]]>
Statistics: Posted by soundmind — 29 Mar 2010, 11:02
]]>
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.Statistics: Posted by bsork — 28 Mar 2010, 22:01
]]>
]]>
]]>
]]>
]]>
]]>
Statistics: Posted by bsork — 25 Mar 2010, 23:57
]]>
]]>
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.
Statistics: Posted by bsork — 25 Mar 2010, 22:23
]]>
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..
Statistics: Posted by 23fx23 — 25 Mar 2010, 06:32
]]>
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.Those BPM calculations are very interesting. I will see what kind of results i get with those.32.29980 1bloc
40.37476 2bloc
53.83301 3 bloc
80.74951 4bloc
Ill have a look. sounds like a good solution...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.
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.
Statistics: Posted by soundmind — 25 Mar 2010, 05:05
]]>
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
Statistics: Posted by 23fx23 — 24 Mar 2010, 08:04
]]>
]]>
(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.
Statistics: Posted by 23fx23 — 24 Mar 2010, 06:12
]]>
]]>
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?
Statistics: Posted by 23fx23 — 24 Mar 2010, 04:16
]]>
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
Statistics: Posted by soundmind — 24 Mar 2010, 03:00
]]>