begin~ or mute~ vs. poly~
In the begin~ helpful it says "quasi-obsolete – please use poly~", and I’m wondering if there is an actual reason why someone should use poly~ instead of begin~ or mute~?
I don’t mind using poly~ if it is a better choice (i.e., if I want to use the poly functionality, or if I want to downsample/upsample)… but otherwise it is a hassle to have to have a separate patch just for the poly~.
because mute~ does often not work as exspected.
what you can do instead of encapsulating is to put one empty poly patcher
at the beginning of a chain, and another one at the end.
input
[poly~ poly_thru~]
myreverb
[poly~ poly_thru~]
output
if they are both muted, the signal chain in the root patcher is interrupted
and does not process.
-110
Thanks, that’s a great workaround idea.
Does begin~ also not work as expected? Is there any way to know what will and will not work without having to try it beforehand? This seems a bit clunky…
Hi Anthony.
Currently each "well-behaved" MSP object (including all the Cycling objects) will deal correctly with mute~ and begin~. But many 3rd party external don’t, and will continue running and eating CPU even when you think they’re muted.
On the other hand, poly~ ensures that everything is muted because it actually mutes the whole patch, instead than the single objects. This is why it’s the preferred method.
hth
aa
begin~used alone (and not for creating an independent signal chain) seems useless, that
is what sig~ is for. :)
Thanks for the explanation, Andrea; that makes much more sense now.
Roman, I meant begin~ together with gate~ or selector~. :)
see? i dont even know how to use it. (so it must be bad)