Comments (4)
Closing this out for now - but feel free to chime in further if any more questions on any of it!
from lx.
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.
from lx.
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.
from lx.
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
from lx.
Related Issues (16)
- Request for access to LXAudioOutput.mediaPath and/or playing audio via an InputStream HOT 6
- Request: Convert build to Maven or Gradle HOT 3
- Feature request: Add visual aid to heronarts.lx.color.ColorParameter HOT 8
- Delete Channel undo selection state HOT 1
- APC40 out of sync on channel add/delete HOT 1
- Tempo bug with OSC clocksource HOT 4
- LXMasterBus has an empty model, breaking effects on the master bus HOT 3
- tempoLocked Click will never .click() HOT 1
- Colloquial way to link LX build w/ LXStudio HOT 11
- Preferred way to build a model programmatically these days? HOT 4
- LXChannel.transitionTimeSecs has lowest level of 100ms HOT 1
- Storing more than 5 clips in a channel? HOT 3
- How to wait until mixer setup is complete? (LXMixer & LXChannels) HOT 1
- DDP packet size HOT 6
- Gradients using HSV2 blendMode can get jumpy when combined with oscillating colors HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lx.