I'm just wondering if it's possible to fold / unfold effects in the Resolume interface using OSC. Like what happens when you press this little triangle next to the effect's name.
some command like: /composition/video/effect4/folded ?
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. 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.it would be nice if the Resolume interface could somehow reflect if I bypass an effect. As the space on the screen is limited, and if an effect is off, there is no reason to see the parameters.
We're re-examining a few things, but the main hurdle is to find an approach that covers all the bases.Are there any news on the future of OSC in Reoslume 5?
Yes. There a few rare cases where an opacity set to 0 can still affect the output (RGB Delay for instance or certain blend modes), so effects are rendered when set to 0 opacity (not when bypassed though).did you change the behaviour of VFX in case the opacity is set to zero.
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 layoutgoto10 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.
I would say this depends on what you are doing. As I said changing multiple parameters at once could be such a situation.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.
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?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),...
hmm. why not /layer/clip/connect 1 4 or /clip/connect 1 4 (I want to connect a clip, not a layer)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?
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.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.
Yes, yes, agreed! I didn't mean that you can ditch the Res interface altogether, but for the tasks you have assigned to your controller, the controller should become the place you look for feedback, right?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.
Well, the reason I brought it up is to get some user discussion going. OSC as it is now, is rather rigid and unflexible. It is however a system which works logically and works across the whole app.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.
+ 1sleepytom wrote:I'd also very much like to see the ability to colour code the resolume interface - sure it looks very neat at the moment, but I'd like to be able to have colour borders round elements to allow easy distinction between different media items.
At least for the active clip: /activeclip/video/tempo/timelinemodesleepytom wrote: ... you have no way of even knowing if the clip is in timeline or BMP mode.
Why does /layerX/clipconnect/ 1 not allow to use empty layer or active layer trigger styles? One could interpret that it defines to trigger the first clip of layer x. Depending on the triggerstyle it coud start in whatever layer. Though some kind of feedback at which layer this clip actually starts playing could be an advantage.goto10 wrote: Your solution of approaching layers has appeal in its simplicity and is fine for its one intended use. It forgets about the fact that the layer part of the /layerX/clipY/ addressing is literally an address, not a target. Sending /layer1/clip1/connect has different results when the clip target is set to own layer, active layer or empty layer. Your solution of /layerX/clipconnect/ 1 does not allow for this use.
+1goto10 wrote: There are multiple outside of the box improvements that can make things simpler (polling a state for instance, /activeclip/playmode/getstatus/