PoE powered OSC controller for Reaper DAW

Gerrit

Well-known member
Open Sound Control (OSC) is an IP based protocol developed as a 21st century successor to MIDI. Unfortunately it didn’t really take off (yet?), there are few Digital Audio Workstations (DAW) that support OSC and if they do it’s often not generic support but more like a ‘MIDI learn function’ where each parameter has to be individually assigned. As far as I know Reaper has the most comprehensive generic OSC support with regards to track information and plugin parameter information. Following up on my earlier experiments I build a development prototype using a 7” 4D Systems display (800x480) and a stripboard with 8 buttons I had lying around.

Interface_track.jpg

A Teensy 3.5 is used because of it’s 5V tolerance, this makes it easy to connect optical rotary encoders operating on 5V. Ethernet is provided by a WIZ850io module mounted on a PJRC adapter board. I created a PCB to hold the Teensy and connectors, there are connectors for 3 serial displays, 8 Bourns EM14 series optical rotary encoders with switch, a continuous foot pedal, two switches and an external board with illuminated buttons. A shift register is used for reading the encoder switches, a buffer is used to drive the external shift registers on the button board.

board-stack.jpgPoE-view.jpg

An Adafruit PoE (Power over Ethernet) splitter (5V, 2.4A) is used to power the controller. Compared to (standard) USB (5V 500mA) PoE can deliver more power over much greater distances so it makes good sense to use PoE. Sure, it requires an PoE network switch but these are more commonplace now given the ever increasing use of audio over IP (AES67, AVB, Dante ,Ravenna etc.) in studio and live applications.
A certain minimum power has to be drawn for the switch to activate the PoE delivery. I did some testing with a Led to check the voltage but this resulted in the LED being turned on and then off again continuously because the current drawn was to low. PoE status can be monitored through the network switch web interface:

switch-poe.png

The controller currently has four modes: track, inserts, plugin and master. The picture at the top shows the track mode. The first and second ‘row’ on the display are common to all modes. On the first row the tempo (bpm) and song position (bars.beats) are displayed. The large scroll wheel on the right is used for scrolling through the song one bar per click. If the cursor is not at the first position of a bar the first click will set it there. This is done using Reaper actions.
The second row is used to display the track number and name and also for the stereo level meters. The track name, and all other names on the display, can be 18 characters long.
The third row displays the current mode or, in case of plugin mode, the plugin name and if the plugin could be identified also the icon associated with the plugin. The fourth row contains the virtual knobs for four parameters and their labels and values. The smaller scroll knob on the right of the display is used for scrolling through the tracks.
In track mode two sends, track panning and track volume are displayed, using the left and right navigation buttons two more sends can be displayed. Notice that the bus track name is available for the sends which is really great.

Interface_inserts.jpg

Inserts mode shows the status of the track inserts, there are two pages of 4 inserts. Unfortunately the insert mix parameter doen’t work so the rotary part of the encoders doesn’t do anything yet in this mode but the pushbutton function can be used to activate or bypass inserts. One of the great things of the Reaper OSC implementation is the fact that the sent names of the plugins, and also those of all parameters for that matter, are the custom names you can enter in Reaper if you want to. In my case I have a bunch of UAD plugins which by default all have names starting with UAD , I changed all the names and dropped the UAD prefix.
The virtual knobs are actually just image stacks as explained in this thread on the 4D Systems forum. ImageMagick was used to generate knob images for each degree from 0 to 300. There are currently 1280 images (120x120 pixels) in the stack, these are stored on an SD card on the display itself. The display is programmed using the free WYSIWYG UI design (Windows) application. The Teensy just sends commands to the display over serial what image to display on which control.

One of the big issues with universal controllers is that they’re universal, they do not reflect the UI of the device they represent, more often than not you have to look twice to figure out what plugin you’re looking at. A more customised view requires meta information on the plugin and it’s parameters which is currently unavailable through OSC so I resorted to adding meta information in the code and identifying a plugin by name. An icon is associated with a plugin to make it more obvious which plugin is selected and the look of the controls can be adapted to better reflect the function. Several meta parameters are associated with a plugin parameter

- Step count
- image offset
- value map
The step count is actually a VST parameter and could probably made available through the OSC interface.
The definition from the VST specification:
• 0 : A continuous parameter. Any normalized value has an exact mapping (0 = there are no steps between the values)
• 1 : A discrete parameter with 2 states like [on/off] [yes/no] etc. (1 = there is one step between these states)
• 2 : A discrete parameter with 3 states [0,1,2] or [3,5,7] (2 = there are two steps between these states)
• 3 : etc...

The main use case for having the step count is to be able to display a button for on/off type parameters. The image offset is used to display different types of virtual buttons/knobs. The value map consists of a boolean to indicate that there is a map, a low value, high value, precision and a unit for display.


Interface_spl.jpg

ImageMagick is also great for grabbing a selection from plugin UI screenshots, resize the selection and add a little sharpening all in one go. The input and mic select parameters are examples of this:

Interface_plexi.jpg

In plugin mode the cursor buttons are used to navigate the plugins (up, down) and the plugin parameter pages (left, right).

All in all the plugin control is working really nice but there’s a nasty fly in the ointment: The text feedback on continuous controllers does not work. In stead of the display text (e.g. “300ms”) Reapers sends the normalised value. As can be seen in the example above, with discrete controls (Input, Mic) the correct text string is sent. The continuous controller values are currently simply converted from the 0-1 range to a 0-10 range for display. If the control is lineair a mapping can be defined as with the Transient Designer attack and sustain parameters in the example above but there are plenty of parameters where this is not the case. In the most important case for text feedback; synchronised delay and other tempo synchronised parameters it is practically impossible to create a mapping as te value is also dependent on the current tempo.

The master mode is used for easy access to master metering, panning and volume and also to set the tempo:

Interface_master.jpg

The Reaper OSC implementation offers a comprehensive interface for accessing track and plugin parameters which goes beyond anything currently possible with MIDI. The number of tracks, sends, inserts and plugin parameters one wishes to receive are freely configurable and be also be changed on the fly by the controller. Although the controller acts on a single track 24 tracks are currently received to make it possible to look up the bus tracks for the sends so that pushing the encoder switch on one of the sends in track mode will take you to the bus track and select the plugin for editing. Holding the insert button and pressing the left cursor button will take you back to the track where you came from. This is a very useful function that cannot be found on any controller currently on the market because it’s just not possible to do this with a MIDI controller.
Now it’s a matter of using this prototype and figure out what buttons are required, transport functions need to be added for sure. When I’m finished with that the next step will be to rebuild my MIDI controller, with 2 displays and 16 encoders, and turn it into an OSC controller.


The code: View attachment Reaper_Track_Controller_20190502.zip

and the KiCad files for the schematic and PCB:View attachment ReaperOSC.zip
 
This is an amazing project and a nice piece of code! it's gone help me a lot!

Thanks:)
It should be relatively easy to adapt the OSC part of the code to your project. The display part is tied to 4D Systems displays although the principle can of course be adapted for use with other displays.
Good luck with your project!
 
Back
Top