fastest possible clock?

[23fx23]

I dlike to queue some data in array in "real time", even if data is not changing, in order to make things like an oscilloscope or something that could reccord/manipulate/replay any kind of moves,data (fader, swich, ect)

the queue data only update on input changes, so i need to add a tiny random value to input,
im a bit loss regarding clock, what's the best way to generate such fast/stable randomizer? (don't know if it's should be per sample/per bloc/per usine bloc exect) in overall im questioning about fastest usine possible clock, what do ya use?
actually i got jitter pbs on my oscilloscope attempt..maybe im asking to much too usine?

i thought i ve done or asked it before but im stuck::::::

any enlightment?

[martignasse]

Hi 23fx23,

Interesting challenge you have here...

But you are really a mad patcher, this kind of job is more for script or usermodule

Anyway, i uploaded a basic example in the add ons : here

I choose a 10ms resolution (less can let some hole in the array), it make approx 5 seconds of recording with array limited to 512.
I not used the 'Queue data' but a 'Set array value' has it let you control when to store.

With script or usermodule, you should have access to finner resolution (per bloc) thru the Process function, but with patch, i dont see how.

Hope it help

[bsork]

Don't forget that you can treat data like it is audio, eg with the delay and the sampler. Somewhere in the add-ons I think there's already a data recorder using the sampler. You'd get a clock speed/resolution of the sample rate if you can feed arrays of BLOCK_SIZE, or if you have only one value per block, the speed will be SAMPLE_RATE/BLOCK_SIZE. I reckon you would have to limit the values to -1~+1.

Mind you, I haven't tried this much myself...

[23fx23]

great thank you a lot guys!, gonna report.
martin: thanks i ll check this out tonight!!, better/more common to "set array" you're right!
you must be right, this kind of job is a bit too much asking for a patch level, pushing/searching the limits hehe
bsork thanks a lot for reminder, will try a few things tonight as well, I din'nt re/tried that much recoding with sampler wich might be a good solution nay already suggested me a long time ago, now i remember
oops im late must go, see ya later guys

[23fx23]

martignasse: thanx for the pach, and should confirm what i had in mind, im asking maybe a bit too much

it's a shame it took me so long to understand/remember that audio was array of block size! i was always trying to convert audio/data and vice versa with single data type(thinking it was absolute), meaning normal i was totally failing hehe thx bsork, reopened tons of new ideas.

so yup recording to sampler is nice , feeding with an array of block size wich is "filled" by the mono data effectively make it an any data sampler ,by the way not limited to the 512array lengh( there are rumors V5 will have much bigger array lengh, but shut), so if im not wrong the precision is then bloc size, about 3ms for a bloc size of 128samples. iguess this is the "pach" limit precision, per bloc execution.
the queing/setting array elements technique has the advantage to allow directly all arrays transformations, setting resolution, reading pos ect.
there is also the tech i used in endless looper wich is setting directly step values of lines.

sample presision sounds absurd for an input control, but ideally would need sample precision for my " retriggered oscilloscope" in order to have no jitter/all frequencies resolution wavform display,
and as the audio bus outputs and update arrays of sample precision, this mean I can have access to those values!

i would need to "concat each new array" of the audio bus to a new bigger array at each bloc, or "queue array in array" or, well you know what i mean . im don't thinks it's possible yet, who knows, any ideas?