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.
    • Jan 11 2020 | 12:32 pm
      Hello, I'm facing the same problem here. With a mc.gate~(or selector!), if I have one output open with 1 channels and another one, closed but with 25 channels (for exemple) still the output will be 25 channels even though only 1 are passing through. This is quiet annoying indeed! miillkk, have you found a way to deal with that? or testcase could you be more specific? I have try with mc.resize~ but it doesnt really work... Thank you very much!!!
    • Jan 13 2020 | 4:32 am
      Hello! Actually I did end up running into this same problem.
      What I ended up doing is having two outputs inside of a subpatcher: one for one amt of mc channels, and the other for the other amount.
      In my case all I had to do was connect both lines to mc.DAC and they still would output correctly.
      Otherwise I couldn't really find a simple, clean solution for this. Something I thought of that you could do is to have two meter~ objects which overlap. Make one visible while the gate is on, and invisible while off, and do the opposite with the other (turn on monotone mode, set bgcolor, offcolor, oncolor to transparent).
      Also I have a feeling you were trying to do what I did here with your patch. If you need any more pointers I can help ya out.
      This is what the outside of the subpatch/bpatcher looks like:
      -mag