The MC Object Wrapper

When you type mc.cycle~ into an object box, one or more traditional MSP cycle~ objects are embedded inside something we call the MC Wrapper.

The wrapper holds multiple independent instances of MSP objects such as cycle~. It permits you to control all of the objects at once with one message or target individual objects. It also manages multichannel connections to other MC objects. For the most part, this is done transparently and you don't have to think about the wrapper too much. But wrapped objects share some useful messages and attributes not availble in the "unwrapped" versions.

mc.* variations of MSP objects

A general rule of thumb is that if there is an MSP object xxx~, mc.xxx~ will be xxx~ in the MC Wrapper. But this is not always the case. Exceptions include:

Objects that perform I/O: mc.adc~, mc.dac~, mc.ezadc~, mc.plugin~, mc.plugout~, mc.ezdac~, mc.sfplay~, and mc.sfrecord~. In these cases, you don't need multiple copies of objects, you just need multichannel inputs and outputs to the outside world
Gain sliders: mc.live.gain~, mc.gain~, mc.multigain~
Signal visualizers: scope~, meter~, levelmeter~ and spectroscope~ (the mc. is optional and does nothing for these objects, as they auto-adapt to the number of channels of a multichannel input signal)
mc.tapin~, mc.tapout~, mc.send~, mc.receive~: these can be thought of as I/O objects to internal memory buffers
Any objects begining with mcs -- these are single instances of MSP objects whose inputs and/or outputs are combined into a single multichannel inlet and/or outlet
MC objects specific to multichannel signal manipulation