i once built an FM synth where almost every object was placed in a poly~, and where additional empty poly~ were used as gates to cut off further parts of the dsp chain. in the end it took ages to load that stuff and used twice the CPU when everything was turned on.

that's incredible, I'm assuming like most things, there must be a good balance. Maybe not every object should be put into a poly, perhaps just the msp ones...

I'm sure i'll find out wether or not i've had good habits once this patch is complete but i couldn't help but ask as I reluctantly admit i've done a complete overhaul on this very same patch, ohhhh i don't know, 3 times now ;).

My understanding of max/msp as of right now tells me the best solution to turning off items which eat up a lot of MSP/CPU is to use this poly~ method, which i've found to be very rewarding when you don't require them to be on.

I also have come across another route which consists of enabling and disabling pcontrol in a sub patch, where the msp objects lie in a patcher. I find that route to be less efficient for some reason when referencing the activity monitor though...

I think you're taking the right approach: trying different options for your specific needs. There are general best practices like poly~ use but in the end what works best depends on the actual cases.

I have to say that since I reengineered the vst part of my system so that VSTs now live in poly~ objects, I've seen much better CPU utilization. The way my system works is that I have slots for about ten VSTs. During any one song, up to ten will be needed but not at the same time. Before I switched to poly~, the CPU utilization stayed up high all the time. Now, the average CPU utilization stays around 15-20% for the most part and often drops down to 5-10%

Right now I have a separate poly~ for each VST, I'm not yet leveraging the 'target' stuff that (I believe) would allow me to have multiple VST objects with different plugins inside a single poly~ so that I could leverage multiple processors. That's my next reengineering project.

Each poly uses the arrival of a MIDI event to unmute itself and a peakamp~ object is used to detect that there's no longer any audio coming from the poly so as to mute it again. So the mechanism is completely dynamic, polys~ turn on and off as needed.

The only thing to be careful about is that if a poly~ is muted and you try to edit the underlying VST, you will experience painfully slow response time to the point where you will think that Max is completely unresponsive or broken.

Very pleased with this, wish I'd done it years ago. It's given quite a bit of new life to my system.

sounds like you were experiencing the same thing i was with CPU utilization. Using peakamp~ is definitely a great idea to keep things dynamic.

another approach i adopted to making this project a bit more efficient was downsampling any lfo's. I'm just still a little vague on how low you could actually downsample for these types of signals..

Somebody else on the forums suggested peakamp~ to me --- that worked really well. I also use it to turn on VSTs that do effect processing and so are triggered by audio input rather than MIDI events.

However, I have recently realized that although CPU utilization was impacting performance, my real problem is probably a clipping issue. I just posted about this on a new thread. https://cycling74.com/forums/i-need-some-help-with-compression-techniques-i-think/#new-topic-0

downsampled processing as well as turning things off usually starts to make sense when you are using 3-4 objects.

you will _not save any cycles when you put a [slide~] or a [line~] into a poly~- like i did in my project described above.