Setting OSC address for parameters? about lx

[mcslee]

Closing this out for now - but feel free to chime in further if any more questions on any of it!

[mcslee]

Yes, OSC paths are automatic based upon the LX component hierarchy. Mouse over any control in the UI and you'll see it's OSC path in the help bar. You can also right-click most controls and "Copy OSC Address" which is helpful for plopping them over into something like a TouchOSC Editor.

The problem with setting global OSC addresses at the parameter level is that there could be collisions (e.g. imagine that parameter is in a pattern and then you have two instances of it, etc.) - which would then require coming up with rules and semantics about what to do with those collisions. So I've held off enabling that.

I've separately thought about offering OSC Learn, similar to the way MIDI mapping works.

Alternately, if you really want custom paths, you can add your own listener to the LXOscEngine and with custom code you can handle OSC messages however you like.

Just throw something like this in your initialize callback - this will get you notified about any messages on the main OSC port.

lx.engine.osc.addListener(message -> {
  // OscMessage message
  // do whatever you want with it!
});

Separately, you can add your own separate OSC receiver on another port:

try {
  lx.engine.osc.receiver(23425).addListener(message -> {
    // OscMessage message
    // do whatever you want with it!
  });
} catch (SocketException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
}

You could make yourself a helper method to register "global" OSC paths in a Map<String, LXParameter> and then just have this listener do stuff based on that.

[Geethree]

Ah I like the idea of registering a new listener. 🎉

When it comes to "collisions".. is that a problem or more of an annoyance? For instance if I set an address to /foo then several parameters were listening to /foo then those would all change? I guess I'm assuming there is a one-to-many relationship in OSC and haven't looked in depth how it works under the hood in LX.

[mcslee]

Yeah it's not necessarily a problem, the semantics of "all parameters at this path get the update" are certainly reasonable enough - but I just prefer to keep ambiguity as limited as possible for stuff closer to the core of LX. String-matching in a global namespace feels a bit too loosey-goosey to me there. Although OSC address patterns can just be treated as non-unique strings - the design intends to reflect a tree. I don't actually implement this in LX, but the OSC address pattern spec includes wildcard matching, e.g. /path/to/*/?/with/wildcards

Hence, this the kind of thing I prefer to make possible through custom code (e.g. add your own OSC listener and feel free to match stuff however you want).

I guess I'm assuming there is a one-to-many relationship in OSC and haven't looked in depth how it works under the hood in LX.

The paths are all guaranteed unique - all components in LX are registered into a tree hierarchy, this is used for both OSC mapping and also things like MIDI or LFO/modulation mapping. Paths are unambiguous, so they can be serialized for later recall, etc. Every LXComponent has a parent which is also an LXComponent, and every LXParameter belongs to an LXComponent.

OSC messages are handled hierarchially/generically by LXComponent
https://github.com/heronarts/LX/blob/master/src/main/java/heronarts/lx/LXComponent.java#L588

Both LXParameter and LXComponent implement LXPath and the static LXPath helpers can be used to quickly look things up in the path system.
https://github.com/heronarts/LX/blob/master/src/main/java/heronarts/lx/LXPath.java