Page 2 of 2

Re: Correct OSC naming

Posted: Wed Aug 20, 2014 15:51
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).

Re: Correct OSC naming

Posted: Fri Aug 22, 2014 17:44
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.

Re: Correct OSC naming

Posted: Mon Aug 25, 2014 16:44
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

Re: Correct OSC naming

Posted: Mon Dec 22, 2014 22:02
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 ;)