Correct OSC naming

"Where is Feature X? I need Feature X! How can you not have Feature X?"
Post Reply
alfaleader
Hasn't felt like this about software in a long time
Posts: 66
Joined: Sat Jul 24, 2010 17:48

Re: Correct OSC naming

Post by alfaleader »

The problem is pattern matching does use a lot more resources then just comparing 2 strings, what might be very important while using microcontrollers (I use them a lot, and every Kb RAM and cpu cycle saved is important).
Top
0x80
Hasn't felt like this about software in a long time
Posts: 52
Joined: Fri Apr 19, 2013 10:59

Re: Correct OSC naming

Post by 0x80 »

If resources like that are a priority maybe you should stick to MIDI? ;) But seriously OSC isn't a particularly efficient protocol. Just like a Monome device isn't talking OSC but using the serialosc deamon to convert it.
Top
alfaleader
Hasn't felt like this about software in a long time
Posts: 66
Joined: Sat Jul 24, 2010 17:48

Re: Correct OSC naming

Post by alfaleader »

MIDI can just be used on 1 computer, the big plus of osc is that you can use a network (so multicast, broadcast...). Much more flexible in the use then midi
Top
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: Correct OSC naming

Post by sleepytom »

Firstly I feel the attempt to make OSC match the GUI and be simple for newbies are both massive mistakes which make it neigh on impossible to do anything really nice with the OSC interface.

The OSC interface should provide ways to control the capabilities of Resolume, not ways to do virtual mouse clicking in the GUI.

Any string processing of numerical values is BS, as is string processing to get an index position from a URL. It's really slow in lots of environments and makes it easy to miss the data in the flood of values being sent out.

My big hope for R5 is that we might see the concept of some kind of callback system via OSC eg- /Resolume/Get/Thumbnail (1,1,1); Which returns a blob with a PNG thumbnail from Layer1,Clip1,Frame1. Or /Resolume/Get/TimelineMode (2,4), returning the timeline mode of layer2, clip4.

When setting values it makes most sense to do stuff like /Resolume/Connect (1,4,2) - plays clip4 from layer1 in layer2.

These features would make the OSC interface loads more powerful, stable and easy to use. Lets not kid ourselves the current way OSC works is NOT easy to use for newbies, and newbies are not doing anything via OSC anyway. Allowing better considered access to the functions via arrays of variables on address of functions is simpler ad much easier to implement in the existing OSC tools such as Lemur.

The purpose of OSC as far as i'm concerned is to allow the creation of dynamically adjusting task specific GUIs on platforms such as Lemur or in custom control systems. To make the most of this it is vital to have some kind of callback system to know which interface elements are required to work with the currently selected object.

Doing anything in systems where the variables are hidden halfway up a URL string is really time consuming (both whilst coding and during runtime) R5 needs to address this issue ;)
Top
Post Reply

Return to “New Features”