The Rigidity of mc.List~ (and of mc.meter~ & mc.selector~)
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
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.
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!!!
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
Just wanted to add my issue to this in case a solution has been found -
I've got a phasor~ that I'm duplicating using mc.dup~. I ideally want to be able to switch mc.dup~ between 4,8,16,32,64,128 and 256, and for the rest of my mc patch to align automatically with the number of channels. Seems like mc.dup~ and mc.resize~ are both fixed to the number of channels they are instantiated with?
I' thinking there is a way round this by scripting connections with thispatcher, but that seems like a very long way round...!
Any thoughts appreciated.
Fwiw I did build this. Here if anyone needs it.
Somewhat inelegant though....
i've been wondering about mc.dup~ myself, particularly if it's really needed... whenever i need things to duplicate, they seem to do so on their own just by interfacing the single-channel patch-chord with any mc object:
i like the scripting abstraction "mc_connector.maxpat", though, thank you, Mark! when i test it i notice the CPU adjusts accordingly so i think i might use it(along with 'chans' attribute to the regular mc objects; if you use the 'chans' attribute on regular objects, you need to turn off-and-back-on DAC for the change to propagate, anyways, scripting connect/disconnect seems to take care of that automatically, too...this'll be helpful).
testing script and matrixctl... is that possible ? seems to be sample accurate.
next step: in a poly~, can the nb of chans be modified in the time of a mute/unmute ?
bzzz