And just when I wrote, after a year’s absence from the blog, that I’m not doing computer music, I’ve suddenly been swept back into computer music in the past week. It’s Gábor Lázár’s fault. His new album Boundary Object on Planet Mu immediately gripped me and told me to get back to work.
The seed was planted when Kallie and I were in Nashville a few weeks ago. At the wonderful Grimey’s Records I stumbled on Lázár’s Boundary Object on vinyl. I revere his 2015 album with Mark Fell called The Neurobiology of Moral Decision Making, so I decided to buy Boundary Object knowing nothing about it.
When I played it on my stereo at home a couple weeks later it knocked my socks off. It’s very much in the tradition of Mark Fell with the stuttering rhythms and relentless digital synths.
As I sat listening to Boundary Object for the first time, within minutes I was inspired to return to my own explorations of Fell’s rhythm algorithms from a couple years ago. In that project I had fleshed out the rhythmic side of Fell’s music. Picking the project back up, I’ll need to turn my attention to the digital synthesis side.
When I left off with computer music a year ago I had come to prefer using the command line to control live Csound performance. In particular, I liked the constraints of only using the keyboard for input and only using single-character commands which were immediately interpreted with the sensekey
opcode.
This was largely a reaction against the more complex GUI I built for the Looper instrument. Between using p5.js, Web Csound, and lots of mouse clicks and animation, that whole instrument was a bit heavy. I found it liberating to simplify my Csound environment and interactivity with the command line.
But the problem with this approach was that I had no GUI and therefore no good way to quickly monitor the state of a Csound performance. This wasn’t a big problem for a simple Csound instrument, but the more complicated the instrument the harder it was to fly blind without a GUI.
Here was my ideal solution:
Based on the ideal solution above, I had to decide what tools to use on this revived project. I knew I didn’t want to use Cabbage like I originally did two years ago. Cabbage is a wonderful IDE that I’d recommend to everyone, but I wanted more control over the design and styling of the GUI.
But how does the JavaScript in my browser interact with a running performance of Csound on my computer, you might ask? That’s the million dollar question. I was thrilled to learn that Michael Gogins, the talented and tireless Csound developer, recently released his webserver
plugin opcodes. With these opcodes, Csound can run a local server and facilitate communication between a web page and native Csound. Amazing!
I’ve only been working on this project for a week now. So far I’ve been building the GUI in JavaScript and testing out the basic functionality of the webserver
opcodes. I’ve also named the project “Mell Fark”.
Here’s a screenshot of what the original GUI in Cabbage looked like followed by the current state of the JavaScript GUI.
The first milestone of Mell Fark will be porting the original instrument I designed in Cabbage over to this JavaScript environment. That’s what I’m gearing up to now. Most of the underlying Csound code will stay the same, but I’ll have to convert all the code that communicates through Cabbage channels to code that communicates via the webserver
opcodes.
Once the project has been ported into JavaScript I will incorporate the synthesizers. I also plan to add more commands and functionality that will give me plenty of creative options during real-time performance. I hope to report back with updates in the coming weeks.