Forums > MaxMSP

begin~ or mute~ vs. poly~

October 26, 2010 | 3:10 am

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


October 26, 2010 | 3:15 am

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


October 26, 2010 | 3:30 am

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…


October 26, 2010 | 12:07 pm

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


October 26, 2010 | 3:59 pm

begin~used alone (and not for creating an independent signal chain) seems useless, that
is what sig~ is for. :)


October 27, 2010 | 12:02 am

Thanks for the explanation, Andrea; that makes much more sense now.

Roman, I meant begin~ together with gate~ or selector~. :)


October 27, 2010 | 1:27 am

see? i dont even know how to use it. (so it must be bad)


Viewing 7 posts - 1 through 7 (of 7 total)