you can use poly for it. every signal connection between 2 muted polys is not running. i sometimes build gate/route constructions based on that. -110

Hi

the "mute" message takes care of your DSP state within a [poly~]; save the two patches below in the same location then close both and reopen the main one one (I named it "polyMute") - a really simple introduction to using [poly~] - essentially it's a hacked helpfile.......so if ya doan wanna use my patch, just look at the helpfile for [poly~]

the main patch (polyMute)

and the subpatcher for [poly~], must be saved as "simple_sine", without the quotes

Brendan

I agree that poly~ is usually the best way to control MSP CPU usage. If you have an aversion to poly~ for some reason, you could use this method, which I used before poly~ came along and still use when appropriate. I a) encapsulate all the MSP stuff I want to enable/disable within a subpatch (patch object or abstraction) with at least one control inlet and as many other inlets and outlets as I need for the incoming and outgoing signal(s), b) wrap that in some other subpatch that takes care of fading in/out and enabling/disabling the MSP subpatch, c) control as many of those constructs as I'd like in a parent patcher. Here's an example that's kind of stupid because it just plays sixteen sine tones, but that should be enough for you to observe a change in CPU usage when you disable them.

I'm also looking for a better way to reduce DSP utilization when I'm not using some parts of my system but I don't know how to use either poly~ or the non-poly~ approach because my DSP abstractions are very loosely coupled.

For example, I have a large nested abstraction called [SynthContainer] that (somewhere near the bottom) contains a VST and much processing but eventually the output goes to a [send~]. Among the parameters to [SynthContainer] will be one that specifies the target [receive~] for that particular SynthContainer.

At the other end is a mixing console with multiple faders, again all inside deeply nested abstractions, each of which contains a [receive~] object so it can get the output from VST~. There are other objects that can also receive the VST audio and send it off to different outputs for monitoring purposes, etc.

I don't know a feasible way to enclose this stuff inside a poly~ nor a single sub patcher.

Are there any other mechanisms available?

Followup --- I did a search (yeah, I suppose I should have done that first!) and found an object called [begin~] which along with [selector~] looks like it can be used to turn off processing.

Can I connect a [begin~] into the INPUT of a [vst~] to get this behavior? Do I need to connect it to all the inputs of the [vst~]

thanks everybody, I did take the poly~ approach, and built a super CPU-intense abstraction, named simple_sine as well than main patch is not changed from n00b_meister What I see is indeed a discreet reduction in the CPU status, but really not in the scale i am looking for... In this example, my old macmini goes from 64% to 55% with muting OFF and then ON

What I'm looking here is a way to completely *silence* and /or *bypass* all those processes inside the subpatch. And reactivate them when needed.

But your proposed solution are best than can be achieved, am i wrong?

@dhj: there is only one solution: in the future, take more care about where to create interfaces between modules, especially for abstractions, which should be something very "general" and easy to use. :)

@personal: everything what is inside a poly (or between 2 muted polys like i suggest above) should eat 0% CPU instaed of what it uses when running.

thanks a lot Roman, what you say means my subpatch/poly I posted above is wrongly built... because as said I'm far form what you say. so i guess I don't get when you say "every signal connection between 2 muted polys is not running" In case you are referring to a structure which is different from the one n00b_meister posted, can you please post a super simple patch of what you say? This would greatly help me! thanks

@Roman Ahhh, if only we knew then what we know now, huh?!

As it happens, I'm deeply using abstractions that are very general and get reused in lots of ways. But the problem (as I understand it) is due to my use of send/receive, a mechanism I also use all over the place to allow for very general reuse, easy addition of new "listeners", inserts, and so forth. My mixer (for example) is completely separate from my "synths", and both are separate from my audio/midi routing system, which has allowed for very significant flexibility, which I don't really want to have to give up too quickly.

It would be nice if audio processing could just be automatically be disabled for any incomplete graph, i.e. if there is no complete "circuit" from a source to a destination.

your patcher above should work from what i can see - at least if you are turning off ALL voices in case there is more than one.

what i mean how i do it is pretty simple:

| [poly~ mypolygate 1] | [yourcoolaudioeffect~] | [poly~ mypolygate 1] |

inside the poly there is an in~ connected to the out~, and a thispoly~which gets the mute message from outside (preferrably through an extra input)

i would now send "mute 1" - [del 0] - into the both poly~s with the effect that the connection between is dead.

-110

got it, thanks!