Turning off signal processing per patcher

krummelur

Hello, I am working on a project that will function as a sound engine for a game, in order to avoid signal processing overload and allow the user to use as many sounds as he/she desires i want to turn off signal processing for each instance of the sound patcher when it is out of range from player.
As far as I can find out you can use the dac~ object to allow signal processing for a patcher by using a "startwindow" message, however this turns off signal processing for all other patchers.

Is there a way to turn off, or in any other way ease dsp usage for one patcher without resetting the dsp?

I understand poly~ can do this, but poly would be quite a hassle the implement in this specific project.

another solution would be to "freeze" or stop an fft~ object on the fly, as that is what is using the most dsp.

very grateful for any advice.

Christopher Dobrian

See the mute~ and pass~ objects, and the 'enable' message to the pcontrol object. Apparently mute~ is deprecated and may not be further supported in future versions. For now it works. I don't know whether pcontrol's enable function is also at risk in the near future.

The poly~ object is thus the preferred method of CPU control going forward. IMHO, it's not that much more of a hassle to implement your audio inside a poly~ than it is to wrap a subpatch or abstraction with the necessary pcontrol or mute~ paraphernalia.

Here's a series of related examples that might be helpful.Example 22: Switching and mixing audio processes Example 23: Polyphony requires multiple objects Example 24: Generating a simple 2-operator FM tone Example 25: Polyphony with multiple copies of a MSP subpatch Example 26: A subpatch suitable for use in poly~Example 27: Polyphony with the poly~ object Example 28: Phase distortion synthesis in a poly~ subpatch Example 29: A polyphonic phase distortion synthesizer, using poly~