Correct OSC naming

[0x80]

I just realized that Resolume has its OSC naming backwards.

/layer1/clip5/video/position/values
should really be
/layer/1/clip/5/video/position/values
or
/layers/1/clips/5/video/position/values

Are you aware of this, and if so is there a plan to correct this in the future?

I can imagine you'd want to keep a backwards compatibility mode or something for existing implementations, but it would be nice to at least fix it at some point. For sending OSC to Resolume it is probably not so problematic but for parsing the output it really messes things up.

[drazkers]

Please don't change to this Joris. I can see how this is correct but its annoying to sort out all my old max and touchdesigner tools.

What does this actually enable that the old system doesn't?

[0x80]

I can see how this is correct but its annoying to sort out all my old max and touchdesigner tools.

And that's why I mentioned the backwards compatibility mode. For OSC output the api could be switched as a setting. For OSC input they could even live together since they wouldn't bite each other.

What does this actually enable that the old system doesn't?

It allows you to parse the osc data in a generic way, without knowing the number of layers and clips or having to resort to regexp or other string parsing functions. Every clip and layer currently is a unique symbol, and from a computer viewpoint that doesn't make much sense.

Imagine having a grid of 128 buttons like a Monome, and to control them you give them all a unique name: button1, button36, button97. And in this case you actually know that the grid is fixed. In Resolume its variable of course.

[Joris]

I just realized that Resolume has its OSC naming backwards (...) Are you aware of this, and if so is there a plan to correct this in the future?

Open Sound Control is an open protocol, so there is no front or back really. Any convention we choose is a valid convention.

The current convention is very straightforward and easy to understand for novices. For experienced users programming their own interfaces, it can require some extra work.

So there is something to be said for changing the form of the addresses. Other people have suggested approaches similar to Monome: "/layer/clip/video/position/values 3 2 0.5" would then set the playhead for layer 3, clip 2.

Personally I like the single value approach better, so "/layer/3/clip/2/video/position 0.5" could be an option.

We still need to examine how that works with the gigantic amount of addresses Resolume actually can address ( for instance would it then become "/layer/3/clip/2/effect/5/parameter/2 0.5" as well? )

Either way, for now, we've frozen development on OSC until Res 5 is released and stable. So there are no immediate plans to change our OSC orientation, frontwards or backwards.

We're more than happy to hear your suggestions and wishes though. Share your use-cases and provide examples. That way we know what people are using OSC for.

[0x80]

Open Sound Control is an open protocol, so there is no front or back really. Any convention we choose is a valid convention.

The current convention is very straightforward and easy to understand for novices. For experienced users programming their own interfaces, it can require some extra work.

Forgive me for my biased view as a software developer. I can see how the current approach could be a little easier on novice users.

So there is something to be said for changing the form of the addresses. Other people have suggested approaches similar to Monome: "/layer/clip/video/position/values 3 2 0.5" would then set the playhead for layer 3, clip 2.

I think that would be a mess honestly. I don't think it's very transparent. Just from looking at the message (and not knowing Resolume) you can't know what value belongs to what parameter, because some, like video, don't have a value. Maybe the approach works for Monome because they have a simpeler model to work with.

It would work as
/layer/clip/position 3 2 0.5

but then obviously you loose the video/audio namespace.

Personally I like the single value approach better, so "/layer/3/clip/2/video/position 0.5" could be an option.

Yes I totally agree It's also really similar to REST like interfaces in HTTP which tend to be very self descriptive.

We still need to examine how that works with the gigantic amount of addresses Resolume actually can address ( for instance would it then become "/layer/3/clip/2/effect/5/parameter/2 0.5" as well? )

Yes, why not? I don't see any problem with that.

It would be nice if additionally the parameters of an effect could somehow be addressed by name instead of index, but I guess that really depends on how effects are implemented. I don't think it is worth much effort as in reality you would probably connect the relevant effect parameters to the dashboard anyway.

Either way, for now, we've frozen development on OSC until Res 5 is released and stable. So there are no immediate plans to change our OSC orientation, frontwards or backwards.

We're more than happy to hear your suggestions and wishes though. Share your use-cases and provide examples. That way we know what people are using OSC for.

I currently only have one OSC feature I'm really missing for the type of work I'd like to do with Resolume; the ability to jump to mm:ss::frame (or beats when using bpm) in a video, and set its loop points

I know about the cue points, but I need many more.

I can work around it using the clip position directly via OSC, and faking the loops by doing manual jumps that requires sending a lot of messages (especially with multiple layers) and I don't think it results in the same smooth playback, due to timing jitter and rounding errors, especially with short loops.

But thanks for the info Joris. Very curios to find out what you guys came up with for version 5.

[Oaktown]

/layer/3/clip/2/effect/5/parameter/2

it would be great to be able to address parameters discreetly rather than having to use the active clip as it is currently set up: /activeclip/video/effect5/param2/values

Also, just to add to the conversation,

I think that all things being equal, [/layer/3/clip/2/effect/5/parameter/2 0.5] is much easier to work with than the monome standard [/layer/clip/effect/parameter 3 2 5 2 0.5]

[alfaleader]

No,

Code: Select all

/layer/clip/effect/parameter 3 2 5 2 0.5

is the correct way of doing things with OSC. When you are programming

Code: Select all

/layer/1/clip/2/...

is the same as the system now (address is just a string, so why bother adding another / ?

I would love the normal

Code: Select all

/layer/clip/effect/parameter 3 2 5 2 0.5

OSC. Would make it lots easier of checking incoming messages.

[0x80]

No,
/layer/clip/effect/parameter 3 2 5 2 0.5
is the correct way of doing things with OSC. When you are programming

That's a bold statement. Care to point us to some references to back up that claim?

An osc message contains two parts, the "url-like" address of the object and then its parameters. I would argue that
/layer/3/clip/2/effect/5/parameter/2 is the actual address the object you're talking to.
and
0.5 is the parameter.

Just because we are dealing with arrays of objects doesn't mean the index becomes the parameter.

is the same as the system now (address is just a string, so why bother adding another / ?

Because then you can instruct the computer to break down the structure by every / and easily extract the index of the object in relation to their root. I think it makes sense from a programming viewpoint. layer3 is a layer, so its root is layer(s) and the index is 3. You would have to use more complicated pattern matching to extract the index from symbols like layer3, layer4.

Look at how urls are constructed in RESTful like APIs: /customers/2345/orders/23/products/3

This is done because it allows for easy pattern matching. It could in theory be
/customer2345/order23/product3

In web development no one would possibly consider that a good approach. I don't see how processing osc address strings is different from any other url pattern.

Like Joris said OSC is an open standard, but apart from being easy to read for novices, /layer1/clip3/effect5 is not something a computer would prefer. So assuming your aim is to write efficient and flexible code I'm tempted to say it "is the correct way of doing things"

If you use
/layer/clip/effect/parameter 3 2 5 2 0.5

it becomes unclear what part of the data is making up the address of your target and what part is data to be delivered to that object. For all I know a clip could have one effect always, and 2 0.5 would be its parameters. It's not at all clear, and I don't see how you can prefer parsing that. For Max and Pure Data where you have a dataflow structure this would be hell I think.

[alfaleader]

Yeah you're right, there is no "standard OSC".

But how I see it, your /bla/bla/blaaa is an address and the variables are the things you want to send.

If you have /layer/clip/connect 3 2 1 you can easy match the address with:

Code: Select all

if(oscmessage.address == "/layer/clip/connect"){ ...}

The active layer and clip are more variables (because you have layer1, layer2, layer3 ... and don't fit very good in your address and with the address matching in available libraries. Now I have to do some extra coding for getting the layer and clip number, would be a lot easier if we just got /layer/clip/connect 3 2 1 (and maybe also legacy /layer3/clip2/connect support so old programs would still work).

[0x80]

But how I see it, your /bla/bla/blaaa is an address and the variables are the things you want to send.

Yes, and just because there are two or more bla's at the same level in your hierarchy doesn't mean the index becomes an argument is what I was trying to explain. bla/blas/2/blaaa is still an address to an object as much as /bla/bla/blaaa is.

If you have /layer/clip/connect 3 2 1 you can easy match the address with:
CODE: SELECT ALL
if(oscmessage.address == "/layer/clip/connect"){ ...}

What you're doing here is absolute string matching, not string pattern matching. If you use pattern matching you'd have no problem extracting the index as long as its surrounded by something like "/".

Code: Select all

The active layer and clip are more variables (because you have layer1, layer2, layer3 ... and don't fit very good in your address and with the address matching in available libraries. Now I have to do some extra coding for getting the layer and clip number, would be a lot easier if we just got /layer/clip/connect 3 2 1 (and maybe also legacy /layer3/clip2/connect support so old programs would still work).

I don't agree obviously. Like I said, they are not variables they are objects which live at an index somewhere in your object path structure. Maybe it's easier for you in your situation with your library (open frameworks?), but for example in something like Max or PureData this wouldn't be feasible at all.

In those environments you'd use something like [route /layer/1] and route[/layer/2] (which is basically string pattern matching) to isolate all messages for a single layer. You can't do that with the addresses you're suggesting. You'd have to parse the data of every messages to find out if you're interested in it. And that applies other libraries as well. I think you should be able to figure out from the address of the osc message if your interested in the data. That's why you should keep address and variable data separate.

Maybe your can point me to an OSC implementation with a bit of hierarchy that includes arrays of object with child nodes (like layer) and that uses the structure you're suggesting? Monome doesn't count for me, because it has a simple and pretty much flat object structure which they decided to address as x/y.