SK-Synth: A subtractive FPGA synthesizer

[stekern]

This is a project I have been working on for a while.
It is a subtractive synthesizer implemented in an FPGA.
Features:
* 2 DCO's with sawtooth, square, triangle and sine waveform generation
* LFO that can be modulate the filter, amplitude or pitch. Possible waveforms are: sawtooth, square and triangle.
* LP-12 filter with adjustable frequency and resonance.
* Filter envelope
* Amplitude envelope.

I have been using a Avnet spartan 3A devboard with a breakoutboard with midi connector and a I2S DA-converter.
In this device the polyphony is set to 8 voices, but it is easily adjustable in the VHDL-source code. I also have received reports that it is easy to implement several SK-Synths to achieve multitimbrality (on a spartan-3e board).

Here is a picture of the devboard with the breakout-board connected:


The synth is controlled by a computer application written in Qt and it runs on both Linux and Windows.

Here is a picture of the application:


The source code for the synth and the controller application and schematics for the breakoutboard can be found in my SVN-repository here:
http://www.sk-electronics.com/svn/repos/SK-Synth/trunk/
Here is a zipped SVN-snapshot from 2010-08-05:
http://www.sk-electronics.com/sk-synth/SK-Synth-20100805.zip

A couple of samples is attached.

---

bass-sample.mp3
Description:		Download (listen)
Filename:	bass-sample.mp3
Filesize:	439.62 KB
Downloaded:	974 Time(s)

---

---

pad-sample.mp3
Description:		Download (listen)
Filename:	pad-sample.mp3
Filesize:	83.29 KB
Downloaded:	935 Time(s)

---

---

60scifi-sample.mp3
Description:		Download (listen)
Filename:	60scifi-sample.mp3
Filesize:	74.31 KB
Downloaded:	944 Time(s)

---

[wooster]

Nice job!

Does your application communicate with the synth over MIDI?

[wooster]

p.s. I am waiting for my own FPGA synth to finish synthesizing right now - takes so loooong

[stekern]

Yes, the application is communicating with the synth using MIDI messages.
It is using the RtMidi library (http://www.music.mcgill.ca/~gary/rtmidi/) to interface with the computers MIDI-hardware.

The synths midi-control messages can be found here:
http://www.sk-electronics.com/svn/repos/SK-Synth/trunk/midi_ctrl.txt

[JovianPyx]

Nice!

Where did you get the green board with the MIDI sockets?

For MIDI, are you using an embedded microcontroller such as PicoBlaze or a hardware IC (on the green board)?

[stekern]

The green board is the breakout board, and it is my own design.
I ordered the PCBs from Olimex (I have used pcbcart.com for some other projects and they are also good) and the components I soldered on myself.
The schematic for it is here: http://www.sk-electronics.com/svn/repos/SK-Synth/trunk/PCB/SK-Synth-revA.pdf
(don't mind the SID stuff, it is a different project, I just saved some money putting it on the same PCB)

MIDI is interpreted directly in the VHDL-code (no hardware or software cpu's are used).
More precisely, here:
http://www.sk-electronics.com/svn/repos/SK-Synth/trunk/vhdl/MIDI.vhdl
and here:
http://www.sk-electronics.com/svn/repos/SK-Synth/trunk/vhdl/midi_ctrl.vhdl

[JovianPyx]

Heh, I do Verilog, I read VHDL poorly - so did you simply create a state machine using VHDL to handle MIDI then? I know someone else who did that.

I use PicoBlaze for MIDI including sysex, the reason is that I find that I need to change the MIDI controller from one synth to another (for example, polysynth vs monosynth) and it's easy in assembly code. The PicoBlaze is said to consume about 90 slices, so it's pretty small. The PicoBlaze also handles controlling the LCD for a Spartan-3E Starter Kit.

[wooster]

I also did a hardware MIDI parser - the state machine is not that complicated, but I can see the benefit of using an embedded uC. How do you find out how many slices a module uses? This is the synthesis report for my midi_parser module:

Summary:
inferred 1 Finite State Machine(s).
inferred 1 RAM(s).
inferred 3 Counter(s).
inferred 52 D-type flip-flop(s).
inferred 1 Comparator(s).

...but I don't see a slice count

[stekern]

Heh, well I have the same problem but the other way around, I do VHDL but read verilog poorly
As a sidenote I can say that your (Jovian Pyx) FPGA-synths were a big inspiration when I started out this project.

Yes, it is basically a state machine that handles the midi.
I'm not using sysex, so it was pretty simple to implement it like that.

There was some other reasons for not including a mcu in the design.
One reason was that I haven't found a softcore small enough except PicoBlaze and I wanted to keep the design as non-xlilinx specific as possible.
The whole project started out when I bought the spartan-3a devboard to freshen up my VHDL-skills that I hadn't been using for nearly four years.
Since I have alot more experience with mcus and programming them than FPGAs I wanted to try to stay away from them in this design to not be lured into "cheating" to much

If I make another FPGA-synth design I will probably include a mcu and some SRAM, that is a bit of a dissapointment with the avnet spartan-3 board.

[JovianPyx]

[stekern]

If you press Module Level Utilization under Design Overview in webISE (11.2) you will get what every module is occupying (Slices, Slice Reg, LUTs, LUTRAM, BUFG and DCM).

Generate detailed report under Implement Design->Map->Process Properties have to be checked for this to be visible though.

My MIDI-implementation is occupying 53 slices (EDIT: excluding the uart).

[JovianPyx]

Another reason I like an embedded microcontroller for a synth is that the assembly code when compiled generates a block RAM module with initialization.

This means that the assembly code and the Verilog code become "married" in the project and the code is loaded along with the project logic with the bit file. It is thus very easy to organize the project so that the code for a specific synth is always "tightly coupled" to the project as a whole.

When using a separate hardware device, one must push the code into it as a separate process and one must be sure to push the right version of code into it. Surely however, this becomes less of a problem as the code stabilizes (assuming it sits in Flash RAM or EEPROM).

In my case, however, my synths are currently all built on dev boards and I like to change the synth that runs on that board on a whim, so using a hardware uC would present at least an inconvenience to me.

YMMV.

[JovianPyx]

[wooster]

Works in 12.1 too. Funny, my midi parser is also 53 slices.

stekern, are you going to add a detune control for the DCO's?

[stekern]

wooster: yep that is definitely on the todo-list, along with some other stuff like legato.

JovianPyx: I get what you are saying. The main reason why I would like an external processor is that I would like to be able pull different FPGA images from, for example an SD-card.

[JovianPyx]

What is an "LP-12" filter?

[stekern]

I was just trying to say that it is a low-pass filter with a cutoff slope at 12dB/octave.

[stekern]

Detuning of each oscillator down to 1 cent is now implemented and updated in SVN.
I had to rewrite the pitch generation stuff a bit, but it was mostly for the good, since it is a lot more flexible now.

[laserbeak43]

[stekern]

Yes, that should work.
I just noticed that I haven't updated a change to the schematic that is necessary. If you will be using an EL817 the resistor R11 should be 1kohm instead of 280ohm.
The EL817 optocoupler is actually not optimal in MIDI-applications, for example HCPL-0701 is a better choice.

I am not actually using the MIDI-out (at the moment), so if you won't need that you can skip that too.

[laserbeak43]

great!! That's really good news, but I hope i have a nice model opto-coupler at my disposal, cause i'd hate to wait on an order.

i have a CNY4-4, would that be ok?

[stekern]

The problem with the EL817 is that when the pullup resistance is to low, VCE will be to high and the FPGA won't notice the 'low' input.
If the pullup resistance is to high the signals slew rates will be to slow.
My UART implementation is pretty forgiving to slow slew rates, but experiment with R11 if problems arise.

[laserbeak43]

ok I will

[stekern]

I have now implemented legato (updated in SVN).
In my implementation the difference between retrig mode and legato mode is, that in retrig mode each voice is assigned an own (filter and amplitude) envelope.
In legato mode only one (filter and amplitude) is used and all voices follows this as long as any note is pressed. When all notes are released the envelope will restart when a new note is pressed.
Does this logic seem reasonable?

I have attached a sample to show how it sounds.
It also demonstrates the oscillator detuning.

Next on the TODO-list is portamento, but that will be a harder nut to crack.
At least without introducing too much logic.

---

legato-sample.mp3
Description:		Download (listen)
Filename:	legato-sample.mp3
Filesize:	180.02 KB
Downloaded:	656 Time(s)

---

[stekern]

I have just finished the portamento implementation.
I took a while to figure out how the logic should work with polyphony,
but this is how I decided to do it:

Portamento is only active when more than one note is pressed, and the pitch sliding is always from the last note pressed.
This seemed to be the most logical solution i my mind.

Here is a screenshot from the latest version of the control program.


And attached is a demonstration of the portamento effect in action.

---

portamento-sample.mp3
Description:	Demonstration of portamento.	Download (listen)
Filename:	portamento-sample.mp3
Filesize:	204.11 KB
Downloaded:	743 Time(s)

---