Automap order of duplicate controls in subpatches
Hey all,
I need to set a different automap number for each control across several duplicated subpatchers.
Eg, if I have a subpatch with 2 controls, automapped to 1 and 2, and I use it 4 times within a parent patch, the controls automap to my Push like this:
1 1 1 1 2 2 2 2
Ie, grouped by number. Makes sense.
What I want to do is give each control a different order number so they'd automap like this:
1 2 3 4 5 6 7 8
Ie, grouped by subpatcher.
The difficulty is that I'm using the same patch multiple times, so presumably I need to dynamically set the automap numbers (or 'long name' parameters would work too, I think) for each control in each instance of the subpatch. A bit like preceeding object names with '#0' in MaxMSP, or '---' in M4L, but neither of those methods work in this case.
Anyone know what I'm on about / if it can be done?!
you can solve things like that by encapsulating loadbang->counter->var or loadbang->#0 in an abstraction.
-110
Cheers for the suggestion, but it didn't achieve what I need in this case. Something similar worked to dynamically rename the 'short name' parameter, which is what shows up via automap on Push (or similar controllers), but that doesn't have an effect on the order in which the parameters actually appear.
As I understand it, this is dictated by 'long name' or 'automapping index', neither of which are dynamically assignable as far as I know.
Maybe poly~ would help, but that would require some enormous re-working of the patch!
Hi Davehouse,
I see what you mean - neither of those parameters are settable via messages/attributes.
I tried to see if there's some logic towards how Live goes about autonumbering the controls if you set them all to the default Automapping Order of zero. It seems to be completely arbitrary... neither related to the order in which you add/position the subpatchers, nor to the order in which you add/position the controls within. So there isn't even a clever workaround.
The solution is definitely for Cycling 74 to make Automapping Order into a settable attribute, if this is something you really need. In which case, you should make a feature request.
An even more comprehensive feature would be to auto-REnumber the controls based on the scripting name of the abstraction (e.g. "abstraction1" would be numbered first, then "abstraction2"), but then you've also got to figure out what to do in cases of multiple nested abstractions - should the numbering order be depth-first or breadth-first? (http://en.wikipedia.org/wiki/Depth-first_search) ...it gets complicated! Perhaps it's better left to the user to implement that themselves in their patch.
Personally, I'm going to disable the 'blue hand' functionality altogether (by locking my control surface to a dummy device) cos I've got other priorities right now!
Do you use Push, Discopatrick? If so then I highly recommend Ubermap: https://forum.ableton.com/viewtopic.php?f=55&t=201849&start=0
It gets around the weirdness of how parameters are automapped to Push by allowing you to set up specific mappings for specific instruments, effects and plugins in Live. Obviously it's a hack - it would be far better to sort it out within Max so it would work across control surfaces - but for now this is working just fine for me, and the author of Ubermap is super helpful.
BTW, despite the thread title on the Ableton forum saying 'Mac only', it's not! I have it working fine on Win 7.
'View' menu > 'Parameters' ...
Edit to your hearts content.
is it possible to do this dynamicly using a message like _parameter_map or something like this?
This would fall into the category of Parameter names, if you could set them dynamically they wouldn't be picked up by the Push as these are all set when a device initialises...
Cheers
D
The hidden attribute Automapping Index can be set dynamically through scripting. See https://www.facebook.com/groups/2209224391/10153937812414392/?notif_t=group_comment_reply