Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Fri Aug 06, 2010 9:54 pm Post subject:
SK-Synth: A subtractive FPGA synthesizer
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.
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Fri Aug 06, 2010 10:58 pm Post subject:
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.
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 237
Posted: Sat Aug 07, 2010 6:07 am Post subject:
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)? _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat?corruptio optimi pessima
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Sat Aug 07, 2010 6:36 am Post subject:
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)
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 237
Posted: Sat Aug 07, 2010 7:37 am Post subject:
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. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat?corruptio optimi pessima
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:
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Sat Aug 07, 2010 7:57 am Post subject:
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.
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 237
Posted: Sat Aug 07, 2010 8:27 am Post subject:
wooster wrote:
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:
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Sat Aug 07, 2010 8:46 am Post subject:
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).
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 237
Posted: Sat Aug 07, 2010 9:00 am Post subject:
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.
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 237
Posted: Sat Aug 07, 2010 9:04 am Post subject:
stekern wrote:
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).
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Sat Aug 07, 2010 11:55 am Post subject:
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.
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Wed Aug 11, 2010 10:26 am Post subject:
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.
thanks for this great work. In this quote, are you saying that if I'm using a breadboard, I can connect MIDI directly to an FPGA pin withonly this part of the schematic, without using this connector interface?
(Altera DE2 Dev Board)
midi schematic.png
Description:
Just the part of the schematic that has the external midi IO
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Fri Aug 13, 2010 9:01 am Post subject:
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.
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Fri Aug 13, 2010 10:53 pm Post subject:
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.
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Wed Aug 18, 2010 10:21 am Post subject:
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.
Joined: Aug 06, 2010 Posts: 14 Location: Finland
Audio files: 5
Posted: Sat Sep 04, 2010 9:21 pm Post subject:
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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
