For all the musicians out there, here’s a great use for your Raspberry Pi. All the features you would expect from a nice analog synth are implemented in a Raspberry Pi-based polysynth – dual oscillators, LFOs, and phasers – and it looks like there will be a few more features added before the Raspi synth is released.
Even though the ‘synthesis’ part of the Raspi synth already sounds wonderful, getting MIDI on the Rasberry Pi leaves much to be desired. The creator of the Raspi synth thought about using the GPIO pins as a MIDI interface, but because the GPIO pins cannot run natively at 31250 bps (the MIDI spec), the Raspberry Pi has to waste most of its CPU cycles just listening for MIDI traffic.
Right now the Raspberry Pi synth is controlled by a USB-connected MIDI interface, and as you can hear after the break, sounds wonderful. We can’t wait to hear what this synth will be able to do in a few months’ time.
[youtube=http://www.youtube.com/watch?v=qyU7TAi_b04&w=470]
[youtube=http://www.youtube.com/watch?v=4YNUHoek6Zk&w=470]
Uh… really? I admit I haven’t yet read the article. But an ARM chip running at multiple MHz can’t run a software UART, in Rx-only mode on some GPIO pins without using ‘most of its CPU cycles’?
One can implement a single-duplex UART just fine at 31250 bps on an ATTiny85 at 8MHz. I’ve done it myself. Granted this was raw code, no OS to introduce jitter etc. but if Linux can do low enough latency ISR servicing, since the Pi runs a lot faster than 8 MHz it should be able to handle this as a background activity just fine.
I admit I haven’t (yet) done a softsynth with this MIDI, but the software UART part (essentially just sampling an input pin and shifting into a Rx data register) should be the smallest part of the CPU load, compared to doing 44.1KHz audio.
OK, I read the article now.. my bad. I see that according to his article he doesn’t have easy access to an edge-triggered interrupt so it would indeed take a lot of CPU to constantly monitor the input pin.
Any filters coming up?
cool
You could also do the hack way and don’t start oversampling till you are somewhere within the start bit, then start oversampling and use the knowledge of the remaining start bit time to retroactively calculate where you landed. then you stop oversampling cause you have the timing figured out.
But I’m sure one of the proper ways of doing it would be better, as some comments suggest in the original post.
#spendstoomuchtimeonserialprotocols
Gidday, awesome project, have been following for the last week or two.
Couple of questions, does the synth operate within raspbian (or any other OS) as some sort of script or is it an OS in itself?
Also, did you cannibalise your iphone midi interface because there is something about it that the Rpi needs, or would a standard run of the mill dime-a-dozen midi->usb interface from ebay/similiar work just as well?