goto10 wrote:Basically our approach to OSC is that on a feedback enabled 3rd party control surface, there is no reason to look at the Res interface at all. That's why you're making the 3rd party interface after all.
Interesting perspective, but I disagree (at least for OSC and MIDI). For me MIDI and OSC devices mainly compliment the Resolume user interface. I think the biggest advantage of such devices is that they enable multi slider/parameter change vs. one mouse pointer only. And for Lemur of course a customizable layout
OSC/MIDI devices offer a direct link to a specific subset of available functions of Resolume. And OSC does not offer all data needed to build a stand alone interface (no preview picture, no real clip names, no... I could go on for a very long time
). And the question is, do we really need all this functions implemented into OSC? Probably not. Unless one can show me a working stand-alone 3rd party interface based on MIDI/OSC only, we need to look/use the native Resolume interface (at least for some specific tasks) AND use the 3rd party controller both together.
goto10 wrote:The moment you need to look at the Res interface to see what you're doing on the control surface, things become needlessly complex, in our opinion.
I would say this depends on what you are doing. As I said changing multiple parameters at once could be such a situation.
But if you are looking for a specific clip, you need to look at the preview window in the native Resolume interface.
goto10 wrote:People have been requesting things like /layer/active/ and then getting the active clip number as an int (problematic because that clip can be in a different layer or deck),...
Interesting question but is this really an OSC issues or more of a general design question? I mean the same question arises for the MIDI implementation, and most likely also for keyboard mappings, right?
How to handle running clips residing in another, inactive deck? Do I control effects of the running clip or of the new clip? etc. etc. tough questions.
goto10 wrote: or addressing clips as /layer/connect/ 1 4 to trigger clip four in layer one (problematic because would then layer/effect/bypass/1 4 also bypass the fourth effect? Can every OSC app handle messages with two arguments?
hmm. why not /layer/clip/connect 1 4 or /clip/connect 1 4 (I want to connect a clip, not a layer)
Bypass an effect: but of the layer or the clip? This is rally not clear using this address.
goto10 wrote:We're open to suggestions, but in cases like this it's important to keep an eye on the whole, instead of your own personal 'perfect' solution.
I agree, it's important to not get lost in details. And I did not request a function for folding, I just thought there is one, which I would have been used then. So no request ticket for this un/fold please.
But with all these OSC topics we just crossed the line of "off-topic" towards "religious-principles"
Anyhow I'm open contribute to these kinds of religious discussions.