Syntax for setting output_routing_type to [live.object]
I'm kind of stumped here and could use a quick hand. I'm trying to set the Live track output to Ext. Out on device load but can't figure out the syntax for it. The "get available_output_routing_types" and "get output_routing_type" produce dictionaries, which work fine, but I don't know how to feed the correct syntax back for "set". Anyone know how to pull this off?
Here's a quick setup for setting the dictionaries up to see what's happening. Note that it has to be in M4L to work properly:
Thanks for the help!
would be great if someone can provide an answer or example for this!
i also managed to figure out how to "get" the routings, but can't figure out how to "set" them.
i tried the message {set output_routing_type $1}, where $1 was being fed by a [dict] object containing:
{
"identifier" : 1,
"display_name" : "ACID"
}
but i get the error: live.object - invalid syntax
can anyone give an example of how to do it properly?
Try the message [set output_routing_type dictionary $1],
where $1 is a dict from the list of available_output_routing_types.
so you are saying that i should feed the $1 message with an actual [dict] object, as i am doing. so i assume that one mistake is i'm not putting the word "dictionary" before "$1" in the message box, as you suggest.
and possibly that my dict should be like this instead of my example above? {"output_routing_type": {"identifier":1, "display_name":"ACID"} }
you suggest i extract the dict from available_routing_types, but i'm extracting from {get output_routing_type}, i suppose there is no difference as long as the contents of the [dict] are identical? i don't have internet where i'm working that's why i can't test right now.
Here is an example for setting the output_routing_type of track 0.
hey broc!
thanks for being the first to finally post an actual working example of the new commands.
i could modify your patch to somehow do what i want, but i'm still puzzled why my patch is not working.
i'm sending a [dict] object to the live.object, which has identical content to the one you are sending, but it's not working.
i am not extracting it from the available_output_routing_types, but from the output_routing_type.
if you save a preset on my patch, and then select it, you can double click on the right, and see that the content has identical syntax as yours, but the message is not passing through for some reason.
The output_routing_type must be one of the available types. I guess there is a simple check based on the internal dict identifiers, not the content.
ok, that's what i was suspecting.
it would be nice if the cycling/ableton team could make a tutorial for the dict object.
i notice that there are many users (especially maxforlive users) who are having trouble with it and are completely relying on this forum.
for now i will try to fix my patch using broc's approach.
thanks bro!
Dictionaries are actually documented quite well.
Besides the usual help and ref pages there is also this article: https://docs.cycling74.com/max8/vignettaes/dictionaries
I can understand that they are not the easiest part in Max to get the head around. Some thoughts about this (maybe/hopefully they can help to lower the frustration)
I believe the main source of confusion with Dicts may be that Dicts are a data structure (JSON) that comes from a different programming environment (JavaScript) and was ported to Max.
JSON (originally) is/was a way in JavaScript to "translate" an Object (Javascript Object = Javascript Code/Data Type/Associative Data Structure ) into a single string. Within JavaScript a JSON object is a string that is (almost) automatically parsed to be a Data Object that can be accessed directly by the JavaScript code. So with Dicts in Max we have a data wrapper around a data wrapper..... The different paradigms between Max , JavaScript and JSON lead to "untypical" handing of Dicts within Max.
The same things happens in other parts of Max when functions of other coding languages are exposed - e.g [regexp], [sprintf], [expr] (handling of variables in those objects are very non-Max-standard because the need the to rely on other data types than available in Max).
Hence working with Dicts in JavaScript is much more straight forward.
Dipping the head a little bit into JavaScript and JSON and than looking back to Max Dicts may help a lot.
i notice that there are many users (especially maxforlive users) who are having trouble with it and are completely relying on this forum.
But that a good thing, no? This forum is meant for that.
i managed to do what i wanted to do but something spooky is happening!
the preset system works fine, but if you save and close the Live Set, not all presets are recalled correctly!
it is a device that allows you to switch output routings of a track, using presets.
i insert my device onto a midi track (track 1 for example)
i set the midi out of track 1, to track 3
and save it as preset 1 in my device
then i set the midi out of track 1, to track 2
and save it as preset 2
etc.. for the rest of the presets
when i load preset 1,
the midi out of track 1 is routed to track 3, as i had saved it
the same with all the other presets i had saved
BUT..
when i save the Live Set and load it again,
some presets load wrong output routings!!
i am attaching the device for download for anyone who wants to test it.
well there's only 2 possibilities i can think of:
1. The pattrstorage contents regarding the routings are not saved properly with the Live Set (but all other stored parameters are saved properly)
or
2. Something overrides (and over-writes) the routing-related parameters at initialization.
i hope i am doing something wrong, or else i can not think anything else than that there is some sort of bug that doesn't let Live save track-routing related pattrstorage data properly.
i don't think i am doing something wrong because
a: the pattrstorage saves and recalls all the data properly while the Set is open, but not the track-routing related data, when saving and re-opening the Live Set.
b: the rest of the data (non track-routing related) is being recalled and saved properly, also when saving and re-opening the Set, using the same pattrstorage.
i'm using Live 9.7.5 and max 7.3.4
if anyone could test it with Live 10 it would be good to know if this erroneous behaviour is still happening.
thanks
Heyheyy little follow up!
I extended Jeff´s patch not only to display and set the available output destinations, but the audio output channel too (works for mono/stereo pairs). If loaded into Live as a M4L device, the patch is also able to figure out on which track it has been loaded. In case of further change, the location can be updated using the "update" button. I post the patch here, have fun with it =)
P.S: I found that if the mono output channels are not enabled in Live, the channel detection won' t happen