Cutting CPU usage

    Jun 21 2012 | 4:35 pm
    I have a synth patch which uses poly~ and rather naively/lazily I have about 90-100 "in" objects within the poly subpatch. Is this a reason I can't use more than 16 voices before the CPU usage is too much?
    It has 40 oscillators in each voice (well 8 x 5 = 40 as each oscillator has the possibility to be a cycle, saw, phasor, rect or tri through a select object). So I guess it could be the number of oscillators? although aren't there some synth VSTs which have hundreds of oscillators.
    Is there any good way to cut CPU within a synth patch? or identify heavy CPU usage within a max patch?

    • Jun 21 2012 | 4:59 pm
      about the usage of CPU depending of the different part of you patch, you can use CPU Usage in the view menu.
    • Jun 21 2012 | 7:55 pm
      hi thanks for the reply. the "show cpu usage" function just points to the poly patch, and you cant view cpu usage within a poly subpatch.
    • Jun 21 2012 | 7:57 pm
      I used it sometimes by decapsulating the subpatch outside of "its world" (I mean the poly)
      It often helps to see the red level parts..
    • Jun 21 2012 | 8:06 pm
      What I have been doing, sorry gershwin this doesn't help too much now that you've made the patch, but helpful for the future.
      I am always testing out the CPU use as I build things, in fact i usually also have the activity monitor from OSX utilities (PC probably has another fxn), and have it in a window beside max. Its a really good indicator as to CPU use as you program, often for stuff i know is CPU consuming I will patch it 2-4 different ways just to see what has a better impact on my CPU as I build, then chose the lesser CPU method.
      Best of luck
    • Jun 21 2012 | 8:08 pm
      unit tests rock, indeed !
    • Jun 21 2012 | 8:41 pm
      thanks for the help turns out having 10 biquads going into each other in each voice took up a load of CPU. The big CPU drinkers are the oscillators, but having a selection between them is a necessity really :(
    • Jun 21 2012 | 9:45 pm
      What about using [begin~] in combination with [selector~] to turn off the oscillators that aren't selected? Does begin~ work inside a poly~? I can't remember...
    • Jun 21 2012 | 11:44 pm
      I think begin~ is deprecated-- I believe a possible way would be to have nested poly~s, so the oscillator selection function is a poly~ patch within the parent poly~. Not sure how you'd implement it though; it would probably be tricky to patch. The only thing I can think of off hand is Alex Harker's dynamic dsp suite of objects which can load (sub-)patches on the fly without interrupting the signal flow...
      edit: also depending on your reason for having the 10 biquads, and how they're implemented, you can probably optimise it. If they're in series you could use the cascade object instead. In max 6 there are also filter design tools that might help, and implementation within gen~ (ie discard coeffs that you don't need etc)....
    • Jun 22 2012 | 10:29 am
      I thought I read somewhere that [selector~] automatically does the whole [begin~] signal switching off thing that true?
      Also I second the [filterdesign] suggestion by terry unless you need to sweep the filter at signal rate. If nothing else it saves on objects. Also why do you want to use [Phasor~] its more of a control signal i.e. not band limited.
      Also I wonder whether you really need all those oscillators in each poly instance. Cannot some of them be used globally for all instances maybe FM oscillators for instance?
    • Jun 22 2012 | 1:33 pm
      Shark is good for finding high CPU objects!
    • Jun 22 2012 | 11:17 pm
      am i correct in thinking that as a phasor is band limited then aliasing will occur