I’ve been upgrading my monotron upgrade slowly and it’s getting to a nice place.
So far it’s got:
One additional Digital oscillator with several waves and some dirty aliasing tricks
Digital oscillator octave setting (with respect to the analog one)
Control over whether the analog oscillator gets trigger or not
One envelope with A/D/S/R
Envelope -> VCF mode
Envelope -> Digital oscillator mod through a “gater” transformation ( a lot like what the anushri proposes)
I still have to provide some functionality with respect to tuning (fine tune / pitch bend / portamento), VCF key tracking and possibly a noise oscillator and it’s going to be a wrap !
In my previous post, I’ve explained how to add midi control to the monotron’s pitch, gate and frequency cut-off using a Teensy chip.
The good news is that the Teensy’s got plenty of raw power left leaving room for extra processing.
My first upgrade plan was to add an extra oscillator, generated by the Teensy, that would then be fet inside the monotron through its auxiliary port.
Since the Teensy is already the master controller for the monotron, the extra oscillator could easily be synchronised from the same midi control. I had an extra DAC output ready to generate a 12-bit signal out of it, it was time to try it out.
The aux input from the monotron is an interesting beast. It’s worthwhile to feed it with different signal at different gains and look at what happens.
Depending on how hard you drive it, two things are going to happen: first it overdrives naturally, which shapes whatever you put through it but, also, it will ‘choke’ the resonance of the filter making it nearly non-existing. You can think of it as the input signal taking all the headroom of the audio path, leaving no room for the resonance to move freely and add its own bite. The first one is highly desirable while overdoing the second one isn’t. I found in the end that using a 33k resistor gave me a good balance between overdrive and resonance choke.
From then on, it was just a matter of programming. I lifted my dirty digital oscillators from the old arduino piano squealer (thank got for gcc-based embedded and c++) and wired the midi control so that the oscillators from the teensy and the monotron’s internal one followed the same gate and pitch.
This is a description of how you can easily add MIDI to a Korg Monotron using a Teensy 3.0.
The objective here is twofold: First to provide an easy way to control the Monotron’s pitch and filter cut-off via MIDI, then provide an easy open-source extension framework to the Monotron’s capabilities using the Teensy as main MCU.
Since I’m relatively new to this topic, I’ll also try to add extensive information on the process so that it can hopefully help people in the same situation.
I’m extremely grateful to the people that directly – or indirectly – helped me to achieve this through thorough documentation of their projects or by answering my noobish question. Olivier Gillet (Mutable Instrument), Paul Maddox (Vaco Loco) and Tony Hardie-Bick and Collin Cunningham – A huge thanks to all of you.
If you know Teensy/Arduino and basic electronics, you should directly grab the schematics and the teensy code over here.
Introduction
Surprisingly, although the schematics for the monotron have been out for a long time, most of the monotron ‘hacks’ I could find are pretty limited. Either they are intended to CV control which – not having any modular – didn’t appeal to me much or provide a simple, direct midi control of pitch. On top of that, all MIDI kits are closed source so people can’t start building on the existing expertise.
After trying to dissect the ways the shruti-1 worked, it seemed obvious that when driven from an MCU, controlling an analog oscillator/filter could go a lot further than a simple one to one MIDI mapping and I decided to explore the possibilities this cheap unit could deliver.
Out of the box
The first thing to do is to allow some connection to the soldering points Korg gently left for us to use as external control. The easiest way to do that is to solder a series of cable to some kind of breakout box that will allow us to plug or unplug the controlling MCU at will.
This is an extremely well documented video from Collin Cunningham explaining how to do this, so I won’t re-explain it all. After doing this, you will have four wires coming out of the monotron, allowing you to connect an external circuit to pitch control, cut-off control, gate and ground. Even better, this is completely non-destructive – the monotron will continue to work exactly like before.
Choosing the MCU
When selecting the unit that will drive the monotron, I wanted to have something as simple as possible. There are tons of them out there but I wanted something that I could program easily and bootstrap quickly in order to concentrate on the task itself. The arduino could have been a choice but the Teensy 3.0 looked even more appealing. Extremely small form factor, cheap, runs up to 96Mhz and, most importantly, has a build in usb class compliant MIDI mode that provides direct MIDI compatibility without having to do any work.
Generating signals
To control the monotron, we need to generate 3 different signals: one for the Gate (that lets the oscillator signal feed the filter), one for the pitch of the oscillator, and one for the filter cut-off frequency. All those signal are within the range of 0v-5v which is precisely the type of voltage the teensy can deal with.
The gate is the easiest one. It expects 5v to open the gate and 0v to close it, which is exactly what the Teensy’s digital pin will do.
For the pitch and filter cut-off signals, we need to generate a DC signal that varies somewhere between 0v and 5v – depending on how high we want the pitch/filter frequency to be. To do so, we have two alternative: either use the onboard PWM of the teensy (see here for a description on how PWM works) or use an additional DAC. The onboard PWM is an easy option, but it is restricted to a range of 255 values. This is somehow fine for the filter cut-off but won’t be very precise for pitch tracking. One can then decide to either use a reduced octave range and use PWM or use a higher precision DAC.
Not knowing upfront how much tweaking would be needed to ensure correct pitch tracking, I decided to use a 12-bit DAC. More so, since I was going to have a DAC, I decided to use a mcp4822 that provides 2 seprate 12-bit dac in one chip. That way I can use the second channel to generate digital audio from the Teensy itself and add extra digital oscillators to the monotron using the same setup.
Making the connections
1. The Gate:
As we saw already, connecting the gate a as simple as connecting one digital pin of the teensy to the gate input in our monotron breakout-box. In our case, we’ll choose the teensy’s pin 5 to control.
2. The Filter cut-off
Since we decided to control the cut-off using PWM, we need to take care of the fact that we will generate a high frequency variable pulse signal that we want to somehow ‘average’ to a constant DC value using a low-pass filter.
It is usual to use a fairly high carrier frequency for the PWM (in this case I’m using 31250 Hz on the teensy’s Pin 3) and apply changes to it at a much lower frequency (we’ll use 800Hz) so that the high frequencies of the carrier can be attenuated enough through a simple passive RC filter. Looking at the schematics, this is achieved by the R3 and C1, which give us a low pass with a cut-off frequency of about 723Hz.
Also, the monotron doesn’t use the full 0v-5v range for CV control of the cut-off but a lower range. Since the Teensy can only generate either 0v or 5v, we’ll need to lower that voltage using a voltage divider. This is achieved by R1/R2 which will divide by a factor of two the voltage generated by the Teensy.
Finally, we’ll need somehow to accomodate the monotron’s expectation in terms of impedance. Looking at its schematics, the voltage we’ll apply is taking an equivalent path as the LFO cut-off control and since that one is regulated through mR44 (I’m using the m prefix here because I’m referring to the monotron’s schematics), we’ll mimic this behavior and add a 10K (R4) resistor too.
Pitch
Since we decided to control the Pitch using a DAC, we won’t have PWM components in it but we still might have some high frequency noise liked to the DAC’s operating frequency (44.1Khz). To be sure we have a clean signal, we will filter the DAC’s output pretty much the same way as the filter cut-off,provide a stable output voltage using R5/C2. Since the pitch is also fed to the monotron the same way as the internal LFO is and we’ll need to provide a resistor equivalent to mR4, which in our case is R6.
Rough Control
At this point, we have pretty much all of our schematics ready. All we need is to add the SPI connection between the teensy and the mcp4822 (so we can control it) and add the various ground and 5V connection.
Calibrating
We can now start programming the Teensy to send values to the monotron’s pitch and cut-off. However, unless you are extremely lucky, it is most likely going to be out of tune since you don’t know what value you need to set the DAC to in order to have the monotron to produce semi-tones. We end up with something that reacts to not but isn’t properly tuned like this:
So we need a way to calibrate our DAC output.
The easiest way I found was to use Live 9 and comparing the monotron’s output with an instance of Operator using 4 sine one octave apart each, playing a single constant C note. This would lead to a nice identifiable spectrum location
Since I can use MIDI to control the monotron, I generated C notes octave apart and used the pitch bend to calibrate the note frequencies until the spectrums matched nicely
This method has the double advantage of providing a direct ‘rough’ visual cue of where the peaks are located but also generate beats between the monotron’s oscillator and Operator’s when the frequency gets closer providing a more precise cue as how close the frequencies are.
After calibrating the DAC’s output that way, we end up with a nice tuned range across 4 octaves (C0-C4)
The good news is that the voltage control needed by the monotron is nicely linear and there’s no real need to start correcting the pitch inside the teensy. Note also that since the pitch and cut-off knob of the monotron are still active, the result is going to be dependent of those. I end up setting the VCO pitch pot somewhere around 9 o’clock and the cut-off at 12 o’clock.
In the end, we have a nicely controllable unit that is completely sequencable from within any MIDI sequencer.
Code and schematics
I’ve made an archive containing both the schematics and the teensy code. The teensy code is separated in two different file. One – hardware.ino – containing the code dealing with the hardware setup and Pin/DAC/PWM control. The other – monotron_control.ino – hooks up the midi received by the teensy’s usb port to the hardware control. Hopefully it’s simple enough to be understood but if needed, I might go more in detail in a later post.
From here, you got software control over pitch and cut-off. It’s easy to add more code to provide various LFO’s, envelopes or use the first DAC channel to generate additional oscillators fed to the monotron through the aux input….
In my previous post, I reported my investigation on building a synth on the RPi and although for the price it was amazing, the performance didn’t go near what the priciest Beagleboard could deliver. However today got anounced a ‘Turbo mode’ update for RPi that, amongst other things, allows automatic overclocking and better handling of Audio/USB. And boy they didn’t lie !
1. Built-in Audio:
Pre-Turbo
512 samples – 4 voices
256 samples – 2 voices
Post-Turbo
512 samples – 11 voices
256 sampes – 7 voices
The default device still won’t go under 256 for the buffer samples but what a difference. The audio is still a little garbagy (due to it’s architecture) but becomes totally usable.
The next logical step after finishing the Raspberry Synth port of last week was to give a serious go at my game console-oriented tracker, LittleGPTracker. Since the code base isn’t that different -it’s a predecessor of the synth architecture but share most of the basic platform adapters- I wasn’t expecting any major troubles. Indeed, beside SDL not wanting to get initialised when the program is started from a remote ssh session – unless you a root – ; the only glitch was that I never had tried to use my SDL display routine to cope with a 1080p display (since the app is originally targeted at a 320×240 resolution) and a couple of small cleanups have been necessary so offsets were properly dealt with.
Here it is, in all of its SCREENMULT=4 glory
Once again, the built audio proves to be utter rubbish but hooking my cheap behringer interface solved the audio glitches.
I haven’t tried midi out yet and something with hooking up joysticks seems kind of fiddly. Beside that, the app seems to run the 8 mono channels without any troubles. Yeah for lo-fi music engines.
If you want a premature ghetto version, hit me up.
So, after all the exposure of the create digital music post, it is high time I added a little bit of background to the Raspberry Pi-MS Korg combo. I really should have done that before I leaked the video anywhere but ho well, timing was also good with the korg announcement.
So, what’s that thing exactly ?
I’ve been, over time, expanding slowly a new framework for writing sound tools. Sequencers, synthesizers, midi processor.. anything. You could see it as my own little supercollider. Within the framework you can code sound modules (oscillators/filters/effects/..), connect them together in a nord modular/reactor fashion and map controls from those modules to midi. The swiss-knife army tool of the trade. With emphasis on portability. Because I’m extremely interested in embedded platforms and odd/cheap units.
The synth demonstrated in this video is just one application of this framework, ported to the Raspberry Pi.
It’s a simple 2 Osc/2 Filter/1 Envelope graph with proper MIDI mapping to correspond to some of the MS-20 controller layout. It’s interesting to see how important and strong the MS-20 legacy still is. I could have done the exact same demo with a MPK mini, but I’m sure it wouldn’t have the impact this one had. The thing about this controller, beside it’s heritage, is that is implies the promise of hours of fiddling and finding unique sounds. It is something you want to bond with and spend time with, much to the opposite of all generic controller most manufacturers do now. Providing a screen-less software back-end to such a controller effectively completes that feeling of being in presence of a physical loving machine.
Porting to the raspberry pi
Compiling for the RPi was the easiest thing ever. Installing the image is super easy and after connecting it to a wired network and enabling sshd from the install menu, it was up and running. I made the mistake at first to try to cross-compile it as I usually do but the toolchain misses a lot of headers and libraries (SDL/ASLA/Jack) and so I reverted to compiling on the board itself which, after a few usual apt-get and selecting a debian build in cmake went as a breeze. It’s super slow when trying to optimise the code (about 30 minutes while on my old mac it takes about 20 seconds) but other than waiting, there was no headache to get a running executable.
Performances
I was eager to test the performance of the RPi. It is a lot cheaper than the Beagleboard, my previous target for linux-based embedded synth, and possibly less performant so I was wondering what would be possible to do with it. Of course the minimum latency is heavily going to depend on what type of synth you’re trying to run and -although the architecture of the synth is pretty simple- the two filters are quite big models so it’s a fairely ‘heavy’ synth. For comparison, I’ve already gathered the maximum number of voices depending on the sample buffer settings for the beagleboard over here.
HDMI out:
My first test was simply to use the ALSA default driver. It won’t accept latencies below 256 samples which isn’t super good but a 6 msecs latency is not that bad. The results are:
512 samples – 4 voices
256 samples – 2 voices
USB Audio:
Connecting a cheap USB audio also works out of the box
512 samples – 5 voices
256 samples – 4 voices
128 samples – 2 voices
64 samples – 1 voice
Conclusion
The RPi is a very decent plaform and provides a great environment out of the box to develop audio applications. Sure, it won’t be able to support a full polyphonic top of the notch soft synth ala u-He but it has plenty of resources to do a very powerful monosynth, polyphonic cheap synths or trackers (my next effort will be to fully port LittleGPTracker on it).
As such it will surely do some concurrence to the arduino/at mega based world also. It doesn’t have yet the ease of connection to external digital/analog environment as the arduino does but I guess it’s just a matter of time before ladyada & sparkfun rolls simple shields to enable it. The beagleboard stays a also decent contender for bigger project but at the price of the RPi, it’s a steal.
Having spent some time yesterday on tuning my synth filter code for my arduino legovox, I decided to see how the combination of two radically different ATmega based synth (my own squealer and the Shruti-1) would sound: It was time for a quick sunday sound doodle using exclusively those with the piggy under pure dyne for sequencing and drum.
The result is quite nice.. the shruti-1 has some clear quality that mixes well with the rougher grittier sound of the squealer. Once again, I’m baffled by the feeling of control analog pots give when tweaking sound.. even though it’s exclusively digital, it feels like it’s not
The arduino never fails to suprise me. Even for someone like me that has close to zilch knowledge about practical electronics, it is so easy to grasp that the possibilities are mind botteling. In a sense, I kind of find the same flexibility I experience developing software. If you got a bit of luck, it’s just a question of assembling the right pieces together and you get an amazing result.
Thinkering with the idea of using the arduino as a microcontroller to deal with inputs and display for a beagleboard synth, I decided to try start by putting together a simple LCD shield from ADAfruit. I still can’t solder for shit but Dorothée‘s really got into it and is very gifted for it.
Apart from being a nice exercise in soldering and getting used to arduino i/o’s, it provides a convinent way to display information (I’m pretty sure the LCD is exactly the same as the shruti-1) and has a ‘D-pad’ + select which – even though they are very poor in the shield itself- make an extremely cheap prototype to test what kind of UI you could develop if you were to use and arduino for control.
Digging through the information about the LCD, I noticed that adafruit was bragging about the shield only taking 2 pins of the arduino (because it uses a dedicated processor that communicates with the arduino using it’s i2c port) and it made me think about what I could do with the other pins. The LCD shield uses two analog pins from the arduino: 4 & 5. So it leaves a lot of room to play with.
The first thing I thought was that I could easily wire 4 additional pots and fiddle around the auduino structure. But then I thought I could dig what pins midivox shield used and discovered that not only it worked on a total different set of pins than the LCD, it still left all of the analog pins completely available.
Even better, when Collin designed the midivox, he added a serie of hole connectors wired to the original arduino pins so that you can hook them up even when the shield is strapped on the arduino.
The result is that it is actually completely straightforward to build a device combining the arduino, a LCD screen, an audio output a MIDI in/out in and 4 pots.
Add a few Lego Brick and you end up with this:
So for about 80 bucks – if you are lazy and by the premade kit – you have a shell that can become
A synth
A MIDI processor
Heck, even an Ableton remote
If you think about making this from scratch, i.e. lying them part on a breadboard instead of using pre-made shield, you can also have a separate MIDI in & out. Also, since the digital pins are unused, it is even thinkable to add a CV cutoff hack to a monotron and have an extremely cheap Digital/Analog powerhouse.
Once connected, all of the part work exactly as originally intended. MIDI works, the LCD works, the pots get read properly. So now it’s just a question of writing software and have fun.
Apparently there was interest in getting a LittleGPTracker version running on unix embedded board other than the game console. Good thing is: It took roughly 20 minutes to do.
It’s not wired to midi at all but everything runs flawlessly at 17% cpu
About a week ago, reading about the CCRMA satellite workshop on “Interactive design with open embedded computers” - see here and here - made me realise I had to give a go at controlling my beagleboard hosted digital synth using Critter and Guitari’s Arduino pocket piano.
The great thing about any arduino shield you buy – or any arduino based project for that matter – is that in the end all you have is an empty hardware shell that you can reconfigure at will to serve other purposes through programming.
If at first my interest for the arduino piano was to explore it as a standalone synth module and what type of synthesis you could do with such a basic configuration, nothing prevented me to use it as an interface to pick up the knobs and buttons value and send them to a more powerful synth engine – like the beagleboard.
But why?
You may wonder why there could be any value to do such a thing. After all, the beagleboard is a potent little computer and plugging any usb MIDI controller just works outside of the box so you’ve got plenty of controlling options…
What suprised me the most when I developed the arduino squealer synth – and recently when playing with a home grown prototype of the audiono - was that no matter how crude the synth engine was, the fact that you had fine control of the synthesis parameters made it extremely alive. As I’ve written already before, I find it extremely puzzling that in this age of high tech computing where software companies put so much effort in developing complex synthesis techniques, nobody in the industry really cares that to interactively control these synth, everyone is pretty much limited to use the mouse or controllers that have 127 pathetic values.
Compared to that, the resolution of 1024 values that the arduino provides is a huge leap forward and allows a lot more exploration for subtle sweet spots.
Connecting the boards
Getting the arduino and the beagleboard to talk together isn’t a big deal. The arduino has an extremely widespread usb serial port and since the beagleboard runs a standard unix distribution, all you need is to install the FTDI drivers for the serial port to appear. After that, it’s just a matter of having two piece of software (one on the arduino and one on the beagleboard) to agree on the way to communicate.
In order to make things simple, I chose a sub-optimal communication mechanism where the arduino would send text message on the serial line whenever the analog value of the potentiometer would change. Something like
c0:1FF
indicates the first potentiometer changed to the HEX value of 0x1FF.
In terms of communication it’s a bit of data overkill but using the fastest ‘safe’ baud rate reported for the serial port – 115200 – it’s plenty enough for testing 3 pots. MIDI isn’t so much better anyway
On the other side, all beagleboard synth has to do is to open the serial line, listen to incoming data and map the pot value to the internal synth parameters.
Self oscillating filter sweep
To demonstrate the result, I’ve recorded sweeping the filter frequency of a self oscillating LPF using two setups:
First using the MS-20 vst emulation inside Ableton Live and doing the sweep using a usb MIDI controller and then using the beagleboard synth controlled through the arduino pocket piano pots. You can clearly hear the stepping that occurs in the first one while the second one is completely clean. Even though the two filters are fairely different, the difference of behaviour in this case is exclusively due to the different resolution mechanism of the controller
Conclusion
So, if like me, one of your interest in making software run on embedded platform is to be able to interact with a synth in a more ‘physical’ way and not standing behind a DAW with a mouse, having a ‘controller shield’ coupled with the beagleboard make a LOT of sense (or have everything sitting tight together like the beaglebone) . For that reason, I’m eagerly waiting to see if Chris Randall’s BeepCat proposal will ever see the day and, in the mean time, will work on adding a lcd display to the arduino so the beagleboard can display stuff.
