Holland Hopson

I'd like to turn off sections of a multichannel patch when they're not in use. Before mc. objects came along I'd use poly~ for this task. It's almost working here, too, but not quite. The processing turns on and off, but the 8 channels of audio are output as a single active channel and 7 silent channels. What am I missing here?

Is mc.voiceallocator~ and the busymap a better way to approach this problem?

Here's the poly~ (name it mc.poly-onoff.test)

mc.*~

adsr~

thispoly~

message

route

out~

meter~

comment

scope~

flonum

ezdac~

toggle

mc.cycle~

mc.poly~

I'd like to turn off sections of a multichannel patch when they're not in use. Before mc. objects came along I'd use poly~ for this task. It

using-mc-poly~-to-toggle-processing-on-and-off

Answering my own question for future forum users:

mc.poly~ sends messages to the first active voice unless otherwise specified. That's why the first channel in the patch above was operating as expected and the others were ignoring the input.

Use a "setvalue 0 $1 " message to target the input to all voices of mc.poly~.

Now on to figuring out how to use poly~ to encapsulate portions of patches that include both standard (mono) MSP signals and mc. multichannel objects. My hunch is I'll need to keep them separate. Otherwise when I mc.poly~ize a mono signal chain it'll get distributed across multiple voices.

Answering my own question for future forum users:
mc.poly~ sends messages to the first active voice unless otherwise specified. That's why the first channel in the patch above was operating as expected and the others were ignoring the input.

depending on what you are doing, you'll generally find that for cpu control in mc.* land you need to use mc.voiceallocator~ (or mc.noteallocator~), and leave mc.poly~ etc for other tasks. they are definitely the way to go, and very powerful.

mc.voiceallocator~ takes a while to get your head around but the key in mc.* is managing the resources of the chain with the various properties (attributes) of the various mc.* objects in your patch, exposing them to the voice management system on a per channel basis. mc.* is more like jitter in some ways than old MSP land.

I've started working with mc.voiceallocator~ and busymaps. It makes more sense to me when dealing with synthesis processes that are event driven. Much of what I do involves processing live input, so finding the right points along the chain where voices can be freed is taking a while to figure out.

Thanks STKR,
I've started working with mc.voiceallocator~ and busymaps. It makes more sense to me when dealing with synthesis processes that are event driven. Much of what I do involves processing live input, so finding the right points along the chain where voices can be freed is taking a while to figure out.


the voicelallocator is great, but I can't find a way to turn a specific voice on/off. The release message takes a voice number as an argument, so I can say "release voice 7" and voice 7 goes off. But how can I turn on voice 7? The event message doesn't work that way. "event 7" just turns on the first free voice, not voice 7.

the voicelallocator is great, but I can't find a way to turn a specific voice on/off. The release message takes a voice number as an argument, so I can say "release voice 7" and voice 7 goes off. But how can I turn on voice 7?  The event message doesn't work that way. "event 7" just turns on the first free voice, not voice 7.

Using mc.poly~ to toggle processing on and off