Simple Musical Interfaces for Sporth using OpenGL bitmaps

2017-03-26

Pondering

Lately, I've been thinking about graphical user interfaces in music. Not having them for so long has given me ample to time to question what they represent. I've avoided including them in my sonic ecosystem of software. They are just hard to do well. Libraries for handling graphics like GTK and QT are large and would add a great deal of complexity to my work. And even if you get the technical stuff figured out, you still are stuck making things look and feel good. It's a set of challenges I'm just not sure about investing the time in solving.

More importantly, I avoid graphical utilities out of principle. Now that I build most of my tools, I often ask myself "do I really need it?". After years of working with text-based highly modular environments like Csound, and then building Sporth, many graphical interfaces feel restrictive and limiting for sound design. Indeed, even when I was knee-deep in commercial software like ProTools or Reaper, I found using the "easy-to-use" mouse-based interfaces to be tedious and sluggish, especially with the rise of high-quality touchscreens. Many widgets common in DAWs are really skeumorphic representations of analog hardware, designed for a generation of technophobic audio engineers. Let's be honest here: virtual knobs make no sense.

Despite all this, I'm coming around to the fact that there is indeed something to be said about having a visual interface of sorts. I'm just not quite sure what that means for me yet.

This past week, I've taken some small steps into the frightening world of graphical user interfaces, building some small graphics utilities based on interfaces I've enjoyed working with in the past. They are implemented as simple Sporth plugins, which generate simple signals to be used within a Sporth patch. Not only are they simple, but they are also small. I've opted to use glBitmaps to draw the interfaces onscreen. To my surprise, they have pretty fast to draw, leaving plenty of CPU room for audio.

Seq16

The first thing I built was Seq16.

Seq16 is a 4-channel, 16-step sequencer. I designed this to make it easy to build drum loops. Seq16 is driven by a sample-accurate clock signal generated by Sporth. Each channel generates a gate signal, stored in a Sporth table that Seq16 creates. These signals can be mapped in many ways to trigger sounds in Sporth.

Seq16 has the ability to save/load pattern data in the internal Soundpipe audio (SPA) format This has proven to be very convenient so far. However, I plan on changing the format to be text-based rather than a binary format.

Tracker3

Tracker3 is a 3-channel, 64-step sequencer.

This is designed specifically to quickly build up small melodies and monophonic instruments. I am proud to say that is may be the stupidest music tracker in existence. No effect columns, no instruments, no patterns. Nothin. Just three channels, choice of note and octave, and 64 steps.

Similar to Seq16, Tracker3 stores signals for each of it's 3 channels via Sporth tables. Each channel has two components: a note component and a gate component. The note component stores the current pitch as a midi note number, the gate is a binary signal indicating if the note is on/off. These signals can be fed into oscillators and envelopes to drive monophonic instruments.

Building on top of Seq16, Tracker3 saves/loads/reloads patterns using a minimal version of Runt. The advantage of this is that sequences can be edited in a text editor in addition to the tracker sequencer.