• they/them/theirs

mcc
@mcc

YouTube link This is a link to a YouTube video. Warning, it starts with a high-pitched noise.

I used to make music on computers. At some point I decided I did not like computers anymore. The reason I decided I did not like computers was Apple, Inc. They kept breaking stuff. I'd get my computer environment all set up the way I wanted, and then Apple would change operating systems or CPU arches or something and all my VSTs would break, and then Apple bought my preferred DAW (Logic) and started making weird changes, and then I lost the copy protection key for Logic in a move. So. I no longer trusted computers.

A few years ago I decided the solutions to my problems were open hardware and embedded devices. After spending a few years exploring this subject, I can report this was not the solution to my problems and in fact none of my problems are solved at all. Read on, and I will tell you about Arduino, and the "Magus", and "OpenWare Laboratory", and my regrets.

I started getting interested in modular synthesizers, which are an overly expensive type of synth that you can "program", or at least control at an often very fine level, by running control voltages over headphone-jack cables, and also in click tracks, which are a kind of tempo synchronization used by very cheap synths like the Pocket Operator drum machines. Both of these can be controlled from the voltage pins of cheap low-end embedded CPUs, that is, devices that don't have an "operating system", your code just runs directly on a chip and any "peripherals" are directly wired into the embedded CPU's pinouts. I thought: This fixes my problems with "computers". "Computers" keep breaking for me because something changes about the operating system. But on embedded, I am the operating system. I could make "songs" out of tiny embedded computer programs that conduct an orchestra of modular synths and pocket operators, and decades could pass but my software would still run the same way on the same chip or an interchangeable commodity replacement, and nothing Apple could do would ruin it.

My first experiments were promising.

YouTube link

This (another YouTube video) is the Stemtera.

The Stemtera is a variant of the Arduino. The Arduino is a vaguely-defined "Open Hardware" platform where some people standardized on a particular way of using popular embedded chips and published all their specs and circuitboard CAD files and such public and free, in a way modeled after software Open Source. Because Arduino is Open Hardware the Stemtera folks could make an Arduino clone and it fully works with Arduino peripherals and the Arduino IDE/uploader thingy (which is way friendlier than the official Atmel or STM equivalents). The advantage of the Stemtera over the Arduino is that the Stemtera is embedded in a Lego block. That is awesome. It is an Arduino embedded in a breadboard which, on the bottom, is literally a giant Lego block.

I briefly thought this thing would solve all my problems by itself. For better or worse, I think like a programmer. I can't really play the piano or guitar. If I try to use a hardware sequencer I just get frustrated with its limitations. When I try to write music I think in terms of the logical steps that produce it, and ultimately the only thing that can embody those logical steps exactly without frustration is code. Back when I made music on computers I literally wrote songs as single C files that arranged sample files and generated tones and output songs as finished WAVs. The video above is something kind of similar; the Stemtera is running a tiny, 250-line C interpreter for a one-off programming language I designed on the fly just to express this one arpeggiated note sequence. Here is the code for the note sequence itself.

(P t--3 0 p8x p13x p0x p8x p13x)
(R t--2 0 t--3 p0 x p8 x p13 x)
R P -2 R P +4 R P -2

That means nothing to you but it means something to me. I was so happy this turned out to be possible. I thought I would be able to scale directly from simple demo sequences like this to complex songs involving multiple devices at once. I was wrong.

The entire rest of this post comes down to the following: I can't get fricking DACs that work.

The Stemtera has 6 ADCs (analog CV inputs), 8 DACs (analog CV outputs), and something like twenty to fifty 1-bit "trigger" pins. Six analog ins, 8 analog outs and an indefinite number of trigger GPIOs ought to keep me happy indefinitely. But the 8 outs aren't real analog outs. They're "PWM". You analogWrite() a voltage value to the pin, and it will jangle very very rapidly between 0 and 1 in a way which on average is equal to the voltage you wanted. In the one video above, this works, because the MiniBrute has a "glide" knob and "glide" is basically a fancy way of saying "average". But if I plug the Stemtera output into a device that doesn't have "glide", or to any of the forty-ish inputs on the MiniBrute that don't have "glide", I will get only horrible noise. The bad kind.

If you have taken a college electrical engineering course you will know there is a simple solution to this. You make an RC filter. You get a resistor and a capacitor of appropriate values and you connect them in series and it will average the values. This is absurdly easy, to an electrical engineer. Because the Stemtera is also a breadboard I would not even need to solder anything. I could just stick the legs of the resistor and capacitor into the breadboard and there's my averager.

I am not an electrical engineer and I completely failed at this. I tried, I really tried. I went to queer open night at the local hackerspace. I learned to solder. I tried so many different combinations of resistors and capacitors from the hackerspace's bins. I never successfully built an RC filter. I never even figured out which resistance and capacitance values I wanted! I found a table in the Atmel manuals that ought to answer that question but I could not figure out how to interpret it.

I tried replacing the Stemtera. I got this thing called the "Dadamachines Doppler" which is basically a FPGA-equipped clone of the Teensy (another Arduino-based "Open Hardware" device) that had two high-quality "real" DACs built in, plus the PWMs and GPIOs of the Stemtera. This one got me closer to my digital-conductor orchestra dream, but on this one the PWMs turned out not to work at all (two and a half years later my Github issue remains unanswered), and I discovered a further problem that the Pocket Operator click tracks weren't as well behaved as I had hoped. Pocket Operators synced fine with other Pocket Operators, but I had trouble getting them to sync with the GPIO triggers:

YouTube link (YouTube link: This is what the trouble sounded like)

After a couple years of remaining stuck on these points and not producing any completed songs I decided something: Although my goal of getting something a little lower level than a Personal Computer to make music on was not a bad one, I had maybe aimed a little too low. This was a spare-time project and I was not going to level up my hardware skills enough to master resistors and capacitors, or to find and install an external DAC, or figure out how to enable the Stemtera's supposed USB capabilities. I wanted to run code on an embedded device. But ultimately I didn't want to rig up my own DACs, or solder, or write USB drivers or whatever. I wanted someone else to do those steps for me.

It turned out "someone does it for you" is something you can just buy.

In retrospect, here is what I should have done at this point: I should have bought an Ornament and Crime, or a Norns. These are fully functional "sound computers" (this is a term I use but no one else does) that let you upload custom code and that have vibrant communities, and they're "Open Hardware". The Ornament and Crime has four CV outputs, four audio outputs and three knobs, and fits in a modular synthesizer rack which would have saved me some desk space; the Norns has two outputs, four USB-MIDI inputs, and first-class support for Lua which I love. Both have screens.

If I wasn't going to buy one of those two, I could have waited another year or three and bought the Korg NTS-1 or NTS-2, which came out too late to help me but do support custom C code and integrate with Korg's commercial products, or even bought a Mutable Instruments Clouds, which is not a soundcomputer but is Open Hardware and Open Source and I could have written my own custom firmware.

I did not do any of these things. I got greedy. And here is where the Regrets begin.

After looking at the various open-hardware soundcomputers and fretting that while most of them covered most of the things I wanted none of them covered all of the things I wanted, I found out about this Kickstarter. The Kickstarter advertised on the one hand a device, called the "Magus", but eventually an entire line of devices, built around a nebulous Open Hardware platform named "OpenWare". There would be three OpenWare devices as part of the Kickstarter but maybe more to come, with maybe eventually third party clones like the Arduino, Teensy and Norns have all received. The three Kickstarter devices had different levels of capabilities and the fanciest one, the Magus, had everything. It had five knobs, twenty dual-mode CV input/outputs, two dedicated CV ins and two dedicated CV outs both of which were bridged to normal headphone-jack i/o (this sounds confusing but it's important: it means the first twenty jacks are for interacting with modular-synthesizer equipment, which uses the Eurorack 5V standard, whereas the last four are compatible with normal audio equipment), 16 LEDs that let you visually monitor the values going in and out of the bottom 16 CV jacks, a screen, a minijack that bridged to 9DIN MIDI, and both a USB jack that let it plug into a computer as a USB-MIDI device and a second USB jack that let it serve as a USB host for midi keyboards and such.

I was elated. This was exactly what I'd been looking for— everything I'd been looking for. No other soundcomputer came close to being able to do all of this.

In retrospect I should have asked why no other soundcomputer had tried to do all of these things.

So here I actually kind of have a problem, writing this, because I like the Rebel Technology guy, he's been very nice to me, and I think OpenWare is a cool project, and I don't really want to say anything bad about the project. However, the Magus does not work. My Magus unit did not work on day one, and after an incredible investment of time and effort on my part it works a little better, but it still doesn't really work, and some of the things that used to work don't work anymore.

OpenWare itself is pretty cool. There are six OpenWare devices on the market by now, four by the Rebel Technology guy and two by Befaco. Anyone who got the OWL guitar pedal ("OpenWare Laboratory"— get it?) or the Befaco Lich is probably completely happy with it. The development interface for OpenWare patches is legitimately incredibly cool, and probably the best thing about the platform— they have an actual web page you can paste C code into, and it compiles it in the webpage and uploads it via WebMIDI, and then you can share your patch directly to a big online listing. (There's also PureData support but I haven't looked into how to use it.)

But Rebel Technology is, as far as I can tell, one guy. And for this Kickstarter he had committed himself to developing, building and shipping three devices, plus the shared firmware for all three, plus this wild online social-media portal for uploading and sharing code. It is maybe not very surprising the device that came out of this Kickstarter has some problems. It is also maybe not very surprising that after the Kickstarter he decided to focus primarily on the new improved devices like the OWL pedal instead of going back and fixing the no-longer-being-manufactured, first-attempt devices from the Kickstarter.

Basically what the Magus is is the prototype for the other five OpenWare devices. Some of its more eye-catching features, like the 9DIN MIDI, the twenty! CV parameter patch points, and the screen, are not present on any future device (the Genius, an announced but unreleased modular-synth device from Rebeltech, has a screen but it's the only one). It seems maybe reasonable to guess that the reason these features got dropped was because once Rebeltech Guy started actually completing the devices he realized he didn't actually have the time to get those features working.

So I'm using a prototype. And it's got problems. The knobs friggin suck; they're sticky and imprecise. The CV outs are noisy. Connecting the USB to a computer increases the noise (depending on firmware version). The LEDs increase the noise (depending on firmware version), so you have to disable them (which depending on firmware version, you may or may not be able to do). There have been various teething problems; the 9DIN MIDI may or may not have ever worked in any version, when I received the device USB didn't actually work, now that I've upgraded to a version with working USB there are new problems with the screen glitching out and the patch selection interface (which is also required in order to change the LED brightness, which remember, is required to reduce noise) only working on maybe 1/5 of bootups. USB hubs do not work. There is a known problem where if you unplug a USB device it will not work again unless you reboot the device (which means if you bump your keyboard in a way the USB cable comes loose you also need to reboot; which in my case currently means I have to reboot 5 more times until the patch-select interface works). On the (deep breath) On the Kickstarter Magus units only there was a problem where the first time you install a firmware upgrade you needed to buy a bootleg STM JTAG debugger from Alibaba, then partially disassemble the device and hook up the JTAG in order to fix a problem in the bootloader that otherwise could have caused upgrades to brick the device. The documentation for how to do the JTAG fix, as well as the documentation for how to build your own copy of the firmware, is written by me, because before I did it there wasn't any (although Rebeltech Guy and This One Other Guy From The Forums did give me an admirable amount of personal hand-holding through the process).

But relatively speaking all of this, including the whole bootleg JTAG thing, are just nitpicks. The real problem is the noise, and the various limitations on the 20 "extra" CV in/outs. The two "audio" inputs and two "audio" outputs more or less work okay (as long as you power from a wall outlet and not from computer USB). But if all I wanted was two working audio inputs and two working audio outputs, I could have just used a Teensy. The thing that made me jump at the Magus instead of the range of other devices, or the other two devices from the kickstarter was that grid of 16 CV in/outs at the bottom of the device. These... kind of don't work. You can only read or write these once per "audio frame", so they have a "refresh rate" of every two to 256 samples, depending on the firmware version. So they're kind of too chunky to use for control input, you definitely couldn't use them to output audio waveforms. Unlike the "audio" in/outs they are not "tuned", meaning, 1 volt in your patch code might not equal 1 volt in the real physical world; this means you can't, in the current firmware, use these CVs to control "notes", because 1 octave will be something either more or less than 1 octave. You could maybe use them for LFOs, I guess. Except also the noise is much, much higher on the "extra" CVs, so high they aren't really suitable for, well, anything. I tried writing a patch that would take chords from a MIDI keyboard and turn them into 3-voice CV output; the result sounded like badly played kazoos, because the notes were not correctly tuned such that notes in a chord were not actually in harmony, and because anyway the pitches were wavering wildly up and down from the CV noise.

Essentially, it turns out there is a reason that the Norns, and the Ornament and Crime, and all the OpenWare devices other than the Magus cap out at two CV outs: because on the inside all these devices use basically the same STM microcontroller from the Teensy, and that microcontroller has two analog ins and two analog outs. If you want more than that you need an external DAC chip, which the Magus has, but the Magus is essentially an orphan project while Rebeltech guy focuses on the newer, more stripped down devices, so he never got the external DAC chip working. Now again I want to stress Rebeltech guy is very nice, and when I reported this issue and got him data about the DAC noise in the forums he dropped everything to investigate it, but then when it turned out to be too complex to fix in a day or so he sort of disappeared again.

To summarize: It turns out that Open Hardware has more or less the same problems as Open Source, that is to say, single overworked maintainers, limited to no documentation, critical github bugs that stay unfixed for years at a time, and everything requiring a lot of manual fiddling before it does anything at all. I thought that jumping into Open Hardware with both feet would at best get me a device that solves all my problems and at worst I'd at least have a fun, educational Project where I learned more about embedded programming, but I haven't really learned all that much because (typical for open source) I've spent so much time just trying to compile and install the damn thing that I haven't gotten to explore any of the "fun" parts of the embedded programming. At one point I actually thought I was going to write QWERTY-keyboard USB drivers for the Magus so I could type sequences in my (P t--3 0 p8x p13x) language directly onto the screen! HUBRIS.

And truly have I fallen prey to Hubris. Possibly I should be blaming myself for my bad experience here. Like I said, the Norns and Ornament and Crime (and the NTS-1, now) are well-established, beloved devices but that wasn't good enough for me, instead I begged my way onto the tail end of a Kickstarter for a prototype device making promises that turned out to be too good to be true. Now I've got a device that (if you count only the features that actually work) does roughly the same things as the Norns, but which I don't actually use because every time I drag it out I wind up spending the entire evening on upgrading the firmware and then filing Github bugs on whatever new problems I've found.


Oh yeah, that video at the top of the post.

So I thought long and hard about the limitations of the Magus, and I thought I'd finally come up with a way to get some good out of the device. I planned out a design for a sequencer based on the Korg nanoKontrol2, which is a cheap, easily-obtained MIDI device with good build quality. The interface for my sequencer is entirely grounded in the nK2; you control it with the nK2's knobs and sliders, so the cruddy knobs on the Magus aren't a problem, and it sends MIDI signals to light up the buttons on the nK2 for visual feedback, so I'm not reliant on the glitching screen. The sequencer controls the playback tempo, so the two-to-256-sample "lag" on updating the parameter CV outs doesn't matter because it can just snap note updates to always fit a frame boundary. And the sequencer is "untuned", like the 0-ctrl, so it doesn't matter the CV outs are untuned because you're ear-tuning to start with. There's still the noise problem to worry about, but I could reserve the two non-noisy "audio" outputs for note control and use the 16 "extra" outputs for either devices with glide or like... filter envelopes, or something, I don't know. Central to this was the cool new feature in the newest OpenWare firmware version, which was that patches now have access to the nonvolatile RAM for file storage. I could save sequences!

Except I couldn't. After a couple weekends making my (incredibly cool, if I do say so myself) OpenWare/nanoKontrol2 sequencer patch, I discovered that in the current version of the firmware patches can load files (eg, uploaded from the web interface) but not save them. It's for like... uploading audio samples, or something. It was actually in one of the early betas, but apparently Rebeltech got worried that if user code could save to the flash they might do it in a loop or something and blow out the flash. That's... pretty reasonable, actually, but it means my patch (which is so cool! it's basically a 16-channel 0-ctrl! the YouTube video only scratches the surface of its features!) is not actually useful. It takes a long time to make a sequence (because you have to ear-tune) and once you've done so you're at constant risk of accidentally bumping the nanoKontrol2 in a way that makes it temporarily disconnect, which remember, means you have to power-cycle the device to make MIDI work again. I'd try to hack saves back in (open source!) but user builds are... one of the things that were working last summer but isn't right now. There's a Makefile that isn't checked in or something.

So! Literally four years separates the second video in this post (with the Stemtera and the MiniBrute) from the first (with the Magus and the nanoKontrol2), yet after those four years I find myself in exactly the same place: Doing a lot of proof-of-concept work to be stuck with a sequencing solution that works in theory but in practice, a short YouTube demo video to show for my trouble, and no music.

Bleaugh.

I bet when the Magus 3 ships in 2030 or something, it's going to be great.


You must log in to comment.

in reply to @mcc's post:

i have a maybe-stupid question: if you want n ins/outs, why not get n/number_of_outs_norns_has norns and hook them up together? just not very elegant, or does networking/controlling a number of those devices together turn into a distributed systems problem?

Okay so the Daisy looks pretty much like the Teensy with the same limitations, but some of these extender modules like the "Daisy Patch" look actually really compelling and... hey, wait a minute! I recognize this module! One of the people on the OpenWare forum actually ported OpenWare to it! So I guess this is potentially a strictly better solution than the OpenWare device I've got because it can literally run OpenWare plus whatever the Daisy community's got. Hm.

So the reason for "why not just wire together multiple Norns?" is very simple: Because the Norns is six hundred dollars (pre-COVID; post-COVID they're $800 and also you can't get one). A similar reason applies to the Ornament and Crime. (There's also the weird problem that both these devices have zero inputs? Unfortunate, that.)

Wiring together multiple teensys, on the other hand... well, that might well work. It would take away some of the simplicity of the approach tho since the whole appeal is writing one short computer program that's directing all the other devices and I'd have to split my one computer program into three or four or however many teensys I have. I guess I could designate one the "conductor" and daisy chain the serial pins of the other three to get raw CV values to set, but at that point I'm actually not doing something all that different from obtaining a DAC part and connecting it to my teensy via serial, and maybe I should have investigated that option more carefully before giving up. Dunno.

Music making gear is an incredibly frustrating situation. I myself have spent an extraordinary amount of time setting up gear and software and relatively very little time actually making music with it. I'm glad we have this cool site now for long-format blogs like this, but I'm sorry you had to deal with all this bullshit. I hope you find your dream soundcomputer some day 💜

I feel this in my bones! The closest I've gotten to DIY hardware is running PureData patches on a headless Raspberry Pi but I have built so many sequencer scripts with novel interfaces based on open-ended MIDI controllers that just…never…quite…come together.

I think if I were in your position I'd consider picking up a commercial MIDI-to-CV device and not worry about ever generating CV directly. You lose a lot of resolution and can't do fun things like treating audio as CV, but it also probably makes a lot of other things much simpler.

Some of those Expert Sleepers DC sound cards do look appealing. Expensive tho... of course, so is obtaining multiple standalone devices that ultimately don't work and have to be replaced.

I was actually a beta tester on the Winterbloom Sol, which is a very affordable PC-to-MIDI-to-CV device that can run onboard CircuitPython scripts-- you can see it in one of the photos in this post-- but unfortunately because what I've got is a beta unit it doesn't have quite enough outputs to be useful for my needs! Maybe I should go back and buy one of the production units...

as someone who still entrusts her computers in the music making Process, i am grateful for this bit of reality for those few fleeting thoughts i get now and then where i want to throw my hands up and go all-in on the hardware route. i hope a more optimal solution presents itself to you soon!!

when I did ... the part about modular and arduino, i side-stepped the reconstruction filter you describe by using 8 digital outs and a R2R-ladder passive 8-bit DAC. I was using it as an oscillator not a CV processor, but one could even tune the R2R DAC to output moog standard pitches directly if wanted. I had done something similar (arduino+reconstruction) in EE school already in a power conversion project.

but that really has nothing to do with your problem, but the reconstruction filtering isn't impossible! whatever is in the teensy-based devices could be copied, more or less. apologies to only be commenting now.

just resistors, i used up 8 digital outs on an arduino uno, one per bit, and tied them all to a resistor network that mixes them properly for the analog value they encode

i think it doesn't apply to you because you need those pins for other things already, but it's been a while since i thought about this and i might be wrong