Rene wrote: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
So you've not tried to do this yet then? /activeclip/video/tempo/timelinemode doesn't output when you select a new clip, actually it never outputs AFAIK its one of the in-only commands (this was the case at 4.6 anyway, i've not bothered with 4.7 yet due to other users reports of stability issues)
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
Yes thats stupid isn't it? Even more stupid is that timeline position is output as a 0-1 float, and clip length isn't output at all so you cannot create an interface which displays meaningful position information (eg how many seconds we are from reaching the end of the clip) If we could get a status of clip length in MS then we could do some basic maths to give us our played/ remaining durations.
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".
+1 - Names are clearly broken at the moment - obviously the name should represent the label as given in the GUI not some arbitrary hard coded name. I'd file this in the same area as generators (eg solid colour) should update their thumbnails (probably only need to do this once a second, but it would be a huge improvement over looking at an interface of red squares which have labels such as GREEN, BLUE, ORANGE written under them which when you look at the osc all output their name as "Solid"
joris wrote:
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.
Except that it doesn't, as when you get down to it loads of the functions do not quite match up (see clip names for one and timeline status for another example). It also make the rather strange assumption that OSC and clicking with a mouse should be similar experiences. Getting the OSC to provide the same functionality that the GUI provides is kind of pointless, we already have the GUI for doing things in the way the gui works.
joris wrote:
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.
Hmm, well from the users perspective then a transition may appear to be 2 clips playing in a single layer, but as we know a bit about openGL and the under the hood design of resolume we know that this isn't actually the case (presumably another GL surface is spawned for the next clip to be in, when the "transition" happens the old surface is faded through to the new surface - ie each layer is actually 2 media players)
joris wrote:
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.
I would very much like to come and show you (and Bart + Edwin) the problems which I'm having, and the kind of tasks that I'm trying to achieve with OSC. It would be a useful and productive conversation to have face to face, in a way which the internet will never be able to replicate.
I have a lot of comments to add on this topic, but I'm not going to get into a pointless argument, we need to sit down and look at the current stuff for you to be able to understand the problems i'm having. As i have said to Edwin i'm more than happy to come and show you guys the issues i'm facing and put money into the development of the solution.