The future of OSC in Resolume

FFGL, OSC, GLSL. If you like abbreviations, this is the forum for you
Rene
Is seriously in love with Resolume. Met the parents and everything
Posts: 388
Joined: Wed Jun 20, 2007 11:53
Location: Vienna, Austria

The future of OSC in Resolume

Post by Rene »

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 ?

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: fold/unfold effects via OSC

Post by Joris »

No, this is not possible. Pretty much everything that Resolume can do via OSC can be found via the OSC mapping mode. If it's not there, it can't be addressed.

Just out of curiosity, what is the user case that would require access to this?

Rene
Is seriously in love with Resolume. Met the parents and everything
Posts: 388
Joined: Wed Jun 20, 2007 11:53
Location: Vienna, Austria

Re: fold/unfold effects via OSC

Post by Rene »

Thanks for clarification Joris. I thought I once was able to fold unfold something via OSC, maybe the Audio/Video section?, maybe I'm just wrong.

I continued to work on my Lemur for iPad Resolume template recently, and 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.
I have around 10 VFX at the composition level, and all are unfolded so I can have an overview. I'll post the template once I figured out how to deal with an annoying bug (OSC feedback controls wrong sliders in Lemur).

Are there any news on the future of OSC in Reoslume 5?

Out of curiosity: did you change the behaviour of VFX in case the opacity is set to zero. It seems that an effect was bypassed in case of zero opacity in previous Resolume verisons, now having a lot of effects (not bypassed) but at zero opacity leads to enormous decrease of the frame rate.

Some pictures of my Lemur Resolume template (still under construction):
1210-lemur-master.png
1210-lemur-master.png (76.7 KiB) Viewed 20660 times
1210-lemur-vfx.png
1210-lemur-vfx.png (68.98 KiB) Viewed 20660 times
1210-lemur-layer_clip.png
1210-lemur-layer_clip.png (115.87 KiB) Viewed 20660 times

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: fold/unfold effects via OSC

Post by Joris »

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.
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.
Are there any news on the future of OSC in Reoslume 5?
We're re-examining a few things, but the main hurdle is to find an approach that covers all the bases.

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), 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?).

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.
did you change the behaviour of VFX in case the opacity is set to zero.
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).

This may have been a bit too much of a broad sweep, and we're probably going to address this internally on a per effect basis (ie each effect has an internal flag than lets it know it can safely be ignored at 0 opacity).

Rene
Is seriously in love with Resolume. Met the parents and everything
Posts: 388
Joined: Wed Jun 20, 2007 11:53
Location: Vienna, Austria

Re: fold/unfold effects via OSC

Post by Rene »

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 :geek: ). 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.

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: fold/unfold effects via OSC

Post by Joris »

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.
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?

Moving beyond OSC, folding effects that are bypassed would be a nice optimization. You can also think of a user case where seeing what the parameters are before un-bypassing would be preferrable. In general our approach to parameter overload is the dashboard (which will probably become more prominent and powerful in Res 5).
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.
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.

As long as we keep that requirement in mind, we're open to suggestion. You can start your sermon, brother ;)

sleepytom
Hasn't felt like this about software in a long time
Posts: 236
Joined: Fri Sep 12, 2008 11:11
Location: sussex by the sea

Re: fold/unfold effects via OSC

Post by sleepytom »

I'd really love it if it were possible to make an OSC interface which didn't require you to look at the resolume monitor at all. This should be an fundamental aim for r5. At the moment its impossible because of the half finished nature of the OSC implementation. (eg clips do not output lots of status info on select, you cannot create an adaptive interface which allows control of the current clips parameters using resolume as you have no way of even knowing if the clip is in timeline or BMP mode. This is so fundamental to interface design that I'm literally flabbergasted that it isn't implemented.)

The clip addressing is fundamentally backward at the moment. It's completely clip centric which make no sense when you think about what resolume actually is...

Resolume "layers" could actually be thought of as "clip players" - each layer can only ever play a single media item so the address pattern of layerX/clipX/connect [0,1] makes no sense (it would only be needed if we could connect multiple clips simultaneously on the same layer, which we can't and never will be able to)
I would suggest that a more sane address pattern would be layerX/connectclip [int] (where the int represents the column of the media with 0 being the command to disconnect the layer) This would be far simpler and reflect how the program actually operates from a users perspective.

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. I'd also like the ability to scroll the window / jump to column numbers with a midi / osc command. All of these functions would vastly improve the ability to create custom OSC GUIs / get the most out of advanced midi controllers.

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: fold/unfold effects via OSC

Post by Joris »

Thanks for chiming in.

I wouldn't go as far as using terms as 'literally flabbergasted' or 'fundamentally backwards', if only because this is a very poor way to start a discussion. But as mentioned above, we're agreed that the OSC implementation can be improved.

However, the current implementation is the only way that makes sense across the board. Every OSC address is the exact counterpart of physically clicking with the mouse. This is the only implementation that maintains consistency for each and every item of the interface.

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.

So in fact, multiple clips can be connected within a single layer. Even when we take targetting/addressing out of the equation, every time you use a transition, you are very much connecting two clips in the same layer, something which the current system can reflect and take into account.

OSC is an open protocol, so we're sort of treading virgin ground here. There are multiple outside of the box improvements that can make things simpler (polling a state for instance, /activeclip/playmode/getstatus/). Changing a single address pattern to cover one issue is not a good idea for improvement, I'm afraid.

Perhaps it's a better idea to outline the actual situation you are having problems with, so we know what to improve.

User avatar
vj granda
Hasn't felt like this about software in a long time
Posts: 195
Joined: Tue Sep 28, 2010 11:34
Location: Andorra

Re: fold/unfold effects via OSC

Post by vj granda »

sleepytom 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.
+ 1

Rene
Is seriously in love with Resolume. Met the parents and everything
Posts: 388
Joined: Wed Jun 20, 2007 11:53
Location: Vienna, Austria

Re: fold/unfold effects via OSC

Post by Rene »

sleepytom wrote: ... you have no way of even knowing if the clip is in timeline or BMP mode.
At least for the active clip: /activeclip/video/tempo/timelinemode

The fact that there are different timeline OSC messages for audio and video, and that a/v clips are treated as audio clips confuses me much more.
/activeclip/audio/position/values vs.
/activeclip/video/position/values

For me also getting names of clips is very important - as this is the only way to get an idea what's behind a button (without looking at the R4 UI), there are no preview pictures or anything else on the OSC controller. Especially for effect clips and FFGL sources, I'd like to get the given names, instead of "Effect Clip" or "Gradient".
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.
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: There are multiple outside of the box improvements that can make things simpler (polling a state for instance, /activeclip/playmode/getstatus/
+1
also for /layerX/clip/name/get 4 or layer1/clip4/name/get
and things like isBypassed, and .../opacity/get

Post Reply