- consume loads of CPU (most of it is because of the tri~ in mat_osc_poly)
- Rnd! button also randomize on points that are deactivated, maybe it shouldn’t.
Hi Manu,
-
For the cpu, I think that the main problem comes in the fact that all the oscillators types are running even if they are not selected. I was thinking of using mute~ and selector~ but they are deprecated… Any other suggestion ? enable ?
-
You mean, points that are deactivated for a type of oscillator ?
- for cpu… write a C external
using one cycle~ with predefined wavetable is likely to be faster, but won’t let you change the extra parameters of tri~ and rect~.
There’s a small things you can do to improve a bit the efficiency of the abstraction without changing much, probably not going to make a huge difference though:
those 2 lines could be merged into just one
CloudApp — Not Found
the sig~ → mtof~ could be just changed to mtof → sig~
CloudApp — Not Found
since you have 8 abstractions like this in each voice that might make a slight difference… or not…
And yeah, test with mute~/enable is that makes anything better… Or ask Thibaut to make you a nice object that does all that.
- for the matrix, I would not expect the OSCn PW to be randomized in this case:
http://cl.ly/image/1Z1Y2U2K401h
Enable works fine. It takes now half of cpu on my test sequence with six of them !
Jean
Awesome!