Audio-Reactive DMX via OSC (No MIDI)

[Jeffrey Millsaps]

This is my first time posting, as well as my first foray into any substantial OSC scripting.  It's a bit convoluted, but here is a way to get your light board (an Ion in this example) to react to audio and mic cues in QLab if you don't have the resources to use the OSC/MIDI method posted in this group.  Some techniques were borrowed from the DiscOSC writeup in the QLab Cookbook.

Basically,  there is a set of OSC cues designed to send intensity levels to the Ion.  In this example, I used three submasters to which the LD had assigned certain effects.  Each submaster has its own set of cues affecting the intensity by multiples of 10, running from 20% to 100%.  The liveAverageLevel command is being used to take readings from a mic cue that has been replicated and adjusted with band passes to isolate high, mid, and low, like with the other methods of achieving this effect.  The difference here is that the level reading is then being applied to the target number of a start cue set to autofollow, and another start cue set to keep the whole thing looping every 0.1 seconds.

The problem I initially found with this method is that the liveAverageLevel command returns values to a precision of 6 decimal points.  To get a value that would correspond to the number of cues available to manipulate light levels, that meant my level-reading OSC cue looked like this:

/cue/123/cueTargetNumber #/cue/LO/liveAverageLevel/1 .000001 .000009#

When inserting the returned values into a cue target number, QLab converted them into scientific notation, so the numbers for my cues controlling the submasters end up being 1e-06, 2e-06, 3e-06, and so on.  When it's all running, it looks like what you can see in the following video.

https://drive.google.com/file/d/1_TARtuX7IoxLBtKw9Lt7k5CtSQG4GmUJ/view?usp=sharing

Adjustments could be made to make more finely tuned submaster adjustments, and to increase the rate at which level readings are taken, but this seemed like a good starting point.  I imagine there are a number of other variable you could affect on your lighting console as well, but I didn't have time to dig through the Eos OSC dictionary any further.  As I said, it's a convoluted method, but it's what I could come with, given the tight schedule I was on and the fact that these are the first OSC cues I've used that weren't just hitting Go on another instance of Qlab.  Hopefully this post and cue file will save someone else the headache of figuring it out, or at least generate some responses that show me a better way to go about this.

[micpool]

I'm probably missing something fundamental here, but why do you need this stepped levels approach? Why cant you just use /eos/sub/18 #/cue/MID/liveAverageLevel/1 0 1#   ?

[Jeffrey Millsaps]

I feel like I'm missing something fundamental as well.  The first thing I attempted was the OSC string you suggested, but I was getting no response from the Ion.  I just went to try it again to make sure I'm not out of my mind.  When I stuck the same liveAverageLevel query into a different OSC cue to output the returned values to text, I was seeing numbers that went out to 6 decimal places, albeit still between 0 and 1.  My assumption was that the Ion didn't know what to do with the extra digits, and so was ignoring the entire cue.  Is there a way to constrain the output of liveAverageLevel to a less precise value?

[micpool]

 A float value  in OSC is a float, and a value shouldn’t be ignored because of its precision. of course, ETC may have other ideas!

The best way to check whats going on with the Ion is to send it fixed values 0.1. 0.21  0.312. O.4123 etc. and see at which value it fails.

If it does need truncating you could use Osculator  to do this.

Mic

[Jeffrey Millsaps]

I'll check that out.  Thanks for the tips!

[Dylan Uremovich]

Years later this helped me out immensely! Was able to use an audio file to drive sub intensity for an on-stage Alexa idea. Thanks!