The Rigidity of mc.List~ (and of mc.meter~ & mc.selector~)


    May 14 2019 | 11:06 pm
    I've just been getting into using mc over the past couple of months and I'm absolutely loving it so far.
    One of the issues I've consistently ran into, however, is how rigid mc seems to be sometimes (inconsistently). Let's take |mc.list~| for example. The object accepts initial arguments, the number of arguments then becomes the maximum list size of the object (and max number of mc channels being output) There's no "channels" argument, and no way to get the object to change the amount of values it contains unless you type x amt of arguments into the object. This is very different from |zl.group| for example and even |mc.cycle~| which has an @chans arg. When I'm building a multi-channel system, it's very important to me that processing I use is not hard-coded. If I go somewhere with an 8 channel system one day, and another place with a 21 channel system another day, it's necessary that I can just type in the number of outputs in my patch in an int box and have it adjusted to that many channels immediately.
    Same goes for being able to monitor channels with |mc.meter~| and choose inputs with |mc.selector~| Once an mc line is connected to these object, they will only output that amount of mc channels. I've pasted a patch of examples.
    Besides scripting, does anyone know a work around I could use to create a list at audio rate which has a variable number of items? (Or just work around these rigid parts of mc?)
    Also I'd love to hear anyone's thoughts about this, or any other objects that have this problem.
    All the best, MAG

    • May 15 2019 | 5:00 pm
      In most cases I think the 'rigid parts' are there for good reason. In the case of mc.list~, the behavior you want could be achieved with an mc.sig~ and using the applyvalues message. You may want to look at the mc.resize~ object for reducing channels or better yet look at using busymaps.