Practical Limits of current OSC implementation
micpool
The OSC in Qlab is a fantastic thing. It allows you to do things, like set a bunch of cues to loop, in a far easier way than applescript, and if it encounters an error (like there is no loop parameter on one of the selected cues) it just ignores it.
It's brilliant for communicating with other devices, and other Qlab machines.
It's great for simple remote controls for plotting in tech using iPad remotes.
Wildcards are stonking!
Where you hit the practical limits of the current implementation is in real time control of parameters like sliderLevels in audio cues and geometry in video cues.
I have been experimenting with a 4x4 autopanner on a LEMUR (on iPad). This puts up to 4 pan controllers on an xy controller and manipulates the matrix levels in the selected audio cue. (see screenshot)
While the implementation functions and is rather slick, the audio quality would not be usable in performance. Manipulating even 4 matrix values continuously with real time OSC controllers causes discontinuity in audio levels. By the time 16 are being constantly updated, Qlab is completely flooded.
This video demonstrates the LEMUR module controlling Qlab. The audio is off a stereo webcam mic. so the quailty isn't great and there is no surround, but the Qlab audio glitches and discontinuity are audible. The Qlab display is designed not to try to update continously so you will only see the matrix values change when the controllers pause, although the audio meters are pretty much real time so you can see the quad panning happening.
If you have a LEMUR set up you can download the LEMUR and Qlab workspace files here
If Qlab is going to allow real time control with continuous OSC data then it probably needs to apply some regulation and smoothing of the OSC data stream.
In traditional MIDI sequencers this problem was addressed with various MIDI thinning options.
This sort of use of OSC with Qlab is clearly at the current limits of what the OSC implementation can do. I suppose the question is, is it easy to improve in subsequent versions(or not), and should the current implementation protect itself from floods of OSC data in some way?
Mic
