osc: do not prepend instance name to osc paths when session managed

[jean-emmanuel]

When non mixer is nsm-managed, it prepends all osc paths with the instance name, for example

/strip/kick/Gain/Mute

becomes

Non-Mixer-XT.instanceName/strip/kick/Gain/Mute

where instanceName is the name provided in the --instance-name cli argument.

While this most certainly made sense in the non-daw ecosystem, it doesn't comply with the open sound control specification (paths must begin with a /) and not all libraries allow sending messages without a leading slash (liblo does, but it's not the only implementation out there).

Once again, I assumed the nm-xt project doesn't aim to keep compatibility with non-timeline, and is leaning toward a standalone mixer solution independent of the non-daw project (for instance I use it only in modular/jack-powered live setups). If that's not the case, then this PR should probably not be merged. If that's the case, then I'll probably undertake more changes in the future to make the osc api more public and specific to nm-xt (the original implementation was mostly designed as a private api to allow non-apps to interact altogether).

[Stazed]

Couple of questions.

I do not understand why you would want to remove the instance name. Why not just add a leading / ? In addition, there may be multiple instances of nm-xt, so removing the instance name could send the same message to both instances when that may not be wanted.

I assumed the nm-xt project doesn't aim to keep compatibility with non-timeline,

Well sort of... I am now working on a fork of non-timeline >> non-timeline-xt that I do want to keep compatible. Since it is a fork I should be able to make any changes that are necessary to keep things working.

where instanceName is the name provided in the --instance-name cli argument.

For NSM the cli is not supposed to be used and is disabled in nm-xt. I assume you mean the instance name provided by NSM.

[jean-emmanuel]

In addition, there may be multiple instances of nm-xt, so removing the instance name could send the same message to both instances when that may not be wanted.

Since each instance must bind to a unique udp port, disambiguation should not be needed in the path.

I do not understand why you would want to remove the instance name. Why not just add a leading / ?

That'd be a solution too, although I think it might just be a extra layer of complexity (when using nsm, to send a osc message from a terminal you'd need to remember both the instance's port and its prefix)

For NSM the cli is not supposed to be used and is disabled in nm-xt. I assume you mean the instance name provided by NSM.

Indeed, my bad. However cli support is still required to determine the osc input port (which is fine imo)

I am now working on a fork of non-timeline >> non-timeline-xt that I do want to keep compatible.

Ok, I'll hold my horses then because I'm not proficient at all with that one :)

[Stazed]

Since each instance must bind to a unique udp port, disambiguation should not be needed in the path.

Ah, the reason the instance name is needed for my purposes is non-timeline-xt specific. I'm just getting into the timeline and it appears that when using NSM with non-timeline, the udp port is ignored. The timeline lists all paths of any instance of the mixer in a menu for connection/automation, but does not distinguish by udp port. So if the path does not contain the instance name, the message is sent to all instances. The leading instance name is used to generate the top menu name of the connection list. So, I am not sure that even a leading / might break things.

I will have to look into how the timeline lists are generated and get back to you.

Agreed, hold off on this for the moment.

[jean-emmanuel]

Ok, I suspected it was needed by non-timeline. It's not critical for me anyway as I can cope with the path prefix. If it looks too hacky, I'll just explain the nsm special case in the osc documentation.

[jean-emmanuel]

Closing as it's not critical and interferes with non-* compatibility.