Proposal for API change

[leolabs]

Hey @ideoforms, first of all, thank you so much for making this control surface script! It's been super helpful for building TouchOSC control surfaces for Ableton.

I've got a proposal for an API change that would make it easier to use the values returned by AbletonOSC. Currently, when you want to query a track's or a clip's property, it looks like:

• /live/track/get/name 1 -> /live/track/get/name 1 track_name

Using these values in TouchOSC can get a bit tricky in my experience when you're working with properties of multiple tracks, for example. Would it be possible to change the API so that you could include the object ID in the OSC address instead of the parameters? For example:

• /live/track/1/get/name -> /live/track/1/get/name track_name
• /live/clip/1/2/start_listening/name -> /live/clip/1/2/get/name clip_name

This would make it easier to map received properties to elements in TouchOSC and other tools which expect a unique address per property.

This could be an alternative to the current API in a way that the current method of requesting properties still works. What do you think, would this be a viable addition to your project? I'd be happy to make a PR if you think this is a good idea.

I'm looking forward to your feedback! 😊

[ideoforms]

Hi @leolabs,

Thanks for the thoughtful comments. This is an approach that I've thought long and hard about in the past...

With this approach, namespaces would then become closer to canonical OSC syntax, representing a nested tree of objects. (You would probably want clip addresses to become something like /live/track/1/clip/2/get/playing_position)

Part of the reason that I did not make this change is that I intend to add support for querying tracks/clips by their name, not just their index, which may contain non-alphanumeric characters such as spaces, meaning they would not be valid in an OSC address, whereas it would be perfectly valid as an argument (so you could do /live/track/get_color "Bass Arp").

There is a certain appeal to having two different namespace syntaxes, with the current /live/clip/get/name N approach alongside /live/clip/N/get/name), particularly if the latter made it much easier for certain clients to work with.

Do you happen to know of any other client software besides TouchOSC that this would help with?

[leolabs]

Hey @ideoforms, thank you for your quick response!

I'm currently working on an AbleSet feature that works similarly to TouchOSC and also allows you to access values by their OSC path (demo). However, only the latest value for each OSC path is retained, so if AbleSet were to receive the name of two tracks (/live/track/get/name 1 Track1 and /live/track/get/name 2 Track2), only the 2nd value would be available.

I think this is the same case for Open Stage Control projects that use OSC, though I'm not 100% sure.

Regarding the use of names in OSC paths, I've run into a similar issue with AbleSet's OSC API and decided to slugify all names for this purpose. In your project, that could mean that if a track was called "Bass Arp", you could make it accessible via /live/track/bass-arp/get/name which would respond with /live/track/bass-arp/get/name "Bass Arp".

If multiple tracks had a name that would convert to "bass-arp", we'd have to make sure that the resulting slug stays unique, so for example, "Bass Arp" would convert to "bass-arp", and "Bass / Arp" would then convert to "bass-arp-2".

Does that sound like a good workaround to you?