signals~ completely OFF

Jan 4, 2013 at 3:43pm

signals~ completely OFF

Hi all,
is there a way to completely minimize the CPU consumption of a signal patchcord?
I’m not talking about muting it, like having the output signal~ be zero. Even in that case, i guess, there will be 44100 zeros every second, and if you don’t really need it it’s not very convenient to wast such resources.
I have in mind using poly for this, but never really study it a lot, to be honest ;-)
Should i need to study it now-now ^_^ , or is there some other option?
Thanks!

#65919
Jan 4, 2013 at 5:02pm

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

#237402
Jan 4, 2013 at 5:27pm

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)

– Pasted Max Patch, click to expand. –

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

– Pasted Max Patch, click to expand. –

Brendan

#237403
Jan 4, 2013 at 6:40pm

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.

– Pasted Max Patch, click to expand. –
#237404
Jan 4, 2013 at 7:40pm

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?

#237405
Jan 4, 2013 at 7:50pm

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~]

#237406
Jan 5, 2013 at 1:55pm

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?

– Pasted Max Patch, click to expand. –
#237407
Jan 5, 2013 at 3:58pm

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

#237408
Jan 5, 2013 at 4:42pm

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

#237409
Jan 5, 2013 at 5:14pm

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

#237410
Jan 5, 2013 at 6:23pm

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

#237411
Jan 5, 2013 at 8:13pm

got it, thanks!

#237412

You must be logged in to reply to this topic.