array "sampler" help

[soundmind]

greetings,

here is what i am trying to do



The problem is some of the "passed" values are not exactly the same for each new cycle. It seems that the values from the step are proceeding too quickly for the "pass" module to catch the same exact ones on each trigger cycle. basically what I am trying to do here is "sample" a very large array and use only the values that reside on each trigger but for some reason some of the values periodically change giving a slightly different result everytime. maybe this is related to the bloc precision? the patch i am building is complex and i cannot get below a 256 block. The values triggered from the pass module are used to drive various perameters (pitch, gain, etc) so exact timing and precision is needed. maybe i am doing something wrong here. any insight? thanks

[23fx23]

mmm that's strange,

here i created a step of 256, set it to bar, i created a sep of 16 for the "sampling clock"same set to bar, that let pass value each next step from 256 like you do, i put the values in a 16 array to check,resulting array is stable and values don't change each loop.
if booth are set to same master clock i see no reasons why there sould be some offset, exept if master clock speed is too fast and that the first step might then output jitter,. how are your syncs?

btw if you sample constantly nth value of array, you could instead just use an expand/compress array with a ratio of 1/16, to get the 16, "each 16" values out of 256, then trigger them as you please, or what do i miss?

[soundmind]

thanks a lot for the fast reply. To be honest I myself don't understand the problem so its hard to explain. The best way to describe it is there is a periodic "jitter" to the values being triggered which causes the parameter modulation to be "choppy". I am on a slightly older low budget laptop with less than 2 ghtz processor so im wondering if that could be the cause. because i have also had choppy slice triggering with the sampler and the grain module. This has not happened with the previous versions as far as i know. The sampler and grain behavior is strange because some samples are fine and some cannot have their slices accurately triggered. Is there known formula or advice on how to get the samplers to trigger slices smoothly without clicks and pops based on the start and end pos? I will take a look at the patch and see what other info i could give. thanks.

[23fx23]

mm don't know how to help you. here to test it work ok if reading 256 values and tempo is at 120, start to get some "random" moves/jiter when tempo gets more than 150, at 300 i clearly see them, this with a block size of 128. i i swich usine on 32 block then ropen even at 300 no jitter.
i suppose at a block o 256 you can get that in your case but seems lowering blocsize is the only solution..
(mmm now i note still this can appear at low tempo, as kind of some time alignement/bloc process clock don't match)

in fact the solutions are eitheir find one of the magical matching tempos hehe (have a tempo that will have bar with a nb of blocs that is pair, ideally possible to be divided by 2/4/8/16/ect) not easy hehe (but that's a reflexion i had to make kind of some 'right fiting the sample/bloc matrix musi lol)

..or i use a bloc counter script as i previously spoked about ,directly controlling reading position instead of build in "time" clock of modules when needed such fast clock/precision is needed, so that at each block you are sure to extract and return the exact value of the array, jitter free.

[soundmind]

Yeah i think its related to the blocksize. The bigger the block the less accurate the events are? the problem is my cpu can only handle 256 with this particular patch so i guess its time to upgrade my machine. things must be very smooth with a 32 block. thanks for the help anyway.

[23fx23]

just for fun, sounds stupid but i tried to find those "fitting the sample/bloc matrix" perfectly tempos, for one bar, choice is limited, but no drift possible theorically with, for a 256 bloc, folowing bpms (but only those,).

32.29980 1bloc
40.37476 2bloc
53.83301 3 bloc
80.74951 4bloc
161.49902 5bloc ,hope ya make Dn'B:lol: in between drift is mathematically fatal if im not wrong, more or less so generally i suppos we don't perceive it. with lower bloc size the choices are highly extended... still i think any 'bloc' based system make true synthesis a pain to deal with, that's more the job for a synth ie reaktor.( my dream is in future we could have computers fast enough to run usine at 1 sample bloc size, that would make it a crasy synth,?) i imagine how brainy it must be for music programmers to deal with such bloc constraint.
ah good old analogique had no such jitter;)

ive just tested, at 161.50 i see no drift, whereas i see some at 159 or 161, so this confirms my "magic tempos" theory lol

[soundmind]

btw if you sample constantly nth value of array, you could instead just use an expand/compress array with a ratio of 1/16, to get the 16, "each 16" values out of 256, then trigger them as you please, or what do i miss?

great idea.

32.29980 1bloc
40.37476 2bloc
53.83301 3 bloc
80.74951 4bloc

Those BPM calculations are very interesting. I will see what kind of results i get with those.

..or i use a bloc counter script as i previously spoked about ,directly controlling reading position instead of build in "time" clock of modules when needed such fast clock/precision is needed, so that at each block you are sure to extract and return the exact value of the array, jitter free.

Ill have a look. sounds like a good solution.

yes a 1 block usine would be a super synth. Is there a specific reason why usine uses blocks? I do notice that usine can have hundreds of modules in several patches all processing multiple data and audio streams without slowing down. Some of the other modular apps are not as robust.

[23fx23]

I supose every data/audio software need some "buffers", ie "blocs" , ie there is a latencybuffer to process audio, based on the asio setting, that's something that always have been unclear to my mind. Before I was playing "Hardawre" with some roland synth, electribe, mackie mixer ect, and they most were fake "analogue, that's numeric, so why didn't they have latency whereas a 2010 quadcore with a 500 euros sound card still have latency cause of blocs, well i don't know...

in most cases data process don't need sample precision, ie that would be cpu not cool and useless to make a pach that send for example midi from a fader, computed each sample, sounds far more desent to compute each 3ms, ie with a bloc size of 128 as only super heroes can moves faders at higher speed, and i doubt any midi based device can't already reach below 1ms data transfert.

I guess that's why usine can handle so much things, it has an adapted for more common task buffer, limitaion is just then synthesis or application that need sample precision, still we can get access to samples a audio is an array, just computed "results" can't go below bloc time, except for script or user modules, but not in patch.

relating to your problem i think just use an expand compress should solve the pb, if you need fast access then use the bloc counter script, it's in a thread called "bloc counter" in suggest improv if i well remember...
and drive it to the index of a get array element value, but yes i would happy to know if one of the "magical tempo" works for you..

[bsork]

Something like this?


Using Get Array Element Value avoids the the problem with blocks and timing. The Step module can be in synchro mode button maybe saving a tiny bit of CPU - unless you have it running for some other reason. In that case, the synchro of Step and SeqSwitches can in fact run independently of each other, since your directly accessing the elements in the Step array.

For good measure, I also added an "index offset" fader (min=0, max=15) so you can use the other 240 values as well.

Edit: Multiply the output of Trunc by 16 using an A*B module.

[23fx23]

yes youre right bsork! just note in soundmind case that step is a 256 lengh array and seqswich a 16 lengh, if im not wrong the picture would work only if arrays where same size, but should just multiply the 16out step position by 16 to get it working, , nice solution, other is to compress array by a16x factor and read it, quite equivalent?

[bsork]

You're quite right! I was going to bed when I just realized the mistake... Put an A*B between Trunc and GetArrVal and multiply by 16, then it should work.

[soundmind]

this is great. many thanks to 23fx23 and bsork for the help. you are absolutely right about avoiding blocks and timing issues with the get array val module. great work. Another question i have is if it is possible to get integer precision within the array module? it seems like you can only adjust the faders with decimal precision. thanks again for your advice.

[bsork]

I don't t remember if any of the array modules (weith that I also mean eg SeqSwitch and Step) can be set to integer resolution on the faders. You can however drive the array outputs through Trunc or Round modules to get integer values.

[soundmind]

the steps module does allow integer precision on the faders. it is a selection in the module just like the faders and knobs modules have a precision selector but the array display or set does not have this. it only allows you to draw in values with decimal precision making it difficult to draw in exact integer values. maybe this could be a feature request?

[23fx23]

you can replace an array display or set by a step module, wich is equivalent, and have a precision that can be set to integer.

[soundmind]

yes but i thought the array module uses less cpu than the steps?

[bsork]

yes but i thought the array module uses less cpu than the steps?

I think so, but unless you use a large number of them, I'm fairly sure that the difference is neglible.

[soundmind]

bsork,
thats good to know. thanks for the help.

[soundmind]

After hours of patching and repatching I have concluded that the choppy sample slice triggering was caused by the way the slices were being selected by the start and end pos. The problem was that I was modulating the start and end pos from the wav display. for example to get a 1/16 slice from a loop divide 100% by 16 and multiply the result from 0 to 15 into the start pos of the wav display connceted to the sampler to get the slices. the complications came about because i also modulated the end pos by adding the result of the division to the result of the multiplication. The reason for doing this was because the loop (start, end pos) in the wav display would show the actual size of the slice based on the results of the maths and makes a nice "highlight" of each slice. well for some reason this was making the sampler choke on samples but once i repatched and only modulated the pos from the sampler all is well with no choppy playback at all. The other problem was solved by making the arrays a lot smaller. because in the old patch sometimes the array would be thousands of steps per cycle. maybe this is too fast for a 256 block. anyways thanks for all the help!