]]>
i didn't knew that process was not absolutely needed,
now i understand it returns results on a bloc clock, but internally can performs faster operation.
ok now i got to dive into
sorry in advance bsork i think i will request some of your great knowledge soon..Statistics: Posted by 23fx23 — 18 Mar 2010, 15:29
]]>
just curious, a script could process 16x data in one bloc only, or process one after the other and would take 16 bloc?
That's up to the script: For caclculations like these, It's in fact easier to create a loop doing all the maths in one go, but if the CPU load is getting high and the output isn't timing critical, you can with some extra code split the calculations into several blocks.A "script block" (if I understand correctly what you mean with that) is the same blocks as everything in Usine; each 64, 128, 256 or whatever sample. The Callback() and Process() procedures referred to above are two of the three predefined processes called from Usine. The third is Init() which is only run on compile time defining in- and outputs etc. and is the only one that must be present. Callback() is called 0~n times at the beginning of each block - once for every input with any change in value. Process() is called once for each block.what i can't yet figure in my mind is what is script clock, it seems fast;), so internal process can do sub bloc operations?but it seems crasy if you can proccess x/unlimited operation in a single bloc, that's what i really need to dive into..
Relating to the first question, if you want to do all calculations in one go for each change in values, you don't need Process(), but if you want to spread out the calculations or do something else in a block that is not directly triggered by a change in an input value, you'll need Process() to handle it.
A script can - like other modules and VSTs - do "sub block operations" in the sense that there's nothing in the host that's stopping it from doing as many operations as it pleases each time it's called, and just like the other modules it can return values at the end of each block. The number of output values and the number and sizes of arrays is up to the script.
Statistics: Posted by bsork — 18 Mar 2010, 08:45
]]>
So you want the same behavior than math modules?
Be able to input single value or array, and the module provide output accordingly ?
yes!, but ideally slighly different: on math module dealing with array is great, but when you make ie a 16 array in, drive it to the A input of a A<B, on B we put a single, not an array, it outputs returns a 16 array. this is more handy, less cpu consumming, and modular well thinked.Be able to input single value or array, and the module provide output accordingly ?
but in this case relating color, idlike for ex put a 16 array in for H, another 16 array in for S, one more for L, and colors would output the 16 different colors, each one picking relative Hsl setting in the input arrays same index position, to make 16x independant "process"
done with a single module.
thanks a lot for that info, im also running out of time;) but as soon as i can try this i jump in that big step i miss.A script can completely replace the modules
Converting CallBack() and Process() from the module sources to a script can be a good exercise
and putting the algorithm in a loop to process each array members should do the trick
im afraid i will poluate the forum with4x more questions.
just curious, a script could process 16x data in one bloc only, or process one after the other and would take 16 bloc?
what i can't yet figure in my mind is what is script clock, it seems fast;), so internal process can do sub bloc operations?but it seems crasy if you can proccess x/unlimited operation in a single bloc, that's what i really need to dive into..
Statistics: Posted by 23fx23 — 17 Mar 2010, 23:13
]]>
i make an inensive use of rgb and hsl modules, sooo great,
just wondered if it would be possible (i can imagine it's complex ,so no worries, but who knows..)..,
to make RGB and HSL modules working with arrays.
haha, you shot me on the array area with my own modules just wondered if it would be possible (i can imagine it's complex ,so no worries, but who knows..)..,
to make RGB and HSL modules working with arrays.
All is arrays, but not colors modules, ggrrrr
So you want the same behavior than math modules?for example I try to convert 64 colors, it's a bit long to wire a module for each,
it would be soo nice if we could feed ie 64 different data array to the color input, and get a 3x 64 array with relative data for R, G, B out,
or pick 64 array to HSL color, and control all lums via a 64 array in for lum... supose you see what i mean...
Be able to input single value or array, and the module provide output accordingly ?
It should be possible to extend actual user modules pretty easily,
but i'm to short in time to look at this now... just have to found some time...
or maybe if someone else want to try...
A script can completely replace the modulesmaybe this can be done actually via script calling the modules?
Converting CallBack() and Process() from the module sources to a script can be a good exercise
and putting the algorithm in a loop to process each array members should do the trick
Statistics: Posted by martignasse — 17 Mar 2010, 22:28
]]>
]]>
i make an inensive use of rgb and hsl modules, sooo great,
just wondered if it would be possible (i can imagine it's complex ,so no worries, but who knows..)..,
to make RGB and HSL modules working with arrays.
for example I try to convert 64 colors, it's a bit long to wire a module for each,
it would be soo nice if we could feed ie 64 different data array to the color input, and get a 3x 64 array with relative data for R, G, B out,
or pick 64 array to HSL color, and control all lums via a 64 array in for lum... supose you see what i mean...
maybe this can be done actually via script calling the modules?
Statistics: Posted by 23fx23 — 17 Mar 2010, 20:29
]]>