Simple DIY dsPIC Project

JovianPyx · Posted: Sat Mar 19, 2011 11:33 am Post subject:

Here is the source code for both the FPGA project and the VB.NET Express Edition patch editor. Please note that the patch editor contains objects that do not function, namely, the save and load patch doesn't work - there is some code there, but it is NOT to be trusted. I probably won't have time to fix that in the near future, so if you really want it to work - you have the source - it can be expanded to finish that.

As for all of my FPGA synth projects, the patch editor sends it's data to the synth via a PC COM port at 19.2 kBaud using sysex formatted messages to the Start Kit's DCE port. These messages will also work if transmitted via MIDI. Due to the partially brain dead MIDI controller code, you cannot send sysex patch data while note messages are also being sent or there will be data corruption.

The zip file has two directories at the top, one is the patch editor, the other is the FPGA Verilog source code. The Verilog source code is meant to compile for a Spartan-3E Starter Kit.

Additive_Flute_Synth_Source.zip

Description:

Project source code for FPGA and patch editor

Download (listen)

Filename:

Additive_Flute_Synth_Source.zip

Filesize:

269.33 KB

Downloaded:

774 Time(s)

JovianPyx · Posted: Sat Mar 19, 2011 6:00 pm Post subject:

Another sample, me plinking. Done using the latest FPGA design code.

Additive_Flute_Synth_Sample_6.mp3

Description:

Additive_Flute_Synth_Sample_6

Download (listen)

Filename:

Additive_Flute_Synth_Sample_6.mp3

Filesize:

1.52 MB

Downloaded:

1244 Time(s)

Dan Lavin · Posted: Sat Mar 19, 2011 6:49 pm Post subject:

Very nice Scott! Were you able to implement LFO pitch modulation? I think that would really help. If not, perhaps pitch modulation could be done manual via pitch bend?

I've noticed a trend in your mp3's of playing notes in a little lower range than a normal flute plays. Is that intentional?

JovianPyx · Posted: Sat Mar 19, 2011 6:58 pm Post subject:

JLS · Posted: Sun Mar 20, 2011 2:43 am Post subject:

Nice example and very very thanks code Smile

JovianPyx · Posted: Mon Mar 21, 2011 12:20 pm Post subject:

Here is the Verilog source code for ver_h which contains the pitchwheel code. The patch editor already posted will work with this.

Additive_Flute_Synth_ver_h.zip

Description:

Additive Flute Synth ver_h Source Code

Download (listen)

Filename:

Additive_Flute_Synth_ver_h.zip

Filesize:

232.84 KB

Downloaded:

703 Time(s)

JLS · Posted: Mon Mar 21, 2011 2:17 pm Post subject:

Thanks update code - great work !

P.S. is possible make version with basic parameter ? (default sound without editor - editor not problem but native is quickly)

Many thanks

JovianPyx · Posted: Mon Mar 21, 2011 2:41 pm Post subject:

Thanks JLS.

Pre initialized parameters are possible, but at some cost in labor hours actually - the problem being that most of them are stored in RAM which is harder to initialize (to other than zero values). But yes, it can be done. I will probably do so with the dsPIC version.

Attached is a sample made using the latest Verilog code. The sample demonstrates the full range of the instrument (with a 5 octave MIDI keyboard), uses a little bit of pitchwheel modulation, twice as vibrato and once as a rather gross glissando. There is also an apparent airy quality to some notes, mostly when overblown (high velocity). I did this on purpose, but the patch editor can control the amount of "blow noise" heard from nothing at all to a lot more than in the sample. --- Music Show Guys: please don't use this, it's not a piece of music, just me bumbling about on my keyboard...

Additive_Flute_Synth_Sample_7.mp3

Description:

Additive_Flute_Synth_Sample_7 using the Verilog code from ver_h of the project

Download (listen)

Filename:

Additive_Flute_Synth_Sample_7.mp3

Filesize:

3.17 MB

Downloaded:

1191 Time(s)

Dan Lavin · Posted: Tue Mar 22, 2011 2:38 pm Post subject:

Scott, yeah the higher notes do sound better. I like the breath noise. Since the device is monophonic do you have a high-note or low note priority? I'm guessing from the trills you do rather than a last note priority. Reminds me of Arp or Moog trills from the 1970s.

JovianPyx · Posted: Tue Mar 22, 2011 3:01 pm Post subject:

Thanks Dan, I should have said that one of the reasons the sounds were low register in the preceding samples is that I'm lazy. I'm sitting at my desk and leaning over toward the Korg keyboard. My arm reaches about 2/3 the way up the keyboard, so my diddling is at the left end... Wink

Heh, I really don't know what the algorithm is called, so I'll describe it and maybe you can tell me ??

When any key is already depressed and another key is pressed, the second key (regardless of pitch) sounds after the first. That part, I'd guess, is obvious.

If either note is released, the remaining one sounds.

It gets a little more complex when more than 2 keys are involved. The algorithm actually remembers the order of 32 notes held down (Assuming you are using a 2x4 or your forearm). When pressed, each note is stored at the end of a RAM table. When any key is released, it's value is removed from the table and the table is compressed, the note is checked and if it is the one currently sounding, it then finds the next historically recently pressed note to play (at the end of the table). If a key is released from the middle of the table, the end of table key still plays, so no change in pitch occurs.

For example, if C D E and F are pressed and held in that order, they play in that order. If D is released - no change in pitch, but after that, if F is released, E sounds. If A B and C are pressed and held and then A and B are released, the sequence A B C is played. If A B and C are played and held and then C B and A are released in that order, a sequence of A B C B A is played.

I hope that made sense... Any clues as to what the algorithm is called?

I found this useful for playing trills, slurs and slurred arpeggios.

Ah - EDIT ADD - I just realized what my algorithm allows - playing like one plays a wind instrument (on a monosynth). When playing a scale on a wind instrument from lower to high, there are several fingers down and you lift them one at a time to play a scale. I played clarinet years ago and my sisters and brother all play flute. Anyway, this algorithm accomodates that kind of fingering, so it sorta feels right.

Pantheon · Joined: Feb 17, 2011 Posts: 36 Location: Edinburgh

I think thats called Legato playing, but I could be wrong. I just remember getting the same effect when checking the Legato option on an old VST.

The algorythms you are describing is a favourite of mine, I programmed it for my Midi-CV converter using a simple stack. Its realy a fun style to play.

Nice work going on here btw Smile

JovianPyx · Posted: Wed Mar 23, 2011 8:00 am Post subject:

Now the thing that gnaws at my brain is that I may have tried to do too much with this design considering that it will also need to perform MIDI control functions as well as generating audio. I will probably spend some serious time analyzing what it will take to implement the details of this design within a dsPIC. The number of 32x32 bit multiplies required could be a problem. I am not sure yet, but I may have to offload the MIDI control portion of this to a standard PIC and even with that, I may not be able to fit what I have envisioned in a dsPIC, especially without some sacrifices here and there...

Dan Lavin · Posted: Wed Mar 23, 2011 8:36 am Post subject:

Scott, well Pantheon is partially correct and I was not thorough enough in my initial listening. What you described is called Last Note Priority. The effect I actually liked is what Pantheon is describing: Legato mode. The ADSR doesn't reset unless all keys are off and yes this is very wind instrument and guitar hammer-on/off -like. I'm happy you implemented this because, as you mention, it allows for more expression in your playing. Your wind background really does help here.

Would it help in porting it over to the dsPIC if you only remember 2-3 notes instead of 32?

JovianPyx · Posted: Wed Mar 23, 2011 9:13 am Post subject:

Oh yes, every little bit helps and I will cut corners where implementation degradation is moot. I think that an 8 or 4 key table should be fine. There are other tricks I can and will also employ - for example, in the FPGA implementation, the pitchwheel design bit requires converting the 14 bit pitchwheel data to exponential. I did this with a small ROM (16 locations) and a linear interpolator, but in a dsPIC with 128K program space, it would make sense for this to be a 16K ROM stored in program space (which is directly addressable by the program) with no interpolator which eliminates one multiply and two adds. The main tuning ROM also employs an interplator which may also fit into that same kind of scheme. Any place where I can use precomputed values in a ROM, I will do that since I believe that 128K program space is way overkill for this project in terms of executable code size - the FPGA main state machine is less than 64 states long, but it does use many multiplies which translate to 8 or more clocks in a dsPIC. If you smell wood burning... it's my brain. Wink

My goal is to make this a one-MCU-monosynth.

JovianPyx · Posted: Thu Mar 24, 2011 11:12 am Post subject:

Multiplier Usage Analysis:

15 - 16x16
2 - 18x18
7 - 32x32

I will have to go back to the FPGA design and resolve the two 18x18 multiplier operations to either 16x16 or 32x32. One of them is for instrument tuning which I'm fairly certain will become 16x16, the other is for applying the channel pressure to the main output amplitude which will probably become 32x32. At least one of the 16x16 multipliers will be eliminated by using a 16K pitchwheel expo conversion table.

I estimate these multiply operations will consume 160 clocks out of 400 including register loads, multiply and register saves. That alone gets close to 1/2 of the clocks available per sample. There are also some adds and barrel shift operations.

So back to the FPGA I go to resolve the two 18x18 bit multiplies and then I start reading the dsPIC datasheet in earnest to discover where I might take advantage of it's built in parallelism.

EDIT ADD: New FPGA code shows that the two 18x18 multiplies can be 16x16 without any noticable performance degradation.
EDIT ADD: I was able to reduce the IIR lowpass filter for zipper removal on channel pressure from 32 bits to 16 bits. This converted two 32x32 multipliers to two 16x16 multipliers. So - much better now.

EDIT ADD 2011-03-26: I never liked using channel pressure to modulate instrument amplitude. It didn't sound like what a real flute does. I've changed the design (FPGA) to modulate 1st and 2nd harmonic amplitude much the same way as velocity. More pressure attenuates the 1st harmonic and amplifies the 2nd. Channel pressure also modulates the noise level.

I've decided to add a delay effect to the FPGA design - looks like there's enough RAM for 130 mS max delay. Note that there is probably insufficient RAM in the dsPIC to include the delay effect in the ported version.

Current multiplier analysis:
18 - 16x16
5 - 32x32

JovianPyx · Posted: Sat Mar 26, 2011 3:47 pm Post subject:

This is the _final_ final, last and final FPGA version... I've added the delay hardware and have another sample. This sample demonstrates the delay effect and the new usage of channel pressure for expression dynamics. Channel pressure is also applied to the amplitude of noise. As I may have said - the delay effect won't be part of the dsPIC due to insufficient on-chip RAM.

I'm attaching a sound file...

Note that the patch editor is new because it has sliders for the delay effect.

Additive_Flute_Synth_Sample_9.mp3

Description:

Additive_Flute_Synth_Sample_9.mp3

Download (listen)

Filename:

Additive_Flute_Synth_Sample_9.mp3

Filesize:

1.54 MB

Downloaded:

1110 Time(s)

Additive_Flute_ver_l.zip

Description:

Verilog source and some docs for Additive Flute Synth version l

Download (listen)

Filename:

Additive_Flute_ver_l.zip

Filesize:

259.27 KB

Downloaded:

539 Time(s)

Additive_Flute_Model_Patch_Editor.zip

Description:

Patch Editor - VB.NET project with source code. Required to work with version l of the Additive Flute Synth.

Download (listen)

Filename:

Additive_Flute_Model_Patch_Editor.zip

Filesize:

151.11 KB

Downloaded:

541 Time(s)

JLS · Posted: Sun Mar 27, 2011 1:04 am Post subject:

Many thanks new version.

Delay implementation is great !

P.S. PolyDrum is finished project or not ? (is possible post me source code for Spartan-3E ?) - thanks info about it

JovianPyx · Posted: Sun Mar 27, 2011 6:24 am Post subject:

ARGH! There is a small problem with the FPGA code posted above (ver_l)

There is an error in how the wet/dry pan for the delay effect works. The slider does NOT do what it should. To correct it, I've attached a new copy of the file in question (Additive_Flute.v).

Simply unzip the zip file and replace the Additive_Flute.v you have with the one in the zip file, recompile the project and the slider will work correctly.

@JLS: I see you've been busy... Smile

PolyDrum is essentially finished. What I don't like about it is that the lower resonators aren't as loud as I'd like. I believe the problem stems from Q enhancement which makes the higher resonators louder. The fix will be either a computed compensation scheme or a RAM to hold compensation values for each resonator. The level is so low at the low pitch end that too much analog amplification is necessary which can result in external noise becoming part of the mix. If the amplitude of all of the resonators were equalized (and therefore louder for lower tones) then the more substantial input to the external analog mixer would allow much lower amplification and much lower noise.

So not yet, but it's on my list of "stuff to make right"...

Additive_Flute.zip

Description:

Additive_Flute.v file with wet/dry pan slider correction.

Download (listen)

Filename:

Additive_Flute.zip

Filesize:

10.2 KB

Downloaded:

524 Time(s)

JovianPyx · Posted: Sun Mar 27, 2011 2:59 pm Post subject:

Taking a break from reading dsPIC datasheets and other design activities. The attachment is something I'm working on - it's not finished, but I think it demos the flute pretty well. I couldn't resist, I put the flute design on two boards. The flutes are intentionally tuned a bit differently.

flute_and_xarp_piece_idea.mp3

Description:

A PIECE THAT IS NOT FINISHED

Download (listen)

Filename:

flute_and_xarp_piece_idea.mp3

Filesize:

898.45 KB

Downloaded:

1149 Time(s)

Dan Lavin · Posted: Tue Mar 29, 2011 8:00 am Post subject:

Scott, good luck porting the Flute over to the dsPIC. The Flute/Xarp sample sounds really nice.

Not that you're exactly searching for more projects, but I thought the Flute could easily become an electric guitar. Change the first 2 waveforms to square waves tuned a fifth apart. Then pitch the 3rd waveform sine an octave above the fifth and fade it in for a feedback effect. Unfortunately that would require having the mod wheel or another controller besides the pitch wheel. Alternatively, you could put the sine/feedback on a long attack so that it comes in if the note is held more than 1-2 seconds. For an overall ADSR, you'd want a very short attack, very short release and very long decay with full sustain. Just a thought I had. I suppose you could do a whole series of instruments that lend themselves to this type of architecture.

JovianPyx · Posted: Tue Mar 29, 2011 5:18 pm Post subject:

roger4277 · Joined: Apr 11, 2011 Posts: 2 Location: Suffolk, UK

Hi Scott,

I've built a scrapboard with dspic per your first post and it runs fine with pickit2. Flashing leds right now.

Struggling a bit with wav files in assembler. Looking forward to toying with your asm code when available.

roger

JovianPyx · Posted: Mon Apr 11, 2011 11:04 am Post subject:

Excellent Roger! I'm not even that far - all I have is a design idea that works on an FPGA. I'm still studying the dsPIC datasheets absorbing the assembly language instruction set. I took a break (eyes going wonky from reading the screen too much), but I'll be back on it today since my diversion project is now complete.

The schematic was adapted from a schematic that I got from Tom Wiltshire (not sure if he frequents this site). I've got all the parts (I think), so maybe I should put one together and do the blinky LEDs too.

My main project will use one wavetable for sine. It will be stored in program memory if that helps any. To save on program logic, I will probably make it a full wave table instead of 1/4 wave as I did in the FPGA where logic is not scarce.

Thanks for your interest!

roger4277 · Joined: Apr 11, 2011 Posts: 2 Location: Suffolk, UK

JovianPyx · Posted: Mon Apr 11, 2011 2:05 pm Post subject:

Roger,

Yes, I'll be using MPLAB with PICkit 2.

Heh, a multi PIC pipe organ, sounds cool. That sounds a little like what Tom Wiltshire is doing - he is putting together an 8 voice polyphonic synth, I believe a subtractive type. He will have one processor (not sure what kind, PIC at least, perhaps also a dsPIC) that controls 8 voice boards.

How will you control the pipe voices? One controller that gates all the pipe dsPICs or a mini controller in each dsPIC?

Sounds like an interesting project.

As for collaboration, I may ask for some help, especially with regards to reinventing wheels. Some things are just painful for me - the first one I'm thinking about is making a 32x32=64 bit signed multiply out of the 16x16=32 signed multiply instruction. I basically know how to do it, but all the bit fiddling makes my eyes cross. And I need that to be as fast as possible. I'll probably google first to see if that's already on the web. I may also write a custom macro processor because I want to write the code as inline as possible to avoid subroutine call overhead. With a macro processor, if a multiple use code segment needs to be changed, it can be changed in the macro processor instead of finding each instance of a code segment and editing it.

So if you see some dsPIC questions here, please "pipe" up (to use an organ expression) Smile