gershwin

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?

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?


cutting-cpu-usage

about the usage of CPU depending of the different part of you patch, you can use CPU Usage in the view menu.

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.

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.


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..

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..


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.

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.

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 :(

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 :(


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...

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)....

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...
T

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)....


I thought I read somewhere that [selector~] automatically does the whole [begin~] signal switching off thing now....is 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?

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?


Shark is good for finding high CPU objects!

am i correct in thinking that as a phasor is band limited then aliasing will occur

Cutting CPU usage