How to disable DSP in a subpatch?

$adam

Hi all,

I'm writing the help file for an external I created, and I made several sub-patches in the main help patch to demonstrate different possible situations of using the object. Now, if I send the "startwindow" message to the dac~ of the main patch, it starts sound processing for the subpatches as well. The problem is that every subpatch has an instance of my object, and if every instance would being used, the entire help would use more than 100% of my CPU. Is there a way to start the DSP only in the current patch window, without starting it inside the subpatches?

Thank you,
Adam

sfogar

Hi,

using poly~ perhaps ?

All the best

--
Alessandro Fogar

http://www.fogar.it

2007/9/20, sadam :
>
> Hi all,
>
>
> I'm writing the help file for an external I created, and I made several sub-patches in the main help patch to demonstrate different possible situations of using the object. Now, if I send the "startwindow" message to the dac~ of the main patch, it starts sound processing for the subpatches as well. The problem is that every subpatch has an instance of my object, and if every instance would being used, the entire help would use more than 100% of my CPU. Is there a way to start the DSP only in the current patch window, without starting it inside the subpatches?
>
> Thank you,
> Adam
>

Mattijs

Check the mute~ help file.

The help file of pcontrol doesn't mention dsp (which is pretty strange actually.. cycling?), but it does disable audio.

Mattijs

$adam

Thank you!

First I tried it but it didn't turn off the DSP, it only muted the sound (my problem was the CPU utilization), so I got very sad. Then I realized that the t_pxobject has a z_enabled bit that changes by enabling/disabling the subpatcher, so I used this to turn off DPS directly in my perform routine. Now it works!!! :-)

Bye,

hans w. koch

Stefan Tiedje

sadam schrieb:
> First I tried it but it didn't turn off the DSP, it only muted the
> sound (my problem was the CPU utilization), so I got very sad. Then I
> realized that the t_pxobject has a z_enabled bit that changes by
> enabling/disabling the subpatcher, so I used this to turn off DPS
> directly in my perform routine. Now it works!!! :-)

Maybe that is the reason why mute~ in general seems unreliable for CPU
optimisation. If every external has to switch itself off, there might be
a lot of the externals, probably even the most expensive, which just
don't do it.
Could cycling's knowledge base (Emmanuel/Joshua/Jeremy...) shed some
light on this? Just for explanation...
I do use normally poly~ to control CPU, but only for the reason that
mute~ often doesn't cut it...
I never heard an explanation for possible problems with mute~.

Just to test it, I made a modified version of the mute~ help file, which
has the reverb from the examples folder incorporated to create some
heavy CPU load. The help file works as advertised and cuts the CPU, but
I know of much more complex patches where it seemed not working, but
maybe due to bugs in the patch, who knows...

Maybe the mute~.help below could be incorporated into the official
distribution? It explains much more than the original one...

Stefan

Max Patch

Copy patch and select New From Clipboard in Max.

--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

jln

Mattijs