signals~ completely OFF

    Jan 04 2013 | 3:43 pm
    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!

    • Jan 04 2013 | 5:02 pm
      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
    • Jan 04 2013 | 5:27 pm
      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 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
    • Jan 04 2013 | 6:40 pm
      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.
    • Jan 04 2013 | 7:40 pm
      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?
    • Jan 04 2013 | 7:50 pm
      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~]
    • Jan 05 2013 | 1:55 pm
      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?
    • Jan 05 2013 | 3:58 pm
      @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.
    • Jan 05 2013 | 4:42 pm
      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
    • Jan 05 2013 | 5:14 pm
      @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.
    • Jan 05 2013 | 6:23 pm
      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.
    • Jan 05 2013 | 8:13 pm
      got it, thanks!