[mc.noteallocator~] busy map name and naming scope with subpatches
So I recently ran into a problem with creating an mpe synth using mc. Everything was fine, until I started using subpatches to clean up my synth. Then suddenly most of the mc objects sending signals were constantly outputting on all channels (e.g. [mc.mtof~] constantly outputting 8.18 Hz for midi note 0 on all 15 channels).
Turns out the problem is the scope of the [mc.noteallocator~]'s busy map.
I tried moving the noteallocator to the main patch but then the subpatch I was using for parsing the mpeevent data doesn't know about the busymap and is sending on all channels.
The only "solution" I found is assigning an explicit @name to the noteallocator and then putting that name into all mc objetcs "Busy Map Name" attribute. Please, please tell that this isn't the go-to way. This goes against the general idea of information hiding and reusability when using subpatches.
I'm basically stuck with putting everything into one giant patch or meticulously providing the busy map's name to every single mc object in the main patch AND in every single subpatch. There has to be a better solution. Is there maybe some kind of [mc.subpatch] that can be provided with a busy map name? I'm at a loss and grateful for any suggestions
I'm running into the exact same issue. I was trying to modularize my mc code, having different osc abstractions that have mc objects but there doesnt seem to be an easy way to have a top level mc.voiceallocator~ controll all of the subpatches :(
So I did find this answer, it is not ideal but a workaround
https://cycling74.com/forums/mc-busymap-target-specific-voice
I'm putting a noteallocator~ object in my osc abstraction with @direct set to 1. I have a separate multichannel envelope abstraction and im feeding the output of that into an inlet that goes to the noteallocator~. It would be great to have either a way of assigning a busymap name to all mc objects in an abstraction or have the abstraction inherit the parent's default busymap.
I'm having a hard time deciphering that since it's only my second week working with Max :D Could you maybe post a screenshot or some example code?
It's good to know I'm not the only one that has an issue with this. A thousand times yes to the idea of downward inheritance!
Here is an example patch, note that an abstraction or two might be missing because i'm just pulling it from something I'm currently working on. The idea is that the output of the amp envelopes is determining if the osc abstraction mc voices are running or not.
This looks like a good use for #0 to provide a unique identifier for each subpatch. Try loadbang-ing a message box with [#0_myBusyMapName] and then directing the output to all relevant mc.noteallocator~ objects. This will ensure that they all share a unique busymap name and will allow multiple copies of the abstraction to exist independently.
Be careful about using [send] and [receive] in this case, since they're global. You could use the [pv] object instead.
Holland - the issue there is that if you specify a name to the mc.voiceallocator~ object, you have to specify that busymap name in every single mc object in your patch, otherwise it the objects refer to the default one. For a large patch this is quite cumbersome and error prone.
Got it. I guess it's only marginally better to send "busymapname" to each mc wrapper object. Esther's original request makes much more sense to me now.