tb/script/oneliner_ik.axo
status
active
description:
one line script object, integer inlet, fractional outlet
this is a variation of the factory oneliner object which takes a fractional input.
active
one line script object, integer inlet, fractional outlet
this is a variation of the factory oneliner object which takes a fractional input.
(includes help file)
more to come, that interpret the data e.g. as pitch, frequencies
active
prints i - print integer (with optional text) to the console.
prints f - print fractional (with optional text) to the console.
prints on initialisation (so useful for debugging execution order, see help file)
print when number changes, at a max rate of once per second.
Note: these are intended for debugging as they have a performance overhead... but sometimes simple tools are useful for debugging patches
(includes help file)
active
enables codec mixing for direct feed from audio input to output (bypassing DAC obviously )
active
1.0.10 (will work with 1.0.9+)
flashes led on midi activity from selected midi device
active
1.0.10 (will work with 1.0.9+)
act as a midi through devices (excluding sysex/clock)
received midi from selected input and forwards it to selected output device, optionally flashing led 2 when data is sent.
note: can send/receive from internal midi bus as well.
active
1.0.10
record and playback k-rate signals as events... this means very long sequences can be recorded in very little memory, as it just records changes.
(see help patch for example usage)
I wrote this quite some time back and posted in a response on how to record k-rate events,
just forgot to post it in the community library.
it records 'size' events, by using a time and data table.
at some point, i will extend/create a version which can record N values using the same time base, which would be efficient on memory. (though only if events coincide in time frequently)
active
1.0.10
cycling attack/decay envelope
added end of cycle trigger
active
1.0.10
see help patch for usage
help objects for axoloti control (axoc), each object is a group of physical controls.
each object display the output values from the control, so the user can see the data values clearly, and the analog controls (knobs/joystick) have a light filter on them.
it should be noted the switches are momentary.
there are inputs for the leds, it should be noted there is no implied relationship between switches and leds, if you wish them to be connected simply connect the switch output to the led input.
active
under active development, may have changes...
(play may be renamed to oscillator , though this change will not affect your patches)
1.0.10
see help patch for example usage.
use wavetable load to load a wavetable (or single wave), specific number of waves in the wavetable, and the size of each
then use wavetable play as an oscillator , referring to the above table (use .../waveloadobject syntax if used in voice subpatch)
if you select 1 wave, they it can act as a single wave oscillator.
important note: waves is number of waves, and must be a power of 2, size is the size of a single wave and again must be a power of 2... there are min/max for each to keep in reasonable bounds
I'll be adding a video here, of how to create wavetables using audacity. It should be noted, there is a 'skill' in producing decent wavetables, its not all down to size , but content and also the ordering.
windex selects the wave in the table, where 0..64 is proportional e.g. if the number of waves = 4, then wave 2 is selected with 32.
xfade will crossfade between waves,
when combining windex and the parameter windex, the index 'bounces' off the end, it does not cycle. I found this more useful behaviour for my needs.... it also means if you set the param to 64, essentially you go backwards through the wave table. (this is not the same as playing the wave backwards!).
limitation : xfade is still forward.
wavetable load fn, dynamic filename variant , use trig to load , outlet indicates if load was successful or not.
note: wavetable must be same number of waves, and each wave the same size, also like table/load etc, file is loaded in audio thread, so could cause audio glitches.
aliasing, at high frequency its likely wavetables will alias, I may improve this overtime, or at least come up with a workflow that can help - but please note its not a simple thing to eradicate.
(note for me: pvoc (Phase Vocoding - Dodge and Jerse, 1997) used by many... including MI Clouds , issue seems to be at small bucket sizes, it will tend to smear the sound, ok for fx, no good for oscillators)
writing this, I think it might be nice to have a reverse waves options... not really necessary, since you could always reverse table/wave cycles before loading, but might be fun, especially when using as a single wave oscillator.
0.1 - added simple wavetable for help, add comments to help file
0.2 - added wave/wavetable load fn
Nice pair of objects. Look forward to test them. Need to update to 1.0.10 sooooon....
Anyway, could I humbly suggest to make a version of the wavetable load object with a filename input to be used with the string/index object? To make it easier to change wavetables.
not something I tend to use... but sure, Ive just added it for you.
there is a restriction that the number of waves and size of each wave is the same.
Cool thanks
Ahh ok. Not sure I understand it correctly; Do you mean that in a wavetable of 128 waves, each wave also has to be 128 samples long?
no... I mean if you have a wavetable consisting of 128 waves each of 2048 samples, then when you use dynamic loading, then each file you specify has to be 128 x 2048. i.e. the 'structure' of the wavetable is the same.
theres a lot of bit shifting going on, and having some things constant improves efficiency... i suppose I could have variations which sacrificed efficiency for flexibility, so you could specify these things dynamically...
though there would be an interesting question about how the patch would know. I guess
one possibility would be a file naming convention (i think serum (?) does this) e.g. SINSAW_128_2048 = 128 waves of 2048 samples. (wouldn't help efficiency, but could be cool for just selecting files at runtime)
Cool. I all ready converted a bunch to 128X2048 so that is great Look forward to try the objects out later in the afternoon.
ABout the filenaming, when using the index object you have to follow certain rules. And that is fine with me and works perfectly. My WT's are called 128W001 128W002 etc. Then it is easier to switch between them with index object. Or else you have to make the patch unlive and write the new name of the new WT into the load objects and make the patch live again. That is just too complicated and destroys workflow.
To me it works perfectly when using indexing object. thanks again for implementing it on this object
Hey @thetechnobear
I was playing around a bit with the wavetable play object you made.
It is pretty great. Thank you for it
I was just looking at the code, because I am trying to add a reset phase function. This is good for bass sounds, for example.
But the code in sample rate looks alot different than from a regular phasor with reset and I didnt succed.
Is adding a reset inlet for the wavetable play object something you would consider implementing? Or a sync input maybe? Both can be used for resetting.
Jaffa
**EDIT: **
Actually I think I managed to get it working on my own now I need to test it a bit further before posting it.
I don't think there anything to it - just set the phase to zero.
the only 'oddity' I would expect, is audio glitches if you are also modulating the table.
(i usually only move to the next wave at the beginning of cycles, so that we can do it thru zero)
not got time this evening, but will take a look later
As I mentioned I think I got it working
I copied the code from a phasor with reset inlet. When reset inlet is triggered by the same source as the gate it is pretty much click free. Also way more consistent. And that is all I was looking for, consistency.
BTW you mention set the phase to zero. There is no phase button on the object. So not sure what to do here
@Sputnki @thetechnobear Here is the version I have now
wt play rst.axo (4.0 KB)
Maybe a k-rate retrigger would be more suitable, while a s-rate sync could be done directly inside the object (making it more easily alias-free)
Take a look at the one I have and tell me what you think. I think it works pretty well
I don't have my axoloti with me, so i can't test it, however i meant a reset inlet just like that, bravo!
I guess the sync implementation would be trickier, seeing all the effort johannes has put into bandlimiting the osc/saw sync object. I wonder if that could be ported from an object to another (i guess no, but who knows)