Table of Contents

It’s been a while since my last update. I’ve made a few commits to the https://github.com/showcontroller/go-osc repo, but there’s been quite a bit of work that I haven’t published. I’ll start off with talking about the raspberry pi zero w based cue light I’m working on.

RPiLx

Discovery via zeroconf/mDNS is now possible for RPiLx. This means you no longer have to find the ip address of the pi via your dhcp server or netmap/whatever. This means applications will be able to automatically find any cue lights on the network. I’m working on a central management application where you can manage all the devices on your network from a webapp. The cue lights will have an optional web control panel, so you can control them easily from any device without having to use an application like QLab to send OSC.

There are more planned updates for RPiLx. I’ll be adding OLED support soon, so a 1″ can display some information, like the current or upcoming cue. The case I’m using already supports this, so it’s just a matter of soldering up the screen and writing a little code. As of now, the devices only listen on TCP, but I’ll be adding a configuration file so you can have it listen on UDP in addition to TCP.

XeOSC

The biggest thing I’ve been working on is another application called XeOSC. It’s aiming to be a full fledged UDP/TCP OSC router with some advanced features. XeOSC allows you to define inputs, outputs and routes. Each input/output listen/sends on one port/interface combo. Routes can accept messages from multiple inputs and send those to multiple outputs. There’s some limited path matching capability for now, but the main thing that I’ve added is Lua scripting support for all received messages. This allows for some very advanced logic and routing.

XeOSC also makes certain things quite easy. For instance, linking up two devices that only act like TCP servers. EOS and QLab both support OSC over TCP but do not support acting as TCP clients. If you want to be able to trigger a cue on QLab from EOS and vice versa over TCP you need an application in the middle that can act as two clients and route messages between them. In XeOSC all it takes is defining two outputs and one route in a config and they’re connected. Trying to do this in other applications is quite unintuitive.

A good example of when Lua scripting support is really nice to have is when you’re trying to connect an input device, like a DS4 controller, to a device that’s expecting a number in a completely different format, like a XR12 mixer. A DS4 controller’s analog sticks output their position as an X and Y coordinate between 0 and 255. The center point is 128,128, so if you want to increase the volume of the fader on the mixer if you move the stick up, you need to do some math. Doing this in other applications can be time consuming or tedious or may not be possible at all. Having scripting support makes this quite easy.

XeOSC also allows you to send one input message to multiple output destinations. If you ever want to run redundant QLab machines for instance, this can be quite helpful. You can have a device sending OSC commands of /go and have that sent to both machines so they stay in sync. Controlling multiple cue lights from the same command would also be quite easy, so this may save you having to make multiple network cues in QLab and save you a bit of time programming.

I plan on adding device support to XeOSC so you can connect devices directly without the need for a bridge. That means instead of having to have ds4control sending OSC to XeOSC, DS4 support will be integrated. I plan on support more devices in the future like MIDI controllers and TP Link smart outlets. I’d like XeOSC to become an all-in-one platform for show control. An event system for cueing other than message receipt will be added at some point. It’s presently command line only but I’ll be adding an integrated web server and web interface to it. Should be a bit easier than a cross platform GUI.

What’s To Come

As for what’s to come, I’ll have another post/video up explaining how to build a RPiLx pretty soon. I want to make sure it’s reliable before I go around telling people to use it. So I’ll have to clean up the code a little and figure out how to build a package for distribution for it. Maybe I’l make a whole raspbian image to download if there’s enough demand.

I’ll be getting in an Enttec DMX USB Pro soon and I’ll be using that to add some DMX control to XeOSC. Artnet or sACN support probably wouldn’t be too hard to add either. Probably won’t be a full fledged light controller or anything, but enough to control some studio lights or a DMX fog machine.

I’ll be releasing the full version of RPiLx prior to me putting out XeOSC. Expect it to be a while before it’s out, as I want to make sure it’s in a working state. I’ll keep posting updates here, hopefully with a bit more frequency.

If you have anything to say, feel free to leave a comment or reach out to me on reddit or something. I do like the feedback and I take it in to consideration when I develop features.