BrowseRouting abstraction can link to the parent track of the device - causes ear-splitting feedback
Hello. I've been having an issue with a device I've been developing. The device uses the BrowseRouting abstraction to allow a second set of input channels (3+4) whose audio is from one of any tracks in the live set. The issue I've been experiencing is that it is possible to ask, through the umenu object, for the device to pull input audio from its parent track. The audio is routed through the device, processed, routed again, processed again - you get it. The sound is unbearable and certainly a safety hazard.
I'm here to ask (meekly - I'm only a month into using Max) if there's a way to modify the BrowseRouting abstraction to ignore its parent track when using live.observer to call IDs from the live set. Or, short of that, if there is a way to guarantee it won't feed back in such a way that could be damaging.
Willing to share my code if that would help at all, but as of right now my use of the abstraction is very straightforward.
Thank you to anyone who takes the time to help me on this!
So first, in case you don't know, you may not want to use the BrowseRouting abstraction. It's been replaced with a [live.routing] object which does the same thing. Unfortunately I don't think changing one for the other helps with what you're after.
IIRC there isn't a way in the API to go from "I know what routing input I want" to "I know which track (id) it comes from", since not all routing inputs correspond to Tracks.
I think your best option is (sadly) to try to compare the name(s) you get as menu items back with the name of the parent track of your device, obtained from the LOM. Then you have to make sure that the corresponding index (from the umenu) can't get selected. The programming pain point here is that track names and the routing index can change during the live set..
Simplest thing to do for safety: put a Limiter device after your M4L routing device for safety.
Ah, interesting! My standalone max installation was updated to reflect live.routing becoming standard, but my m4l install was not. I'll fix this.
I'm assuming either way it will wrap around to a umenu object? It's possible that digging in the help and references for umenu and live.routing could help me get started on fixing this. It feels daunting, but will probably be good practice and teach me something.
Does the live.routing object simplify the system too much, though? My first thought is that it would be easier to manage this type of thing inside of BrowseRouting, as the RoutingObjects abstraction inside of it manages track IDs separate to the audio input routing. But I could be wrong. If there's a way to do it with live.routing, I'll take it. BrowseRouting's code is spaghetti-like and intimidating (to me).
You're right in that the goal you suggest sounds arduous, and involves a couple of pain points. A great temporary solution will definitely be adding that limiter object - I hadn't thought of that. I will update my m4l, do some research, and possibly return here.
Thanks so much! o7
I haven't actually used live.routing myself, but I spent enough time a few years ago dealing with BrowseRouting to never want to look at how it works again. :)
From what it seems live.routing's output is fairly similar. You could probably just make your own abstraction that wraps around live.routing, gets the index of the matching track name and then uses that index to send a "enable <N> 0" message to umenu for that index. That way it doesn't mess with live.routing's indexes and also prevents you from selecting it.
I think you can still use live.routing with Live 11, but actually I'm not totally sure, I guess there's a chance it's dependent on Live 12.