Intermediate steps before progressing to fpga.

Great projects!  I'm actually planning to do something similar over the next few years.  I've been totally swamped with family obligations over the last few years which has minimized the time I've been able to invest in FPGAs and single-board computers, but those obligations should be almost over.  I played clarinet and keyboards when I was a kid, but my life's work and other things minimized the time I could spend with music.  I'm hoping that will change very soon.

Modern technology allows one to do keyboard scanning and music synthesis at amazingly low cost.  There's tons of free resources on the 'net, including samples of antique instruments that can be brought to life with a modern keyboard and cheap computing.  My first projects include:

1.  Get a modern 76-key keyboard -- e.g., a used Yamaha YPG-235 -- and use it as is to get my keyboard skills back, but also use it as a MIDI controller for a home-brew synthesizer, probably based on a Raspberry Pi 2.  I want to be able to do things like historic tunings, which you can't do with an inexpensive synth like the YPG-235, but a home-brew synth can do anything.

2.  Get an old organ console with 2 manuals and full 32-note AGO pedalboard.  You see those on Craig's List from time to time for free or next-to-nothing.  The electronics don't need to function: I want to convert the keyboards and stop switches into a MIDI controller, and then use a RasPi 2 as a synthesizer.  I'll pipe the audio back into the organ's audio amplifier (which may or may not need to be replaced).  Great way to revive an old organ that would otherwise end up in a landfill.  There's something mind-boggling about replacing hundreds of discrete transistors (or even vacuum tubes) with a dinky little RasPi (with billions of transistors).

So to your original question:  I'm an FPGA guy but I'm not planning to use FPGAs for these projects. Instead I want to use the DSP capabilities built into RasPi's SoC, which include (I think) vector capability on the ARM's floating-point unit and (with a bit more work) supercomputer capability with the VideoCore GPU.  I think there's way more processing power available than I need.  A sampling synthesizer needs lots of memory for samples, so I'll be using most of the 1 GB just for samples.  (One could use Flash, but flash wears out if it's re-read too many times.)

FPGAs are a fun alternative.  First, go through the usual FPGA learning process --it's the same for all applications.  FPGAs have a steep learning curve, also known as "The Cliffs of Insanity".  Once you're experienced with generic FPGA applications, it should be fairly clear how to use them as a platform for music synthesis.  It's just a bunch of multiplies and adds, so if you're using an FPGA family that has hard multiply/accumulate macros it's pretty straightforward.  But it's probably easier to do those same multiplies and adds with RasPi's DSP instructions and its GPU.

Great projects!  I'm actually planning to do something similar over the next few years.  I've been totally swamped with family obligations over the last few years which has minimized the time I've been able to invest in FPGAs and single-board computers, but those obligations should be almost over.  I played clarinet and keyboards when I was a kid, but my life's work and other things minimized the time I could spend with music.  I'm hoping that will change very soon.

Modern technology allows one to do keyboard scanning and music synthesis at amazingly low cost.  There's tons of free resources on the 'net, including samples of antique instruments that can be brought to life with a modern keyboard and cheap computing.  My first projects include:

1.  Get a modern 76-key keyboard -- e.g., a used Yamaha YPG-235 -- and use it as is to get my keyboard skills back, but also use it as a MIDI controller for a home-brew synthesizer, probably based on a Raspberry Pi 2.  I want to be able to do things like historic tunings, which you can't do with an inexpensive synth like the YPG-235, but a home-brew synth can do anything.

2.  Get an old organ console with 2 manuals and full 32-note AGO pedalboard.  You see those on Craig's List from time to time for free or next-to-nothing.  The electronics don't need to function: I want to convert the keyboards and stop switches into a MIDI controller, and then use a RasPi 2 as a synthesizer.  I'll pipe the audio back into the organ's audio amplifier (which may or may not need to be replaced).  Great way to revive an old organ that would otherwise end up in a landfill.  There's something mind-boggling about replacing hundreds of discrete transistors (or even vacuum tubes) with a dinky little RasPi (with billions of transistors).

So to your original question:  I'm an FPGA guy but I'm not planning to use FPGAs for these projects. Instead I want to use the DSP capabilities built into RasPi's SoC, which include (I think) vector capability on the ARM's floating-point unit and (with a bit more work) supercomputer capability with the VideoCore GPU.  I think there's way more processing power available than I need.  A sampling synthesizer needs lots of memory for samples, so I'll be using most of the 1 GB just for samples.  (One could use Flash, but flash wears out if it's re-read too many times.)

FPGAs are a fun alternative.  First, go through the usual FPGA learning process --it's the same for all applications.  FPGAs have a steep learning curve, also known as "The Cliffs of Insanity".  Once you're experienced with generic FPGA applications, it should be fairly clear how to use them as a platform for music synthesis.  It's just a bunch of multiplies and adds, so if you're using an FPGA family that has hard multiply/accumulate macros it's pretty straightforward.  But it's probably easier to do those same multiplies and adds with RasPi's DSP instructions and its GPU.

Sounds great. Where I think the Pi will as difficult as an FPGA is with the timing. Deterministic timings over linux are in the same cliff of madness league as the one you mention in your post. Everything else is most likely simpler on the Pi for a software-inclined person ...

I'm hoping that works to my advantage, as I can't really claim to be software-inclined. I find hardware to be the easy part, that said, because my electronics projects are all music/audio/midi based, I am finding myself making the same elemental circuits over and over, making them easy to remember. Whereas on the software side I often have to carefully consider or research every step. I have heard it said, that you have to un-think previous programming knowledge when migrating to FPGA, and fortunately, there is little for me to unthink.

Thanks Jan.

Jan Cumps  wrote:

 

Sounds great. Where I think the Pi will as difficult as an FPGA is with the timing. Deterministic timings over linux are in the same cliff of madness league as the one you mention in your post. Everything else is most likely simpler on the Pi for a software-inclined person ...

Thank you for the warning.  I'm hoping that the audio output device will do a good job of deterministic timing, so all my user space software needs to do is buffer up output samples.  The nice thing about an organ is that you expect some latency between pressing a key and hearing the sound, especially if it's a pipe organ where the pipes are a significant distance from the console.  That gives you some buffering time to play with.  You don't have that luxury with a harpsichord or fortepiano.  I wish it were practical to program RasPi at the bare metal so that I wouldn't have to fight with the operating system.  It may be that using the GPU as a DSP engine will make the timing easier.  In this case RasPi would be running headless so virtually all of the GPU can be devoted to DSP.  Also, the fact that RasPi 2 has four ARM cores ought to make this easier since one or two cores can be dedicated to music-making, leaving two cores for management functions.

The timing aspects of linux and windows is problematic.  To deal with the non-deterministic timing, I have used small co-processors (either CPLD, FPGA or tight real-time microprocessor) to sample and/or update on a more periodic interval.  I stream data to/from the co-processor which then processes in real-time and if necessary replies to the main processor.  This has worked well in most cases, but long latency in windows caused challenges.

Good luck,

Gene