Text data over OSC

FFGL, OSC, GLSL. If you like abbreviations, this is the forum for you
Downtown
Is taking Resolume on a second date
Posts: 46
Joined: Mon Dec 14, 2015 21:56
Location: St Louis, MO

Re: Text data over OSC

Post by Downtown »

What does not work (but would be nice):

/composition/link1/name
(dashboard effect names, per layer or comp)

/activeclip/name

/layer1/name

This is using Resolume 5, however

Downtown
Is taking Resolume on a second date
Posts: 46
Joined: Mon Dec 14, 2015 21:56
Location: St Louis, MO

Re: Text data over OSC

Post by Downtown »

Zoltán wrote:Resolume 6 supports text via OSC.
You can ask for the names by putting a question mark before the addresses.
Addresses for names are pretty straightforward, for example layer 1 name:
/composition/layers/1/name
to set it send a string to this address.
As another example, a column 3's address is
/composition/columns/3/name
A clip's address is
/composition/layers/3/clips/5/name
you see the scheme right, this is layer 3 clip 5.
The composition BPM's address is
/composition/tempocontroller/tempo

You can find out any address and expected value type and range by going to Shortcuts menu-Edit OSC and clicking on colored items.
Downtown wrote:Also kind of disappointed I can't do a metronome over OSC.
Would you want to get a metronome signal via OSC?
Now that I'm using Resolume 6, I've got a couple problems.
First, and this is just my problem, many of the OSC addresses are different, meaning I have to re-address 400 functions :(
Second, I added the "name" address to a few functions, but it doesn't work nearly as well as it did on Resolume 5. When I change decks, the names of the buttons update, but not all of them. It's random which ones don't work, but layer 1 clip 1 always works, and layer 1 clip 4 never works, although the address is correct and it's pointing to the correct OSC. Additionally, deck names do not work unless I rename them in Resolume (which I guess sends the OSC signal), and the deck no longer appears as active when it's selected in my Lemur interface, as if it's not receiving the OSC data (all OSC outputs are turned on).

Downtown
Is taking Resolume on a second date
Posts: 46
Joined: Mon Dec 14, 2015 21:56
Location: St Louis, MO

Re: Text data over OSC

Post by Downtown »

After testing the above, it appears that correctly addressed clips also only update the names when they are renamed, but not when I switch decks. That ruins my OSC dreams until this is fixed :(

Edit: example YouTube video: https://www.youtube.com/edit?o=U&video_id=W99Ay4DQoFA

Downtown
Is taking Resolume on a second date
Posts: 46
Joined: Mon Dec 14, 2015 21:56
Location: St Louis, MO

Re: Text data over OSC

Post by Downtown »

After tinkering it with quite a bit, not much has changed. I get a little better performance now that I updated to the Fall Creators Update but some of the text data for clip names still does not send. It's not random which ones don't work. The code is accurate, because it works sometimes, and it's the same code as the other buttons, just with a different address.

What is also still a problem is that I still don't receive x (on/off) data for clips or decks I select. It's just a button with no back and forth communication.

Also, deck names are still not sent via OSC unless I start Lemur first and R6 second, or when I rename a deck.

Any advice? Not sure why OSC was seemingly overhauled when it worked amazing for R5, but I'm sure there must have been a good reason.

Downtown
Is taking Resolume on a second date
Posts: 46
Joined: Mon Dec 14, 2015 21:56
Location: St Louis, MO

Re: Text data over OSC

Post by Downtown »

Pretty disappointed in the lack of responses, and also that v6.0.3 didn't seem to solve any of these issues.

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: Text data over OSC

Post by Joris »

OSC has always been a monster feature that's difficult to develop. It's insanely powerful and insanely versatile. That makes it especially difficult, since it can be used for so many things and we have to cover all those bases in a single implementation.

For instance, we've received lots of complaints about the granularity of OSC commands and the volume of output data on 5. This is what we've addressed on 6.

It can be expected that now not everything works exactly the same as before. After all, we're only human and we can't possibly foresee every possible use case. So when calling us out on this, please go easy on us. We've got a shit ton of things we need to work on every day. A long thread filled with lots of examples and broken use cases generally will get glossed over, since we can't realistically solve everything in one go.

So what I suggest is the following: Name the one thing that you're missing in the OSC implementation right now. Try to boil it down to a single use case. We'll then do our best to make that happen in an update. And like that we'll chisel at taming the beast that is OSC together.

Downtown
Is taking Resolume on a second date
Posts: 46
Joined: Mon Dec 14, 2015 21:56
Location: St Louis, MO

Re: Text data over OSC

Post by Downtown »

Joris wrote:OSC has always been a monster feature that's difficult to develop. It's insanely powerful and insanely versatile. That makes it especially difficult, since it can be used for so many things and we have to cover all those bases in a single implementation.

For instance, we've received lots of complaints about the granularity of OSC commands and the volume of output data on 5. This is what we've addressed on 6.

It can be expected that now not everything works exactly the same as before. After all, we're only human and we can't possibly foresee every possible use case. So when calling us out on this, please go easy on us. We've got a shit ton of things we need to work on every day. A long thread filled with lots of examples and broken use cases generally will get glossed over, since we can't realistically solve everything in one go.

So what I suggest is the following: Name the one thing that you're missing in the OSC implementation right now. Try to boil it down to a single use case. We'll then do our best to make that happen in an update. And like that we'll chisel at taming the beast that is OSC together.
Thank you for your response. Most of my concern was a lack of response at all. I love the program and I know you all work very hard on it.

My largest problem is the fact that when I switch decks in Resolume over OSC, it does not update all of my clip name labels. This wasn't an issue in Resolume 5, it worked very well. Example video: https://www.youtube.com/watch?v=W99Ay4DQoFA
I have OSC set to use bundles. Turning this function off doesn't seem to affect anything.

2nd runner up would be that I can no longer see which clip is currently active, which also worked fine in Resolume 5. You can see that in the video as well.

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: Text data over OSC

Post by Joris »

Thanks. We'll look into this.

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

Re: Text data over OSC

Post by sleepytom »

Yes i can confirm that the info sent on deck load is not working correctly. I'm getting random missing clip names as well as some clips simply not updating their "connected" address - this is a pretty savage deal breaker for my use case currently. A related issue is that connected clips from the previous deck do not disconnect when they should. Once the new deck is loaded any clips from the previous deck will stay stuck on connected = 1.

I'm really keen that OSC gets more attention in 6 than it has done in 5 (or 4 or 3!) - there is so much that can be done with OSC that really opens up the possibilities of the app, but whilst the implementation is buggy it makes it impossible to develop robust tools which interact with Resolume.

The new address pattern in resolume 6 is excellent though - far easier to deal with than the old one. I'm really hoping that we will get a system to turn on OSC output on specific addresses by sending an OSC command into resolume though. Without this any OSC based tools require a lot of user interaction to get working, which will ultimately mean they are unable to gain widespread appeal.

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: Text data over OSC

Post by Joris »

At the risk of derailing the thread, I'm starting to wonder whether we're not abusing a control protocol to represent software state. Open Sound *Control* is meant to provide very low latency and high precision control over parameters.

What you're doing now, is gathering a lot of control data, and then reverse engineering what the state of the software is from that. This means we have send a shipload of data on events like layer selection, otherwise you will never know what effects are applied on each layer. This data can change, but it's unlikely to have changed with every layer select. Deck changes work similarly, you need to process an insane amount of control messages to figure out what the new deck looks like.

What if instead of burying you with control data, we provide a single object (formatted like an XML or JSON or something easily parsable), containing the state of Resolume. ie "This is the current composition, it has this many layers with these effects, these are the current clips in this deck, etc etc". You can extract the data you need from this object, and then use OSC to control it.

Of course that object is going to be huge, but you don't have to send it on every parameter change. We can limit the frequency it's being sent, send it only on change, or on request. Also, you only have to parse the part you're interested in, instead of having to sort through every incoming message, to see if you need it or not.

Just thinking out loud here.

Post Reply