Digital Waveguide

FPGASynth.DigitalWaveguide History

Hide minor edits - Show changes to markup

May 01, 2011, at 07:30 PM by 108.13.196.146 -
Changed lines 152-162 from:

sound with longer sustain. Lowering the bandwidth shortens sustain. If the bandwidth is low enough, you will get drum-like sounds (kind of like tonal bongos or congas). For drum sounds, switch 3 should be set off so that the entire range becomes drum sounds. For plucked strings, set switch 3 on for consistent string sounds accross the instrument's range.

The pickup position is controlled with the MIDI modulation wheel. It affects the sound much like an electric guitar's pickup position. Note that because of dirty RAM after moving the wheel, the synth may produce a low level of noise while moving the wheel. The noise abates as soon as the wheel stops moving. If I find a way to fix this, I will (future version). For now, the mod wheel is meant as an easy way to set the pickup position without system exclusive messages. In fact, there are no system exclusive message settings at all in this version. It is probably not good to use the modulation wheel as a performance control in this version. The Pitch Wheel is not programmed nor is after touch.

to:

sound with longer sustain. Lowering the bandwidth shortens sustain. If the bandwidth is low enough, you will get drum-like sounds (kind of like tonal bongos or congas). For drum sounds, switch 3 should be set off so that the entire range becomes drum sounds. For plucked strings, set switch 3 on for consistent string sounds accross the instrument's range. As a side note, my interest in digital waveguide synthesis began when I read about a college FPGA project called Terror Mouse, a 6 string "guitar" model implemented in a small FPGA. The Terror Mouse design used a shelving filter which at the time I didn't completely understand. This fact led to my choice of a simple single pole lowpass IIR filter. Recently (May 1, 2011), I revisited the PolyDaWG-8 synth and added a selectable reflection filter module. Two filters were implemented, the simple single pole filter that I had already been using and the Terror Mouse shelving filter (using the designer's coefficients). In a word, I'd describe the shelving filter as underwhelming. It works, but does not emulate an "acoustic guitar" as was the designer's intention. In fact, the single pole lowpass IIR is tunable and versatile enough that it can provide a timbre so similar to the Terror Mouse shelving filter as to be indistinguishable. All in all, I prefer the single pole IIR design because it can be tuned so easily. The coefficients are calculated on the fly in the FPGA.

The pickup position is controlled with the MIDI modulation wheel. It affects the sound much like an electric guitar's pickup position. Note that because of dirty RAM after moving the wheel, the synth may produce a low level of noise while moving the wheel. The noise abates as soon as the wheel stops moving. If I find a way to fix this, I will (future version). For now, the mod wheel is meant as an easy way to set the pickup position without system exclusive messages. In fact, there are no system exclusive message settings at all in this version. It is probably not good to use the modulation wheel as a performance control in this version. The Pitch Wheel is not programmed nor is after touch.

Changed lines 159-173 from:

The sustain pedal acts like a piano's. Undepressed, each note played is held only as long as the key is held down. Depressed, each note played rings until the pedal is released. Note that this synth is only 8 voice polyphonic, so if sustain is held down and more than 8 notes are played, an older ringing string will be "stolen" to produce the newest note's sound.

I have found that two of these instruments on the same MIDI channel with slightly different filter settings sound very full and rich. This is due to the fact that the filter provides a small delay which varies with bandwidth. Thus different filter settings will change not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the filter's setting range. The pitch difference is then responsible for a phasing effect, something like that heard from a piano (though this synth is NOT a piano model).

The basic pitch range of the instrument is determined by the sample rate. As it exists in the zip file, the system is programmed for 250 KHz. You can change this to 125 KHz to lower the instrument one octave. The range is 3.5 octaves regardless of the sample rate.

to:

The sustain pedal acts like a piano's. Undepressed, each note played is held only as long as the key is held down. Depressed, each note played rings until the pedal is released. Note that this synth is only 8 voice polyphonic, so if sustain is held down and more than 8 notes are played, an older ringing string will be "stolen" to produce the newest note's sound.

I have found that two of these instruments on the same MIDI channel with slightly different filter settings sound very full and rich. his is due to the fact that the filter provides a small delay which varies with bandwidth. Thus different filter settings will change not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the filter's setting range. The pitch difference is then responsible for a phasing effect, something like that heard from a piano (though this synth is NOT a piano model).

The basic pitch range of the instrument is determined by the sample rate. As it exists in the zip file, the system is programmed for 250 KHz. You can change this to 125 KHz to lower the instrument one octave. The range is 3.5 octaves regardless of the sample rate.

March 10, 2011, at 09:36 PM by 108.13.196.146 -
Changed lines 232-233 from:

- Removed several states from the main state machine. This should allow an increase in sample rate from 534478 Hz. Max sample rate for this version: 862068.966 Hz. This version allows tuning via rotary encoder to change the sample rate downward. At startup, the lowest C key should be a G# (before the rotary encoder is moved).

to:

- Removed several states from the main state machine. Max sample rate for this version: 862068.966 Hz.

- This version allows tuning via rotary encoder to change the sample rate downward. At startup, the lowest C key should be a G# (before the rotary encoder is moved). Therefore, it will require you to tune it as you need it.

March 10, 2011, at 09:33 PM by 108.13.196.146 -
Added line 231:
March 10, 2011, at 09:33 PM by 108.13.196.146 -
Added lines 230-236:

ver_q: - Removed several states from the main state machine. This should allow an increase in sample rate from 534478 Hz. Max sample rate for this version: 862068.966 Hz. This version allows tuning via rotary encoder to change the sample rate downward. At startup, the lowest C key should be a G# (before the rotary encoder is moved).

- New range is 57 notes.

- Add linear attenuation (uses JOY_X and JOY_Y).

March 10, 2011, at 09:28 PM by 108.13.196.146 -
Changed line 244 from:

+LATEST CODE+

to:

LATEST CODE

March 10, 2011, at 09:27 PM by 108.13.196.146 -
Changed lines 244-245 from:
to:

+LATEST CODE+

March 10, 2011, at 09:25 PM by 108.13.196.146 -
Added lines 244-245:
March 07, 2009, at 04:39 AM by 98.119.118.140 -
Changed lines 257-258 from:

Thanks to the members of the FPGA-Synth list for all of the help I have received there

to:

Thanks to the members of the FPGA-Synth list for all of the help I have received there.

February 13, 2009, at 03:41 PM by 98.119.118.140 -
Deleted lines 148-161:

The following is a block diagram of one of the 8 digital waveguide "strings".

                                                   Length gives
excite               Length gives pitch            pickup position
\                      \                            \
 >--[add]-->-[CLIP]->-[variable delay line]--->---[variable delay line]->-[subtract]--> out
      |                                     |   |                              |
      ^           STRING LOOP               V   V         COMB FILTER          ^
      |                                     |   |                              |
      ----[invert]--<---<--[Variable IIR]----   ---->----->----->----->----->---
                                \
                                Timbre
February 13, 2009, at 03:40 PM by 98.119.118.140 -
Deleted line 60:

Here's an ASCII diagram of the system:

Deleted lines 63-64:
February 13, 2009, at 03:39 PM by 98.119.118.140 -
Changed lines 62-79 from:
                                                     length
          on/off         BW                          control
            |            |                              |
  +--> nonlinearity --> IIR0 --> sign inversion --> delay line ----->----->----->-------+
  |                                                    |                                |
  |                                                    |                                |
  |                             pickup                 |                                |
  ^       +--------------------> SUM <-----------------+                                V
  |       |                       |                                                     |
  |       |                       +----> OUTPUT                                         |
  |       |                                                                             |
  +-<- delay line <-- hard clip <-- SUM <-- sign inversion <-- IIR1 <-- nonlinearity <--+
            |                        ^                          |            |
          length                     |                          BW          on/off
          control                    +--< Excitation input
to:

Block Diagram http://www.fpga.synth.net/pmwiki/uploads/FPGASynth/K_S_Block_Diagram.gif

February 13, 2009, at 03:14 PM by 98.119.118.140 -
Deleted lines 116-127:
                                             Length gives
excite        Length gives pitch            pickup position
\               \                            \
 >--[add]-->--[variable delay line]--->----[variable delay line]-->--[subtract]--> output
      |                             |   |                                 |
      ^        STRING LOOP          V   V          COMB FILTER            ^
      |                             |   |                                 |
      --[invert]--<--[Variable IIR]--   -->------>------->------->----->---
                           \
                           Timbre
February 13, 2009, at 03:12 PM by 98.119.118.140 -
Added lines 113-116:

Block Diagram http://www.fpga.synth.net/pmwiki/uploads/FPGASynth/Karplus_Strong_Single_Delay_Line_Block_Diagram.gif

February 13, 2009, at 02:38 PM by 98.119.118.140 -
Changed lines 280-281 from:
to:
July 18, 2008, at 03:53 PM by 71.189.44.199 -
Changed lines 291-292 from:

The MIDI controller contains all the basic MIDI performance stuff plus code to perform system exclusive based updates to the hardware's operational registers or RAM (Note that this feature was not used in the DaWG synths). The code also includes (with some hardware) support for the LCD display on the S-3Esk. The current code is 0x20B locations in length, so there is still plenty of room for features or whatever.

to:

The MIDI controller contains all the basic MIDI performance stuff plus code to perform system exclusive based updates to the hardware's operational registers or RAM (Note that this feature was not used in the DaWG synths). The code also includes support for the LCD display on the S-3Esk. The current code is 0x20B locations in length, so there is still plenty of room for features or whatever.

July 03, 2008, at 08:55 PM by 71.189.44.199 -
July 03, 2008, at 08:54 PM by 71.189.44.199 -
Changed line 112 from:

I found it simpler to use the Karplus-Strong Single Delay Line model.

to:

It is simpler and better to use the Karplus-Strong Single Delay Line model because it uses half the RAM to do the exact same thing.

July 03, 2008, at 08:47 PM by 71.189.44.199 -
Deleted lines 142-147:

Where This Will Go:

Use SDRAM to replace the block RAMs for a larger number of strings that are also longer.



July 03, 2008, at 08:43 PM by 71.189.44.199 -
Changed lines 272-273 from:

ver_n is tunable, it seems usable, but I am not happy with the granularity. Tuning was accomplished by changing the SPI DAC controller to allow inserting a variable number of extra clocks between DAC enable pulses. This design uses RAM wherever possible instead of flipflops. Using RAMs requires more state machine steps for each string increasing the total time for computing the harp to 57 clocks. The filter now uses 3 clocks instead of 4, this helped mitigate the longer time required by the RAM method. ver_n was tested using WebPACK ISE 9.2i.

to:

ver_n is tunable, it seems usable, but I am not happy with the granularity. Tuning was accomplished by changing the SPI DAC controller to allow inserting a variable number of extra clocks between DAC enable pulses which lowers the sample rate. This design uses RAM wherever possible instead of flipflops. Using RAMs requires more state machine steps for each string increasing the total time for computing the harp to 57 clocks. The filter now uses 3 clocks instead of 4, this helped mitigate the longer time required by the RAM method. ver_n was tested using WebPACK ISE 9.2i.

July 01, 2008, at 11:44 PM by 71.189.44.199 -
Changed lines 134-135 from:

Regarding the sound of the instrument, it is important to note that this physical model is one dimensional. That is, it simulates only one of the ways in which a real string vibrates. For more dimensions, additional waveguide systems are required per string. The FPGA I am using has too little internal RAM to do any more than 8 strings in one dimension (well, technically, I think I could squeeze 9 strings, but that would require a big change to the MIDI controller). The next version of this project will include SDRAM. The maximum number of waveguides will depend on how fast the design handles SDRAM transactions. The number of strings will be the max waveguide count divided by the number of dimensions supported. That said about dimensions, this instrument will not sound like any true natural instrument because of it's one dimensionality. It has characteristics that are found in natural instruments and I believe that is what gives this instrument a "more natural than a synthesizer" sort of sound. The instrument produces two major groups of sound, string-like and drum-like. With the filter bandwidth rather large, the sound will have more sustain and a brighter snappier attack, the lower register sounds harpsichord like and a bit higher sounds guitar-like. The more slowly decaying harmonics tend to have a metallic sound. The sound morphs slightly and gradually as you move up the scale. This effect is reduced by using more keyfollow for the pickup position. With low bandwidth, damping is rather quick, suppressing higher harmonics except during the very beginning of the sound. The drum sounds can be made to sound very much like tonal bongos or tonal congas, lowering the bandwidth increases the damping while increased bandwidth gives a longer resonant decay.

to:

Regarding the sound of the instrument, it is important to note that this physical model is one dimensional. That is, it simulates only one of the ways in which a real string vibrates. For more dimensions, additional waveguide systems are required per string. The FPGA I am using has too little internal RAM to do any more than 8 strings in one dimension (well, technically, I think I could squeeze 9 strings, but that would require a big change to the MIDI controller). Of course, other techniques might be able to better utilize the RAM and attain a higher string count.

The next version of this project may include SDRAM. The maximum number of waveguides will depend on how fast the design handles SDRAM transactions. The number of strings will be the max waveguide count divided by the number of dimensions supported. That said about dimensions, this instrument will not sound like any true natural instrument because of it's one dimensionality. It has characteristics that are found in natural instruments and I believe that is what gives this instrument a "more natural than a synthesizer" sort of sound. The instrument produces two major groups of sound, string-like and drum-like. With the filter bandwidth rather large, the sound will have more sustain and a brighter snappier attack, the lower register sounds harpsichord like and a bit higher sounds guitar-like. The more slowly decaying harmonics tend to have a metallic sound. The sound morphs slightly and gradually as you move up the scale. This effect is reduced by using more keyfollow for the pickup position. With low bandwidth, damping is rather quick, suppressing higher harmonics except during the very beginning of the sound. The drum sounds can be made to sound very much like tonal bongos or tonal congas, lowering the bandwidth increases the damping while increased bandwidth gives a longer resonant decay.

July 01, 2008, at 11:27 PM by 71.189.44.199 -
Deleted lines 292-295:

Notes:

1) This model is not strictly a plucked string. In the plucked string model, the excitation comes in the form of a triangle of forces used to initialize the string at pluck time. Think of a stretched rubber band that is pulled off to one side before releasing it. In my implementation, I use a simpler, but unnatural excitation of initializing equal energy (amount determined by MIDI velocity) to each delay cell of the first half of the waveguide. This was done to simplify the implementation of this experimental model.


July 01, 2008, at 11:23 PM by 71.189.44.199 -
Changed lines 290-291 from:

Note that this is a work in progress. As time goes by, I will probably find things to improve. I will post messages to SDIY and FPGA-Synth to alert of any changes to the code.

to:

Note that this is a work in progress. As time goes by, I will probably find things to improve. I will post messages to SDIY and FPGA-Synth to inform of any changes to the code.

June 22, 2008, at 04:32 PM by 71.189.44.199 -
Changed lines 138-139 from:

Digital techniques used to provide waveguides create design boundaries that must be considered. Pitch resolution of a waveguide depends upon the number of stages in the delay line. The more stages, the smaller will be the granularity of pitch. However, each doubling of the length of a waveguide causes the pitch to drop one octave assuming that the sample rate doesn't change. If one wishes to compensate for the lower pitch, one is required to increase the sample rate. So while it's desirable to have long waveguides for pitch accuracy, long waveguides also demand higher sample rates to maintain pitch range. Higher sample rates then restrict how much work the controlling state machine can do in each sample time. This leads to design restrictions such as the number of string objects provided or the number of features provided. The PolyDaWG/8 synth was designed with a "happy medium" approach. Initially, PolyDaWG's designed waveguide lengths were determined only by the amount of RAM available and the sample rate of between 125KHz and 250KHz was chosen to provide sounds in the range of normal human hearing. The waveguide lengths chosen provide only about 3.5 octaves because the pitch resolution becomes too large at the high end of the pitch range. In designing PolyDaWG/8, I used a C program which calculates the correct waveguilde length of each note of the scale (starting at some reasonable low value) for a given sample rate. The program stops as soon as it encounters a waveguide length which produces a pitch that is more than 5 cents out of tune. 5 cents is considered to be undetectable as "out of tune" by most humans. This data was then used to generate the tuning ROM values.

to:

Digital techniques used to provide waveguides create design boundaries that must be considered. Pitch resolution of a waveguide depends upon the number of stages in the delay line. The more stages, the smaller will be the granularity of pitch. (Note: a method called "fractional delay" is available to allow more pitch resolution with a small computational sacrifice. Lagrange interpolators are an example of this). However, each doubling of the length of a waveguide causes the pitch to drop one octave assuming that the sample rate doesn't change. If one wishes to compensate for the lower pitch, one is required to increase the sample rate. So while it's desirable to have long waveguides for pitch accuracy, long waveguides also demand higher sample rates to maintain pitch range. Higher sample rates then restrict how much work the controlling state machine can do in each sample time. This leads to design restrictions such as the number of string objects provided or the number of features provided. The PolyDaWG/8 synth was designed with a "happy medium" approach. Initially, PolyDaWG's designed waveguide lengths were determined only by the amount of RAM available and the sample rate of between 125KHz and 250KHz was chosen to provide sounds in the range of normal human hearing. The waveguide lengths chosen provide only about 3.5 octaves because the pitch resolution becomes too large at the high end of the pitch range. In designing PolyDaWG/8, I used a C program which calculates the correct waveguilde length of each note of the scale (starting at some reasonable low value) for a given sample rate. The program stops as soon as it encounters a waveguide length which produces a pitch that is more than 5 cents out of tune. 5 cents is considered to be undetectable as "out of tune" by most humans. This data was then used to generate the tuning ROM values.

June 22, 2008, at 04:28 PM by 71.189.44.199 -
Changed line 62 from:

''[@

to:

[-[@

Changed lines 78-79 from:

@]''

to:

@]-]

June 22, 2008, at 04:27 PM by 71.189.44.199 -
Changed line 62 from:

'''[@

to:

''[@

Changed lines 78-79 from:

@]'''

to:

@]''

February 17, 2008, at 08:37 PM by 71.116.255.109 -
Changed line 295 from:

1) This model is not strictly a plucked string. In the plucked string model, the excitation comes in the form of a triangle of forces used to initialize the string at pluck time. Think of a stretched rubber band that is pulled off to one side before releasing it. In my implementation, I use a simpler, but unnatural excitation of initializing equal energy (amount determined by MIDI velocity) to each delay cell of the first half of the waveguide.

to:

1) This model is not strictly a plucked string. In the plucked string model, the excitation comes in the form of a triangle of forces used to initialize the string at pluck time. Think of a stretched rubber band that is pulled off to one side before releasing it. In my implementation, I use a simpler, but unnatural excitation of initializing equal energy (amount determined by MIDI velocity) to each delay cell of the first half of the waveguide. This was done to simplify the implementation of this experimental model.

February 17, 2008, at 08:36 PM by 71.116.255.109 -
Changed line 295 from:

1) This model is not strickly a plucked string. In the plucked string model, the excitation comes in the form of a triangle of forces used to initialize the string at pluck time. Think of a stretched rubber band that is pulled off to one side before releasing it. In my implementation, I use a simpler, but unnatural excitation of initializing equal energy (amount determined by MIDI velocity) to each delay cell of the first half of the waveguide.

to:

1) This model is not strictly a plucked string. In the plucked string model, the excitation comes in the form of a triangle of forces used to initialize the string at pluck time. Think of a stretched rubber band that is pulled off to one side before releasing it. In my implementation, I use a simpler, but unnatural excitation of initializing equal energy (amount determined by MIDI velocity) to each delay cell of the first half of the waveguide.

February 17, 2008, at 08:35 PM by 71.116.255.109 -
Added lines 293-296:

Notes:

1) This model is not strickly a plucked string. In the plucked string model, the excitation comes in the form of a triangle of forces used to initialize the string at pluck time. Think of a stretched rubber band that is pulled off to one side before releasing it. In my implementation, I use a simpler, but unnatural excitation of initializing equal energy (amount determined by MIDI velocity) to each delay cell of the first half of the waveguide.


November 26, 2007, at 05:06 PM by 71.106.219.12 -
Changed lines 138-139 from:

Digital techniques used to provide waveguides create design boundaries that must be considered. Pitch resolution of a waveguide depends upon the number of stages in the delay line. The more stages, the smaller will be the granularity of pitch. However, each doubling of the length of a waveguide causes the pitch to drop one octave assuming that the sample rate doesn't change. If one wishes to compensate for the lower pitch, one is required to increase the sample rate. So while it's desirable to have long waveguides for pitch accuracy, long waveguides also demand higher sample rates to maintain pitch range. Higher sample rates then restrict how much work the controlling state machine can do in each sample time. This leads to design restrictions such as the number of string objects provided or the number of features provided. The PolyDaWG/8 synth was designed with a "happy medium" approach. Initially, PolyDaWG's designed waveguide lengths were determined only by the amount of RAM available and the sample rate of between 125KHz and 250KHz was chosen to provide sounds in the range of normal human hearing.

to:

Digital techniques used to provide waveguides create design boundaries that must be considered. Pitch resolution of a waveguide depends upon the number of stages in the delay line. The more stages, the smaller will be the granularity of pitch. However, each doubling of the length of a waveguide causes the pitch to drop one octave assuming that the sample rate doesn't change. If one wishes to compensate for the lower pitch, one is required to increase the sample rate. So while it's desirable to have long waveguides for pitch accuracy, long waveguides also demand higher sample rates to maintain pitch range. Higher sample rates then restrict how much work the controlling state machine can do in each sample time. This leads to design restrictions such as the number of string objects provided or the number of features provided. The PolyDaWG/8 synth was designed with a "happy medium" approach. Initially, PolyDaWG's designed waveguide lengths were determined only by the amount of RAM available and the sample rate of between 125KHz and 250KHz was chosen to provide sounds in the range of normal human hearing. The waveguide lengths chosen provide only about 3.5 octaves because the pitch resolution becomes too large at the high end of the pitch range. In designing PolyDaWG/8, I used a C program which calculates the correct waveguilde length of each note of the scale (starting at some reasonable low value) for a given sample rate. The program stops as soon as it encounters a waveguide length which produces a pitch that is more than 5 cents out of tune. 5 cents is considered to be undetectable as "out of tune" by most humans. This data was then used to generate the tuning ROM values.

November 26, 2007, at 05:00 PM by 71.106.219.12 -
Added lines 138-139:

Digital techniques used to provide waveguides create design boundaries that must be considered. Pitch resolution of a waveguide depends upon the number of stages in the delay line. The more stages, the smaller will be the granularity of pitch. However, each doubling of the length of a waveguide causes the pitch to drop one octave assuming that the sample rate doesn't change. If one wishes to compensate for the lower pitch, one is required to increase the sample rate. So while it's desirable to have long waveguides for pitch accuracy, long waveguides also demand higher sample rates to maintain pitch range. Higher sample rates then restrict how much work the controlling state machine can do in each sample time. This leads to design restrictions such as the number of string objects provided or the number of features provided. The PolyDaWG/8 synth was designed with a "happy medium" approach. Initially, PolyDaWG's designed waveguide lengths were determined only by the amount of RAM available and the sample rate of between 125KHz and 250KHz was chosen to provide sounds in the range of normal human hearing.

November 18, 2007, at 12:23 AM by 71.165.30.109 -
Added lines 266-269:

ver_n:

ver_n is tunable, it seems usable, but I am not happy with the granularity. Tuning was accomplished by changing the SPI DAC controller to allow inserting a variable number of extra clocks between DAC enable pulses. This design uses RAM wherever possible instead of flipflops. Using RAMs requires more state machine steps for each string increasing the total time for computing the harp to 57 clocks. The filter now uses 3 clocks instead of 4, this helped mitigate the longer time required by the RAM method. ver_n was tested using WebPACK ISE 9.2i.

Changed line 280 from:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_l, 8 voices) Updated 09-09-2007
to:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_n, 8 voices) Updated 11-17-2007
September 26, 2007, at 04:47 PM by Scott Gravenhorst -
Changed lines 132-133 from:

In doing this project, I learned some important things. One of them has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad. Also, as the pitch is increased (waveguide length decreased), the effect of this extra delay is more and more apparent. I did not notice, however, that any pitch within the instrument's range was so far out of tune as to be obvious, only that as pitch increases, differences between filter settings make for faster phasing (for two or more synths played together).

to:

In doing this project, I learned some important things. One of them has to do with delays. I initially expected that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad. Also, as the pitch is increased (waveguide length decreased), the effect of this extra delay is more and more apparent. I did not notice, however, that any pitch within the instrument's range was so far out of tune as to be obvious, only that as pitch increases, differences between filter settings make for faster phasing (for two or more synths played together).

September 09, 2007, at 11:00 PM by Scott Gravenhorst -
Changed line 275 from:

* PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices) - OBSOLETE

to:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices) - OBSOLETE
September 09, 2007, at 10:59 PM by Scott Gravenhorst -
Changed lines 275-278 from:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices) - OBSOLETE
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_l, 8 voices) Updated 09-07-2007
  • BassDaWG.zip - BassDaWG/4 Source and Documentation files (ver_b, 4 voices) Updated 09-07-2007
to:

* PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices) - OBSOLETE

  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_l, 8 voices) Updated 09-09-2007
  • BassDaWG.zip - BassDaWG/4 Source and Documentation files (ver_c, 4 voices) Updated 09-09-2007
September 09, 2007, at 10:54 PM by Scott Gravenhorst -
September 09, 2007, at 10:32 PM by Scott Gravenhorst -
Changed lines 289-290 from:

The MIDI controller contains all the basic MIDI performance stuff plus code to perform system exclusive based updates to the hardware's operational registers or RAM. The code also includes (with some hardware) support for the LCD display on the S-3Esk. The current code is 0x20B locations in length, so there is still plenty of room for features or whatever.

to:

The MIDI controller contains all the basic MIDI performance stuff plus code to perform system exclusive based updates to the hardware's operational registers or RAM (Note that this feature was not used in the DaWG synths). The code also includes (with some hardware) support for the LCD display on the S-3Esk. The current code is 0x20B locations in length, so there is still plenty of room for features or whatever.

September 09, 2007, at 10:20 PM by Scott Gravenhorst -
Changed lines 292-293 from:

Thanks to the members of the FPGA-Synth list for all of the help

to:

Thanks to the members of the FPGA-Synth list for all of the help I have received there

September 09, 2007, at 10:17 PM by Scott Gravenhorst -
Deleted line 285:
Added lines 287-290:

MIDI Controller

The MIDI controller contains all the basic MIDI performance stuff plus code to perform system exclusive based updates to the hardware's operational registers or RAM. The code also includes (with some hardware) support for the LCD display on the S-3Esk. The current code is 0x20B locations in length, so there is still plenty of room for features or whatever.

Added lines 292-293:

Thanks to the members of the FPGA-Synth list for all of the help

Changed lines 295-297 from:
to:


September 07, 2007, at 07:02 PM by Scott Gravenhorst -
Changed line 275 from:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices)
to:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices) - OBSOLETE
September 07, 2007, at 07:00 PM by Scott Gravenhorst -
Deleted line 255:

Deleted line 261:

September 07, 2007, at 06:56 PM by Scott Gravenhorst -
Changed lines 264-267 from:

BassDaWG/4:

It was simple to convert PolyDaWG/8 into a 4 string polyphonic bass version. It works the same, but has strings twice the length of PolyDaWG/8. BassDaWG/4 has a 4.5 octave range.

to:

ver_l:

Correct anomoly in voice assignment.

Added lines 269-275:

BassDaWG/4 ver_b:

It was simple to convert PolyDaWG/8 into a 4 string polyphonic bass version. It works the same, but has strings twice the length of PolyDaWG/8. BassDaWG/4 has a 4.5 octave range.

The same voice assignment anomoly as was found in PolyDaWG/8 was corrected in BassDaWG/4 ver_b.


September 07, 2007, at 06:53 PM by Scott Gravenhorst -
Changed lines 271-273 from:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_k, 8 voices) Updated 09-04-2007
  • BassDaWG.zip - BassDaWG/4 Source and Documentation files (ver_a, 4 voices) Updated 09-05-2007
to:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_l, 8 voices) Updated 09-07-2007
  • BassDaWG.zip - BassDaWG/4 Source and Documentation files (ver_b, 4 voices) Updated 09-07-2007
September 05, 2007, at 06:19 PM by Scott Gravenhorst -
Changed lines 136-137 from:

BassDaWG/4 is a modified version of PolyDaWG/8. It has 4 strings that are twice as long. Since the sample rates are the same, this instrument is an octave lower. It also has an additional octave of range (4.5 octaves). With proper filter and pickup position settings, it can be made to sound something like a fretless electric bass though not exactly. BassDaWG/4 is also polyphonic, so you can do common bass chords and accent harmonies.

to:

BassDaWG/4 is a modified version of PolyDaWG/8. It has 4 strings that are twice as long. Since the sample rates are the same, this instrument is an octave lower. It also has an additional octave of range (4.5 octaves). The filter bandwidth algorithms are modified for better consistency of bass sound across the keyboard. With proper filter and pickup position settings, it can be made to sound something like a fretless electric bass though not exactly. BassDaWG/4 is also polyphonic, so you can do common bass chords and accent harmonies.

Changed lines 272-273 from:
  • BassDaWG.zip - BassDaWG/4 Source and Documentation files (ver_a, 4 voices) Updated 09-04-2007
to:
  • BassDaWG.zip - BassDaWG/4 Source and Documentation files (ver_a, 4 voices) Updated 09-05-2007
September 05, 2007, at 05:25 PM by Scott Gravenhorst -
Changed line 151 from:

A 8 voice polyphonic MIDI synthesizer based on the Karplus-Strong single delay line with

to:

An eight voice polyphonic MIDI synthesizer based on the Karplus-Strong single delay line with

September 05, 2007, at 05:22 PM by Scott Gravenhorst -
Changed lines 130-131 from:

Some Conclusions:

to:

Some Observations and Conclusions:

Added lines 136-137:

BassDaWG/4 is a modified version of PolyDaWG/8. It has 4 strings that are twice as long. Since the sample rates are the same, this instrument is an octave lower. It also has an additional octave of range (4.5 octaves). With proper filter and pickup position settings, it can be made to sound something like a fretless electric bass though not exactly. BassDaWG/4 is also polyphonic, so you can do common bass chords and accent harmonies.

Changed lines 141-142 from:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU ROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand it by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string polyphonic harp working with block RAM.

to:

Use SDRAM to replace the block RAMs for a larger number of strings that are also longer.

September 05, 2007, at 12:41 AM by Scott Gravenhorst -
Added line 263:
September 05, 2007, at 12:40 AM by Scott Gravenhorst -
Added lines 262-265:

BassDaWG/4: It was simple to convert PolyDaWG/8 into a 4 string polyphonic bass version. It works the same, but has strings twice the length of PolyDaWG/8. BassDaWG/4 has a 4.5 octave range.


Changed lines 268-269 from:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_k, 8 voices) Updated 09-03-2007
to:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_k, 8 voices) Updated 09-04-2007
  • BassDaWG.zip - BassDaWG/4 Source and Documentation files (ver_a, 4 voices) Updated 09-04-2007
September 04, 2007, at 05:38 PM by Scott Gravenhorst -
Changed lines 134-135 from:

Regarding the sound of the instrument, it is important to note that this physical model is one dimensional. That is, it simulates only one of the ways in which a real string vibrates. For more dimensions, an additional waveguide system is required per string. The FPGA I am using has too little internal RAM to do any more than 8 strings in one dimension (well, technically, I think I could squeeze 9 strings, but that would require a big change to the MIDI controller). The next version of this project will include SDRAM. The maximum number of waveguides will depend on how fast the design handles SDRAM transactions. The number of strings will be the max waveguide count divided by the number of dimensions supported. That said about dimensions, this instrument will not sound like any true natural instrument because of it's one dimensionality. It has characteristics that are found in natural instruments and I believe that is what gives this instrument a "more natural than a synthesizer" sort of sound. The instrument produces two major groups of sound, string-like and drum-like. With the filter bandwidth rather large, the sound will have more sustain and a brighter snappier attack, the lower register sounds harpsichord like and a bit higher sounds guitar-like. The more slowly decaying harmonics tend to have a metallic sound. The sound morphs slightly and gradually as you move up the scale. This effect is reduced by using more keyfollow for the pickup position. With low bandwidth, damping is rather quick, suppressing higher harmonics except during the very beginning of the sound. The drum sounds can be made to sound very much like tonal bongos or tonal congas, lowering the bandwidth increases the damping while increased bandwidth gives a longer resonant decay.

to:

Regarding the sound of the instrument, it is important to note that this physical model is one dimensional. That is, it simulates only one of the ways in which a real string vibrates. For more dimensions, additional waveguide systems are required per string. The FPGA I am using has too little internal RAM to do any more than 8 strings in one dimension (well, technically, I think I could squeeze 9 strings, but that would require a big change to the MIDI controller). The next version of this project will include SDRAM. The maximum number of waveguides will depend on how fast the design handles SDRAM transactions. The number of strings will be the max waveguide count divided by the number of dimensions supported. That said about dimensions, this instrument will not sound like any true natural instrument because of it's one dimensionality. It has characteristics that are found in natural instruments and I believe that is what gives this instrument a "more natural than a synthesizer" sort of sound. The instrument produces two major groups of sound, string-like and drum-like. With the filter bandwidth rather large, the sound will have more sustain and a brighter snappier attack, the lower register sounds harpsichord like and a bit higher sounds guitar-like. The more slowly decaying harmonics tend to have a metallic sound. The sound morphs slightly and gradually as you move up the scale. This effect is reduced by using more keyfollow for the pickup position. With low bandwidth, damping is rather quick, suppressing higher harmonics except during the very beginning of the sound. The drum sounds can be made to sound very much like tonal bongos or tonal congas, lowering the bandwidth increases the damping while increased bandwidth gives a longer resonant decay.

September 04, 2007, at 05:37 PM by Scott Gravenhorst -
Changed lines 134-135 from:

Regarding the sound of the instrument, it is important to note that this physical model is one dimensional. That is, it simulates only one of the ways in which a real string vibrates. For more dimensions, an additional waveguide system is required. The FPGA I am using has too little internal RAM to do any more than 8 strings in one dimension (well, technically, I think I could squeeze 9 strings, but that would require a big change to the MIDI controller). The next version of this project will include SDRAM. The maximum number of waveguides will depend on how fast the design handles SDRAM transactions. The number of strings will be the max waveguide count divided by the number of dimensions supported. That said about dimensions, this instrument will not sound like any true natural instrument because of it's one dimensionality. It has characteristics that are found in natural instruments and I believe that is what gives this instrument a "more natural than a synthesizer" sort of sound. The instrument produces two major groups of sound, string-like and drum-like. With the filter bandwidth rather large, the sound will have more sustain and a brighter snappier attack, the lower register sounds harpsichord like and a bit higher sounds guitar-like. The more slowly decaying harmonics tend to have a metallic sound. The sound morphs slightly and gradually as you move up the scale. This effect is reduced by using more keyfollow for the pickup position. With low bandwidth, damping is rather quick, suppressing higher harmonics except during the very beginning of the sound. The drum sounds can be made to sound very much like tonal bongos or tonal congas, lowering the bandwidth increases the damping while increased bandwidth gives a longer resonant decay.

to:

Regarding the sound of the instrument, it is important to note that this physical model is one dimensional. That is, it simulates only one of the ways in which a real string vibrates. For more dimensions, an additional waveguide system is required per string. The FPGA I am using has too little internal RAM to do any more than 8 strings in one dimension (well, technically, I think I could squeeze 9 strings, but that would require a big change to the MIDI controller). The next version of this project will include SDRAM. The maximum number of waveguides will depend on how fast the design handles SDRAM transactions. The number of strings will be the max waveguide count divided by the number of dimensions supported. That said about dimensions, this instrument will not sound like any true natural instrument because of it's one dimensionality. It has characteristics that are found in natural instruments and I believe that is what gives this instrument a "more natural than a synthesizer" sort of sound. The instrument produces two major groups of sound, string-like and drum-like. With the filter bandwidth rather large, the sound will have more sustain and a brighter snappier attack, the lower register sounds harpsichord like and a bit higher sounds guitar-like. The more slowly decaying harmonics tend to have a metallic sound. The sound morphs slightly and gradually as you move up the scale. This effect is reduced by using more keyfollow for the pickup position. With low bandwidth, damping is rather quick, suppressing higher harmonics except during the very beginning of the sound. The drum sounds can be made to sound very much like tonal bongos or tonal congas, lowering the bandwidth increases the damping while increased bandwidth gives a longer resonant decay.

September 04, 2007, at 05:36 PM by Scott Gravenhorst -
Added lines 134-135:

Regarding the sound of the instrument, it is important to note that this physical model is one dimensional. That is, it simulates only one of the ways in which a real string vibrates. For more dimensions, an additional waveguide system is required. The FPGA I am using has too little internal RAM to do any more than 8 strings in one dimension (well, technically, I think I could squeeze 9 strings, but that would require a big change to the MIDI controller). The next version of this project will include SDRAM. The maximum number of waveguides will depend on how fast the design handles SDRAM transactions. The number of strings will be the max waveguide count divided by the number of dimensions supported. That said about dimensions, this instrument will not sound like any true natural instrument because of it's one dimensionality. It has characteristics that are found in natural instruments and I believe that is what gives this instrument a "more natural than a synthesizer" sort of sound. The instrument produces two major groups of sound, string-like and drum-like. With the filter bandwidth rather large, the sound will have more sustain and a brighter snappier attack, the lower register sounds harpsichord like and a bit higher sounds guitar-like. The more slowly decaying harmonics tend to have a metallic sound. The sound morphs slightly and gradually as you move up the scale. This effect is reduced by using more keyfollow for the pickup position. With low bandwidth, damping is rather quick, suppressing higher harmonics except during the very beginning of the sound. The drum sounds can be made to sound very much like tonal bongos or tonal congas, lowering the bandwidth increases the damping while increased bandwidth gives a longer resonant decay.

September 03, 2007, at 03:58 PM by Scott Gravenhorst -
September 03, 2007, at 02:07 PM by Scott Gravenhorst -
Changed lines 262-263 from:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_j, 8 voices) Updated 08-30-2007
to:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_k, 8 voices) Updated 09-03-2007
September 02, 2007, at 09:36 PM by Scott Gravenhorst -
Changed lines 255-256 from:

I tightened the state machine from 14 clocks per string to 6 clocks per string. The total is now 49 clocks for the entire harp (one clock to initialize and start the state machine plus 6 clocks per string). This version is capable of a sample rate of 1 MHz.

to:

I tightened the string processing state machine from 14 clocks per string to 6 clocks per string. The total is now 49 clocks for the entire harp (one clock to initialize and start the state machine plus 6 clocks per string). This version is capable of a sample rate of 1 MHz.

September 02, 2007, at 09:11 PM by Scott Gravenhorst -
Added lines 257-258:

Other code cleanup to reduce the number of warnings and to conserve FPGA resources where possible.

September 02, 2007, at 09:08 PM by Scott Gravenhorst -
Changed line 276 from:

The rotary encoder on the Spartan-3E Start Kit can be either a clockwise or a counter clockwise one. If the filter action is backwards, you can force it to work correctly by placing a 10K resistor across user jack J1 pins I01(B4) and either Vcc or Gnd. The ones with white plastic bodies seem to work backward.

to:

The rotary encoder on the Spartan-3E Start Kit can be either a clockwise or a counter clockwise unit. If the filter action is backwards, you can force it to work correctly by placing a 10K resistor across user jack J1 pins I01(B4) and either Vcc or Gnd. The ones with white plastic bodies seem to work backward. For the blue body rotary encoders, put the resistor to Vcc, for the white body units, put the resistor to ground. This will correct the problem only using this synth (and future synths I design based on this board).

September 02, 2007, at 08:59 PM by Scott Gravenhorst -
Changed lines 255-256 from:

I tightened the state machine from 14 clocks per string to 6. The total is now 49 clocks for that harp (one clock to initialize and start the state machine plus 6 clocks per string). This version is capable of a sample rate of 1 MHz.

to:

I tightened the state machine from 14 clocks per string to 6 clocks per string. The total is now 49 clocks for the entire harp (one clock to initialize and start the state machine plus 6 clocks per string). This version is capable of a sample rate of 1 MHz.

September 02, 2007, at 08:57 PM by Scott Gravenhorst -
Changed lines 252-257 from:
to:

ver_k:

I tightened the state machine from 14 clocks per string to 6. The total is now 49 clocks for that harp (one clock to initialize and start the state machine plus 6 clocks per string). This version is capable of a sample rate of 1 MHz.


August 31, 2007, at 12:03 AM by Scott Gravenhorst -
Changed lines 234-242 from:
     0        very treble, low moderate keyboard tracking
     1        treble, moderate keyboard tracking
     2        full keyboard tracking
     3        bass, moderate keyboard tracking
     4        bass, low moderate keyboard tracking
     5        bass, low keyboard tracking
     6        very bass, slight keyboard tracking
     7        bassiest, very slight keyboard tracking
to:
     0        very treble, low moderate keyboard follow
     1        treble, moderate keyboard follow
     2        full keyboard follow
     3        bass, moderate keyboard follow
     4        bass, low moderate keyboard follow
     5        bass, low keyboard follow
     6        very bass, slight keyboard follow
     7        bassiest, very slight keyboard follow
August 30, 2007, at 11:34 PM by Scott Gravenhorst -
Changed lines 219-220 from:

ver_j:

to:

ver_j:

Changed line 243 from:
     The current mode will be displayed in the LEDs while button SOUTH is depressed.
to:
     The current setting will be displayed in the LEDs while button SOUTH is depressed.
August 30, 2007, at 09:47 PM by Scott Gravenhorst -
Changed lines 259-261 from:
  • PolyDaWG8-1.mp3 - PolyDaWG/8 Small (90 seconds) musical piece demonstrating the synth. I used 2 instruments, one is panned hard right, the other is panned hard left. The stereo and phasing effects of the two together is nice, but if you want to hear each instrument alone, you can. The difference between the two instruments is the filter setting.
  • PolyDaWG8-2.mp3 - PolyDaWG/8 ver_j, content similar to above, but the pickup position follows the keyboard shortening the distance for higher notes.
to:
  • PolyDaWG8-1.mp3 - PolyDaWG/8 Small (90 seconds) musical piece demonstrating the synth. I used 2 instruments, one is panned hard right, the other is panned hard left. The stereo and phasing effects of the two together is nice, but if you want to hear each instrument alone, you can. The difference between the two instruments is the filter setting. This piece uses a constant value for the pickup position.
  • PolyDaWG8-2.mp3 - PolyDaWG/8 ver_j, content similar to above, but the pickup position follows the keyboard, shortening the distance between the bridge and the pickup for higher notes.
August 30, 2007, at 09:42 PM by Scott Gravenhorst -
Changed lines 260-261 from:
to:
  • PolyDaWG8-2.mp3 - PolyDaWG/8 ver_j, content similar to above, but the pickup position follows the keyboard shortening the distance for higher notes.
August 30, 2007, at 08:14 PM by Scott Gravenhorst -
Deleted lines 217-227:

And here is the current code:

  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices)
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_h, 8 voices) Updated 08-27-2007

Sound Files:

  • PolyDaWG6-1.mp3 - PolyDaWG/6 Small Example Sound File (strings)
  • PolyDaWG8-1.mp3 - PolyDaWG/8 Small (90 seconds) musical piece demonstrating the synth. I used 2 instruments, one is panned hard right, the other is panned hard left. The stereo and phasing effects of the two together is nice, but if you want to hear each instrument alone, you can. The difference between the two instruments is the filter setting.

Note that this is a work in progress. As time goes by, I will probably find things to improve. I will post messages to SDIY and FPGA-Synth to alert of any changes to the code.

Added lines 219-263:

ver_j:

Controlling the pickup position:

There are two modes for controlling the pickup position, Normal and Original.

The machine powers on in Normal mode.

You can look at the lower right corner of the LCD to determine the mode. N for normal, O for original. A bit cheesey, I know, but it works.

Normal Mode:

  The mod wheel selects 1 of 8 keyboard follow configurations.

  SETTING     CHARACTER
     0        very treble, low moderate keyboard tracking
     1        treble, moderate keyboard tracking
     2        full keyboard tracking
     3        bass, moderate keyboard tracking
     4        bass, low moderate keyboard tracking
     5        bass, low keyboard tracking
     6        very bass, slight keyboard tracking
     7        bassiest, very slight keyboard tracking

     The current mode will be displayed in the LEDs while button SOUTH is depressed.
     Otherwise, the LEDs display the rotary encoder value.

Original Mode:

  This is the first control mechanism I designed and it has it's uses.  In this mode, the
  pickup position is not adjusted according to the note played.  Instead, the position value
  is controlled by the modulation wheel and it's value is applied to all notes regardless
  of the length of the string loop waveguide.

And here is the current code:

  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices)
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_j, 8 voices) Updated 08-30-2007

Sound Files:

  • PolyDaWG6-1.mp3 - PolyDaWG/6 Small Example Sound File (strings)
  • PolyDaWG8-1.mp3 - PolyDaWG/8 Small (90 seconds) musical piece demonstrating the synth. I used 2 instruments, one is panned hard right, the other is panned hard left. The stereo and phasing effects of the two together is nice, but if you want to hear each instrument alone, you can. The difference between the two instruments is the filter setting.

Note that this is a work in progress. As time goes by, I will probably find things to improve. I will post messages to SDIY and FPGA-Synth to alert of any changes to the code.

Changed lines 266-267 from:
to:

August 28, 2007, at 06:53 PM by Scott Gravenhorst -
Changed lines 199-200 from:

The instrument's timbre is controlled by both the variable IIR reflection point filter and by the pickup position. The reflection point filter determines how quickly the string is frequency and amplitude damped while the pickup position sets the intrument's "mellowness" factor. With the mod wheel at low values, it is like an electric guitar's bridge pickup while higher values give a sound like a neck pickup. The neck pickup settings tend to be more sinelike whereas the bridge pickup settings tend to have more high harmonics present.

to:

The instrument's timbre is controlled by both the variable IIR reflection point filter and by the pickup position. The reflection point filter determines how quickly the string is frequency and amplitude damped while the pickup position sets the intrument's "mellowness" factor. With the mod wheel at low values, it is like an electric guitar's bridge pickup while higher values give a sound like a neck pickup. The neck pickup settings tend to have fewer high harmonics whereas the bridge pickup settings tend to have more.

August 28, 2007, at 06:35 PM by Scott Gravenhorst -
Changed lines 210-211 from:

not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the filter's setting range. The pitch difference is then responisble for a phasing effect, something like that heard from a piano (though this synth is NOT a piano model).

to:

not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the filter's setting range. The pitch difference is then responsible for a phasing effect, something like that heard from a piano (though this synth is NOT a piano model).

August 28, 2007, at 06:32 PM by Scott Gravenhorst -
Changed lines 224-225 from:
  • PolyDaWG8-1.mp3 - PolyDawg/8 Small (90 seconds) musical piece demonstrating the synth. I used 2 instruments, one is panned hard right, the other is panned hard left. The stereo and phasing effects of the two together is nice, but if you want to hear each instrument alone, you can. The difference between the two instruments is the filter setting.
to:
  • PolyDaWG8-1.mp3 - PolyDaWG/8 Small (90 seconds) musical piece demonstrating the synth. I used 2 instruments, one is panned hard right, the other is panned hard left. The stereo and phasing effects of the two together is nice, but if you want to hear each instrument alone, you can. The difference between the two instruments is the filter setting.
August 28, 2007, at 04:43 PM by Scott Gravenhorst -
Changed line 222 from:

Sound File:

to:

Sound Files:

Changed lines 224-225 from:
to:
  • PolyDaWG8-1.mp3 - PolyDawg/8 Small (90 seconds) musical piece demonstrating the synth. I used 2 instruments, one is panned hard right, the other is panned hard left. The stereo and phasing effects of the two together is nice, but if you want to hear each instrument alone, you can. The difference between the two instruments is the filter setting.
August 27, 2007, at 06:24 PM by Scott Gravenhorst -
Changed lines 220-221 from:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_g, 8 voices) Updated 08-26-2007
to:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_h, 8 voices) Updated 08-27-2007
August 26, 2007, at 06:49 PM by Scott Gravenhorst -
Changed lines 220-221 from:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_g, 8 voices)
to:
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_g, 8 voices) Updated 08-26-2007
August 26, 2007, at 05:49 PM by Scott Gravenhorst -
Changed lines 197-198 from:

For now, the mod wheel is meant as an easy way to set the pickup position without system exclusive messages. In fact, there are no system exclusive message settings at all in this version. It is probably not good to use it as a performance control in this version. The Pitch Wheel is not programmed nor is after touch.

to:

For now, the mod wheel is meant as an easy way to set the pickup position without system exclusive messages. In fact, there are no system exclusive message settings at all in this version. It is probably not good to use the modulation wheel as a performance control in this version. The Pitch Wheel is not programmed nor is after touch.

August 26, 2007, at 05:29 PM by Scott Gravenhorst -
Changed lines 185-186 from:

There are two delay lines per string, the string loop delay line is 2048 x 18 (two block RAMs), the comb filter delay line is 256 x 18 (distributed RAM, four 64 x 18).

to:

There are two delay lines per string, the string loop delay line is 2048 x 18 (two block RAMs). The comb filter delay line is 256 x 18 (distributed RAM, four 64 x 18 RAMs).

August 26, 2007, at 05:26 PM by Scott Gravenhorst -
Added lines 185-186:

There are two delay lines per string, the string loop delay line is 2048 x 18 (two block RAMs), the comb filter delay line is 256 x 18 (distributed RAM, four 64 x 18).

August 26, 2007, at 05:23 PM by Scott Gravenhorst -
Changed line 9 from:

This project is a digital waveguide experiment (physical model).

to:

This project is a digital waveguide experiment (physical model of a tight string).

Added line 140:

Added line 168:

August 26, 2007, at 02:21 AM by Scott Gravenhorst -
Changed lines 102-103 from:

Switch 3 controls "linearization" of the filter. What I mean by "linearization" is that if the filter's bandwidth amount is the same for the entire range of pitches, the low end can sound like strings, but the hight end sounds drumlike. To fix this, I invented 2 algorithms to help. With switch 3 in the up position, the system is better for strings. If switch 3 is in the down position, it will work nicely for drums. For strings, you want the filter bandwidth setting higher. For drums, you want the filter bandwidth setting lower.

to:

Switch 3 controls "linearization" of the filter. What I mean by "linearization" is that if the filter's bandwidth amount is the same for the entire range of pitches, the low end can sound like strings, but the high end sounds drumlike. To fix this, I invented 2 algorithms to help. With switch 3 in the up position, the system is better for strings. If switch 3 is in the down position, it will work nicely for drums. For strings, you want the filter bandwidth setting higher. For drums, you want the filter bandwidth setting lower.

August 26, 2007, at 12:51 AM by Scott Gravenhorst -
Changed lines 215-217 from:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f 6 voices)
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_g 8 voices)
to:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f, 6 voices)
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_g, 8 voices)
August 26, 2007, at 12:49 AM by Scott Gravenhorst -
Changed lines 140-143 from:

Phase 3: PolyDaWG/6

6 Voice Polyphonic Physical Model String and Drum Synth

to:

Phase 3: PolyDaWG/8

8 Voice Polyphonic Physical Model String and Drum Synth

Changed lines 146-148 from:

A 6 voice polyphonic MIDI synthesizer based on the Karplus-Strong single delay line with movable pickup string model. This design uses only the FPGA internal resources and an extern SPI 12 bit DAC. 19 block RAMs and one multiplier are used. This is the first step in creating a larger polyphonic harp. The next step will be to replace the block RAMs with SDRAM, after which the block RAMs are available for additional features. I believe it is possible to use a miserly approach to the block RAMs and possible squeak out one more string from the block RAM version. The RAMs for the comb filter are too large and since they are dual ported, they could be cut in half thus freeing 3 more block RAMs for the additional string. If I do this, it will be in a later version.

to:

A 8 voice polyphonic MIDI synthesizer based on the Karplus-Strong single delay line with movable pickup string model. This design uses only the FPGA internal resources and an extern SPI 12 bit DAC. 17 block RAMs and one multiplier are used. This is the first step in creating a larger polyphonic harp. The next step will be to replace the block RAMs with SDRAM, after which the block RAMs are available for additional features. The RAMs for the comb filter are created using distributed RAM instead of block RAM.

Changed line 169 from:

The following is a block diagram of one of the 6 digital waveguide "strings".

to:

The following is a block diagram of one of the 8 digital waveguide "strings".

Changed lines 199-200 from:

Note that this synth is only 6 voice polyphonic, so if sustain is held down and more than 6 notes are played, an older ringing string will be "stolen" to produce the newest note's

to:

Note that this synth is only 8 voice polyphonic, so if sustain is held down and more than 8 notes are played, an older ringing string will be "stolen" to produce the newest note's

August 26, 2007, at 12:44 AM by Scott Gravenhorst -
Changed lines 215-217 from:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f)
to:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f 6 voices)
  • PolyDaWG8.zip - PolyDaWG/8 Source and Documentation files (ver_g 8 voices)
August 25, 2007, at 07:57 PM by Scott Gravenhorst -
Changed lines 193-195 from:

For now, the mod wheel is meant as an easy way to set the pickup position without sysex. In fact, there are no system exclusive message settings in this version at all. It is probably not good to use it as a performance control in this version. The Pitch Wheel is not programmed, nor is after touch.

to:

For now, the mod wheel is meant as an easy way to set the pickup position without system exclusive messages. In fact, there are no system exclusive message settings at all in this version. It is probably not good to use it as a performance control in this version. The Pitch Wheel is not programmed nor is after touch.

August 25, 2007, at 07:51 PM by Scott Gravenhorst -
Changed line 178 from:
      --[invert]---<----<---[Variable IIR]---   -->----->------->------>---->---
to:
      ----[invert]--<---<--[Variable IIR]----   ---->----->----->----->----->---
August 25, 2007, at 07:50 PM by Scott Gravenhorst -
Changed line 216 from:
to:
  • PolyDaWG6.zip - PolyDaWG/6 Source and Documentation files (ver_f)
August 25, 2007, at 07:18 PM by Scott Gravenhorst -
Added line 217:

Sound File:

August 25, 2007, at 07:06 PM by Scott Gravenhorst -
Changed lines 147-148 from:

movable pickup string model. This design uses only the FPGA internal resources. 19 block RAMs and one multiplier are used. This is the first step in creating a larger polyphonic harp. The next step will be to replace the block RAMs with SDRAM, after which the block RAMs are available for additional features. I believe it is possible to use a miserly approach to the block RAMs and possible squeak out one more string from the block RAM version. The RAMs for the comb filter are too large and since they are dual ported, they could be cut in half thus freeing 3 more block RAMs for the additional string. If I do this, it will be in a later version.

to:

movable pickup string model. This design uses only the FPGA internal resources and an extern SPI 12 bit DAC. 19 block RAMs and one multiplier are used. This is the first step in creating a larger polyphonic harp. The next step will be to replace the block RAMs with SDRAM, after which the block RAMs are available for additional features. I believe it is possible to use a miserly approach to the block RAMs and possible squeak out one more string from the block RAM version. The RAMs for the comb filter are too large and since they are dual ported, they could be cut in half thus freeing 3 more block RAMs for the additional string. If I do this, it will be in a later version.

August 25, 2007, at 07:03 PM by Scott Gravenhorst -
Changed lines 140-143 from:

Phase 3:

The PolyDaWG/6 6 Voice Polyphonic Physical Model String Synth

to:

Phase 3: PolyDaWG/6

6 Voice Polyphonic Physical Model String and Drum Synth

August 25, 2007, at 07:03 PM by Scott Gravenhorst -
Changed lines 147-148 from:

pickup position string model. This design uses only the FPGA internal resources. 19 block RAMs and one multiplier are used. This is the first step in creating a larger polyphonic harp. The next step will be to replace the block RAMs with SDRAM, after which the block RAMs are available for additional features. I believe it is possible to use a miserly approach to the block RAMs and possible squeak out one more string from the block RAM version. The RAMs for the comb filter are too large and since they are dual ported, they could be cut in half thus freeing 3 more block RAMs for the additional string. If I do this, it will be in a later version.

to:

movable pickup string model. This design uses only the FPGA internal resources. 19 block RAMs and one multiplier are used. This is the first step in creating a larger polyphonic harp. The next step will be to replace the block RAMs with SDRAM, after which the block RAMs are available for additional features. I believe it is possible to use a miserly approach to the block RAMs and possible squeak out one more string from the block RAM version. The RAMs for the comb filter are too large and since they are dual ported, they could be cut in half thus freeing 3 more block RAMs for the additional string. If I do this, it will be in a later version.

August 25, 2007, at 07:00 PM by Scott Gravenhorst -
Changed line 157 from:

Switch 3 Controls filter contour setting

to:

Switch 3 Controls filter keyboard follow setting

August 25, 2007, at 06:17 PM by Scott Gravenhorst -
Added lines 213-214:

The nonlinearity I experimented with in the monosynth version has been removed. I've determined that if there is an effect from it, I cannot hear it.

Added line 221:
August 25, 2007, at 06:12 PM by Scott Gravenhorst -
Changed lines 215-216 from:
to:
August 25, 2007, at 06:11 PM by Scott Gravenhorst -
Changed lines 215-216 from:
to:
August 25, 2007, at 05:48 PM by Scott Gravenhorst -
Added lines 216-217:

Note that this is a work in progress. As time goes by, I will probably find things to improve. I will post messages to SDIY and FPGA-Synth to alert of any changes to the code.

August 25, 2007, at 05:19 PM by Scott Gravenhorst -
Changed lines 207-208 from:

not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the range. The pitch difference is then responisble for a phasing effect, something like that heard from a piano (though this synth is NOT a piano model).

to:

not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the filter's setting range. The pitch difference is then responisble for a phasing effect, something like that heard from a piano (though this synth is NOT a piano model).

August 25, 2007, at 05:16 PM by Scott Gravenhorst -
Changed lines 207-208 from:

not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the range.

to:

not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the range. The pitch difference is then responisble for a phasing effect, something like that heard from a piano (though this synth is NOT a piano model).

August 25, 2007, at 05:13 PM by Scott Gravenhorst -
Deleted line 195:

<<<<<<<

Deleted lines 197-200:

======= The instrument's timbre is controlled by both the variable IIR reflection point filter and by the pickup position. The reflection point filter determines how quickly the string is frequency and amplitude damped while the pickup position sets the intruments "mellowness" factor. With the mod wheel at low values, it is like an electric guitar's bridge pickup while higher values give a sound like a neck pickup. The neck pickup settings tend to be more sinelike whereas the bridge pickup settings tend to have more high harmonics present.

>>>>>>>

August 25, 2007, at 05:11 PM by Scott Gravenhorst -
Added lines 196-199:

<<<<<<< The instrument's timbre is controlled by both the variable IIR reflection point filter and by the pickup position. The reflection point filter determines how quickly the string is frequency and amplitude damped while the pickup position sets the intrument's "mellowness" factor. With the mod wheel at low values, it is like an electric guitar's bridge pickup while higher values give a sound like a neck pickup. The neck pickup settings tend to be more sinelike whereas the bridge pickup settings tend to have more high harmonics present.

=======

Added line 202:

>>>>>>>

August 25, 2007, at 05:11 PM by Scott Gravenhorst -
Added lines 196-197:

The instrument's timbre is controlled by both the variable IIR reflection point filter and by the pickup position. The reflection point filter determines how quickly the string is frequency and amplitude damped while the pickup position sets the intruments "mellowness" factor. With the mod wheel at low values, it is like an electric guitar's bridge pickup while higher values give a sound like a neck pickup. The neck pickup settings tend to be more sinelike whereas the bridge pickup settings tend to have more high harmonics present.

August 25, 2007, at 04:33 PM by Scott Gravenhorst -
Changed line 178 from:
      --[invert]--<---<---<--[Variable IIR]--   -->----->------->------>---->---
to:
      --[invert]---<----<---[Variable IIR]---   -->----->------->------>---->---
August 25, 2007, at 04:32 PM by Scott Gravenhorst -
Changed lines 183-184 from:

The reflection point filter (Variable IIR) is controlled using the rotary encoder. Clockwise rotation increases the filter's bandwidth. Higher bandwidth will give a more metallic

to:

The single shared reflection point filter (Variable IIR) is controlled using the rotary encoder. Clockwise rotation increases the filter's bandwidth. Higher bandwidth will give a more metallic

August 25, 2007, at 04:30 PM by Scott Gravenhorst -
Changed lines 194-196 from:

For now, the mod wheel is meant as an easy way to set the pickup position without sysex. It is probably not good to use it as a performance control in this version.

to:

For now, the mod wheel is meant as an easy way to set the pickup position without sysex. In fact, there are no system exclusive message settings in this version at all. It is probably not good to use it as a performance control in this version. The Pitch Wheel is not programmed, nor is after touch.

August 25, 2007, at 04:26 PM by Scott Gravenhorst -
Changed lines 179-180 from:
                                                      Timbre
to:
                                                                Timbre
August 25, 2007, at 04:25 PM by Scott Gravenhorst -
Added lines 167-168:

The Synth:

August 25, 2007, at 04:23 PM by Scott Gravenhorst -
Changed lines 214-216 from:
to:


August 25, 2007, at 04:23 PM by Scott Gravenhorst -
Changed lines 210-212 from:
to:

And here is the current code:

August 25, 2007, at 04:21 PM by Scott Gravenhorst -
Changed lines 204-205 from:

not only the timbre of the string, but also the pitch.

to:

not only the timbre of the string, but also the pitch. The pitch is affected by this more at the low (especially drum sounds) end of the range.

August 25, 2007, at 04:17 PM by Scott Gravenhorst -
Changed line 62 from:
to:

'''[@

Changed lines 78-80 from:
to:

@]'''

Changed line 113 from:

[@

to:

'''[@

Changed line 124 from:

@]

to:

@]'''

August 25, 2007, at 04:16 PM by Scott Gravenhorst -
Changed line 169 from:

[@''

to:

'''[@

Changed lines 180-181 from:

''@]

to:

@]'''

August 25, 2007, at 04:15 PM by Scott Gravenhorst -
Changed lines 145-147 from:
           [ PolyDaWG/6 ]
to:

Designed by Scott R. Gravenhorst, 24-Aug-2007

Changed lines 149-152 from:

pickup position string model.

Designed by Scott R. Gravenhorst, 24-Aug-2007

to:

pickup position string model. This design uses only the FPGA internal resources. 19 block RAMs and one multiplier are used. This is the first step in creating a larger polyphonic harp. The next step will be to replace the block RAMs with SDRAM, after which the block RAMs are available for additional features. I believe it is possible to use a miserly approach to the block RAMs and possible squeak out one more string from the block RAM version. The RAMs for the comb filter are too large and since they are dual ported, they could be cut in half thus freeing 3 more block RAMs for the additional string. If I do this, it will be in a later version.

Changed lines 165-166 from:

LEDs display the upper 8 bits of the filter rotary encoder value which is a

to:

The LEDs display the upper 8 bits of the filter rotary encoder value which is a

Added line 182:
Changed line 219 from:

The rotary encoder on the Spartan-3E Start Kit can be either a clockwise or a counter clockwise one. If the filter action is backwards, you can force it to work correctly by placing a 10K resistor across user jack J1 pins I01(B4) and either Vcc or Gnd. The ones with white plastic bodies seem to work backward.

to:

The rotary encoder on the Spartan-3E Start Kit can be either a clockwise or a counter clockwise one. If the filter action is backwards, you can force it to work correctly by placing a 10K resistor across user jack J1 pins I01(B4) and either Vcc or Gnd. The ones with white plastic bodies seem to work backward.

August 25, 2007, at 04:15 PM by Scott Gravenhorst -
Deleted line 140:
Changed lines 150-153 from:

Slide Switches:

to:

Slide Switches:

Added lines 162-163:

LEDS:

Changed line 169 from:

[@

to:

[@''

Changed lines 180-181 from:

@]

to:

''@]

August 25, 2007, at 04:08 PM by Scott Gravenhorst -
August 25, 2007, at 04:07 PM by Scott Gravenhorst -
Deleted line 139:
Added lines 142-218:

Phase 3:

The PolyDaWG/6 6 Voice Polyphonic Physical Model String Synth

           [ PolyDaWG/6 ]

A 6 voice polyphonic MIDI synthesizer based on the Karplus-Strong single delay line with pickup position string model.

Designed by Scott R. Gravenhorst, 24-Aug-2007


Slide Switches:

Switch [1:0] select MIDI channel 1 through 4

Switch 2 controls the excitation pulse shape:

  off = velocity controlled rectangular pulse
   on = fixed width sawtooth pluck

Switch 3 Controls filter contour setting

  off = better for drums, set bandwidth low
   on = better for strings, set bandwidth high

LEDs display the upper 8 bits of the filter rotary encoder value which is a basic indication of the filter setting (because this value is then modified by the note number received on each string pluck, see Verilog code).

The following is a block diagram of one of the 6 digital waveguide "strings".

                                                   Length gives
excite               Length gives pitch            pickup position
\                      \                            \
 >--[add]-->-[CLIP]->-[variable delay line]--->---[variable delay line]->-[subtract]--> out
      |                                     |   |                              |
      ^           STRING LOOP               V   V         COMB FILTER          ^
      |                                     |   |                              |
      --[invert]--<---<---<--[Variable IIR]--   -->----->------->------>---->---
                           \
                           Timbre

The reflection point filter (Variable IIR) is controlled using the rotary encoder. Clockwise rotation increases the filter's bandwidth. Higher bandwidth will give a more metallic sound with longer sustain. Lowering the bandwidth shortens sustain. If the bandwidth is low enough, you will get drum-like sounds (kind of like tonal bongos or congas). For drum sounds, switch 3 should be set off so that the entire range becomes drum sounds. For plucked strings, set switch 3 on for consistent string sounds accross the instrument's range.

The pickup position is controlled with the MIDI modulation wheel. It affects the sound much like an electric guitar's pickup position. Note that because of dirty RAM after moving the wheel, the synth may produce a low level of noise while moving the wheel. The noise abates as soon as the wheel stops moving. If I find a way to fix this, I will (future version). For now, the mod wheel is meant as an easy way to set the pickup position without sysex. It is probably not good to use it as a performance control in this version.

The sustain pedal acts like a piano's. Undepressed, each note played is held only as long as the key is held down. Depressed, each note played rings until the pedal is released. Note that this synth is only 6 voice polyphonic, so if sustain is held down and more than 6 notes are played, an older ringing string will be "stolen" to produce the newest note's sound.

I have found that two of these instruments on the same MIDI channel with slightly different filter settings sound very full and rich. This is due to the fact that the filter provides a small delay which varies with bandwidth. Thus different filter settings will change not only the timbre of the string, but also the pitch.

The basic pitch range of the instrument is determined by the sample rate. As it exists in the zip file, the system is programmed for 250 KHz. You can change this to 125 KHz to lower the instrument one octave. The range is 3.5 octaves regardless of the sample rate.


August 22, 2007, at 07:10 PM by Scott Gravenhorst -
Added lines 140-145:

Rotary Encoder Odd Behavior

The rotary encoder on the Spartan-3E Start Kit can be either a clockwise or a counter clockwise one. If the filter action is backwards, you can force it to work correctly by placing a 10K resistor across user jack J1 pins I01(B4) and either Vcc or Gnd. The ones with white plastic bodies seem to work backward.

August 20, 2007, at 09:02 PM by Scott Gravenhorst -
Added line 93:
Added line 95:
Changed lines 109-110 from:
to:

August 20, 2007, at 09:01 PM by Scott Gravenhorst -
Changed lines 108-109 from:

PHASE 2:

to:

PHASE 2:

Changed lines 128-129 from:

Some Conclusions:

to:

Some Conclusions:

Changed lines 133-134 from:

Where This Will Go:

to:

Where This Will Go:

August 20, 2007, at 09:01 PM by Scott Gravenhorst -
Changed line 93 from:

A Digital Waveguide Monosynth

to:

A Digital Waveguide Monosynth

August 20, 2007, at 08:58 PM by Scott Gravenhorst -
Changed lines 108-109 from:

PHASE 2:

to:

PHASE 2:

Changed lines 128-129 from:

Some Conclusions:

to:

Some Conclusions:

Changed lines 133-134 from:

Where This Will Go:

to:

Where This Will Go:

August 20, 2007, at 08:58 PM by Scott Gravenhorst -
Changed lines 135-136 from:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU ROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand it by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

to:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU ROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand it by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string polyphonic harp working with block RAM.

August 20, 2007, at 08:56 PM by Scott Gravenhorst -
Changed lines 130-131 from:

In doing this project, I learned some important things. One of them has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad. Also, as the pitch is increased (waveguide length decreased), the effect of this extra delay is more and more apparent. I did not notice, however, that any pitch within the instrument's range was so far out of tune as to be obvious, only that as pitch increases, differences between filter settings make for faster phasing (for two or more synths played to gether).

to:

In doing this project, I learned some important things. One of them has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad. Also, as the pitch is increased (waveguide length decreased), the effect of this extra delay is more and more apparent. I did not notice, however, that any pitch within the instrument's range was so far out of tune as to be obvious, only that as pitch increases, differences between filter settings make for faster phasing (for two or more synths played together).

August 20, 2007, at 08:53 PM by Scott Gravenhorst -
Changed lines 135-136 from:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU ROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

to:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU ROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand it by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

August 20, 2007, at 08:51 PM by Scott Gravenhorst -
Changed lines 135-136 from:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU PROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

to:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU ROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

August 20, 2007, at 08:51 PM by Scott Gravenhorst -
Changed line 135 from:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the sample (250 KHz) rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU PROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

to:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the 250 KHz sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU PROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

August 20, 2007, at 08:48 PM by Scott Gravenhorst -
Changed line 135 from:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string. Only one multiplier will be used in the design and one block RAM is used for the MIDI controller MCU PROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit.

to:

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the sample (250 KHz) rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string - well more than enough. Only one multiplier will be used in the design. One block RAM is used for the MIDI controller MCU PROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit. Once I have this working, I may then expand by using the SDRAM, but for now, it will be sufficiently challenging to get a 6 string harp working with block RAM.

August 20, 2007, at 08:44 PM by Scott Gravenhorst -
Changed lines 133-134 from:

Where This Will Go

to:

Where This Will Go:

August 20, 2007, at 08:43 PM by Scott Gravenhorst -
Changed lines 130-131 from:

In doing this project, I learned some important things. One of them has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad.

to:

In doing this project, I learned some important things. One of them has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad. Also, as the pitch is increased (waveguide length decreased), the effect of this extra delay is more and more apparent. I did not notice, however, that any pitch within the instrument's range was so far out of tune as to be obvious, only that as pitch increases, differences between filter settings make for faster phasing (for two or more synths played to gether).


Where This Will Go

My desire has always been to do a polysynth, so I will start with this one. My original plan was to use SDRAM for the waveguides so that I could have many strings. However, at the moment, the SDRAM is both a mystery and I'm told it's not a piece of cake to use. After rearranging the code for the monosynth version, I've determined that I can make a six string harp using block RAM. This will require that I share the filter for all 6 strings. This seems possible because the sample rate allows 200 system clock cycles for each sample clock. That would leave about 33 system clock cycles to process each string. Only one multiplier will be used in the design and one block RAM is used for the MIDI controller MCU PROM leaving 18 block RAMs for strings. Each string requires 3 block RAMs, so it will just fit.

August 20, 2007, at 08:36 PM by Scott Gravenhorst -
Changed lines 130-131 from:

In doing this project, I learned some important things. One important thing has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad.

to:

In doing this project, I learned some important things. One of them has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad.

August 20, 2007, at 08:34 PM by Scott Gravenhorst -
Changed lines 127-128 from:
to:

Some Conclusions:

In doing this project, I learned some important things. One important thing has to do with delays. I was expecting that the waveguide's length would be the only factor in setting the pitch of a string. This is not true in this design because there is an IIR filter in the string loop. It turns out that the IIR filter provides a variable delay of zero to one sample time. Because the waveguides are 2048 locations long, this isn't a huge problem, but it is apparent when using two of these synths together. The more different the filter settings are, the more the strings are detuned with respect to each other. This can provide a nice phasing effect, so it's not entirely bad.

August 17, 2007, at 11:50 PM by Scott Gravenhorst -
Changed lines 123-124 from:

The new code now plays 3.5 octaves, the modulation wheel sets the pickup position. The switches and rotary encoder are as they were in the my first cut, above. This code uses 3 block RAMs instead of 4 for the string model (for a total of 4 including the MCU ROM instead of 5).

to:

The new code now plays 3.5 octaves, the modulation wheel sets the pickup position. The switches and rotary encoder are as they were in my first cut, above. This code uses 3 block RAMs instead of 4 for the string model (for a total of 4 including the MCU ROM instead of 5).

August 17, 2007, at 11:44 PM by Scott Gravenhorst -
Changed lines 123-124 from:

The new code now plays 3.5 octaves, the modulation wheel sets the pickup position. The switches and rotary encoder are as they were in the my first cut, above. This code uses 3 block RAMs instead of 4.

to:

The new code now plays 3.5 octaves, the modulation wheel sets the pickup position. The switches and rotary encoder are as they were in the my first cut, above. This code uses 3 block RAMs instead of 4 for the string model (for a total of 4 including the MCU ROM instead of 5).

August 17, 2007, at 10:51 PM by Scott Gravenhorst -
Changed lines 106-107 from:

======================================================

to:

August 17, 2007, at 10:47 PM by Scott Gravenhorst -
Changed lines 94-95 from:
to:
Changed lines 123-127 from:

The new code now plays 3.5 octaves, the modulation wheel sets the pickup position. The switches and rotary encoder are as they were in the my first cut, above.

to:

The new code now plays 3.5 octaves, the modulation wheel sets the pickup position. The switches and rotary encoder are as they were in the my first cut, above. This code uses 3 block RAMs instead of 4.

August 17, 2007, at 10:38 PM by Scott Gravenhorst -
Changed line 111 from:
to:

[@

Changed line 122 from:
to:

@]

August 17, 2007, at 10:36 PM by Scott Gravenhorst -
Added lines 105-127:

======================================================

PHASE 2:

I found it simpler to use the Karplus-Strong Single Delay Line model.

                                             Length gives

excite Length gives pitch pickup position \ \ >--[add]-->--[variable delay line]--->----[variable delay line]-->--[subtract]--> output

      |                             |   |                                 |
      ^        STRING LOOP          V   V          COMB FILTER            ^
      |                             |   |                                 |
      --[invert]--<--[Variable IIR]--   -->------>------->------->----->---
                                                      Timbre

The new code now plays 3.5 octaves, the modulation wheel sets the pickup position. The switches and rotary encoder are as they were in the my first cut, above.

August 04, 2007, at 11:33 PM by Scott Gravenhorst -
Added lines 96-98:

Slide Switches: Switch 0 and 1 control the MIDI channel, 1 through 4.

Added lines 102-104:

Rotary Encoder: Controls the reflection point filter bandwidth. The higher the setting (twisting to the right increases), the more stringlike, and the less drumlike.

August 04, 2007, at 11:28 PM by Scott Gravenhorst -
Added line 93:

A Digital Waveguide Monosynth

August 04, 2007, at 11:27 PM by Scott Gravenhorst -
Changed lines 95-96 from:

Switch 2 controls the excitation pulse shape. If off or down, a velocity sensitive rectangular pulse height is used.

to:

Switch 2 controls the excitation pulse shape. If off or down, a velocity sensitive rectangular pulse height is used. If switch 2 is on or up, the pulse is a sawtooth, ramping front end with fixed height and width.

August 04, 2007, at 11:25 PM by Scott Gravenhorst -
Added lines 95-96:

Switch 2 controls the excitation pulse shape. If off or down, a velocity sensitive rectangular pulse height is used.

August 04, 2007, at 11:23 PM by Scott Gravenhorst -
Deleted line 94:
August 04, 2007, at 11:22 PM by Scott Gravenhorst -
Changed lines 95-96 from:
to:

Switch 3 controls "linearization" of the filter. What I mean by "linearization" is that if the filter's bandwidth amount is the same for the entire range of pitches, the low end can sound like strings, but the hight end sounds drumlike. To fix this, I invented 2 algorithms to help. With switch 3 in the up position, the system is better for strings. If switch 3 is in the down position, it will work nicely for drums. For strings, you want the filter bandwidth setting higher. For drums, you want the filter bandwidth setting lower.

August 04, 2007, at 11:15 PM by Scott Gravenhorst -
Changed lines 93-95 from:
to:
August 04, 2007, at 11:13 PM by Scott Gravenhorst -
Changed lines 93-95 from:
  • [[(Attach:)DWG_monosynth_ver_f.zip - A Simple Digital Waveguide Monosynth
to:
August 04, 2007, at 11:11 PM by Scott Gravenhorst -
Changed lines 91-95 from:
to:

  • [[(Attach:)DWG_monosynth_ver_f.zip - A Simple Digital Waveguide Monosynth
August 02, 2007, at 12:33 PM by Scott Gravenhorst -
Changed line 55 from:

The EAST button is a squelch/dampen control to silence the system.

to:

The EAST button is a squelch/damping control to silence the system.

August 01, 2007, at 04:46 PM by Scott Gravenhorst -
Changed lines 85-86 from:

it sounds drum like and progresses to a more metallic sound.

to:

it sounds like clicks due to severe filter attenuation, then drum like and progresses to a more metallic sound.

August 01, 2007, at 04:32 PM by Scott Gravenhorst -
Added line 91:
July 31, 2007, at 08:32 PM by Scott Gravenhorst -
Added lines 80-90:

Here are some MP3 sample files, in each one, a single pitch was selected and the synth's reflection point filters were set at bandwidth = 0, then as the key is struck, the filter is opened up slowly to demonstrate the action of the filter. In all cases, most of the sample includes re-excitation of the system while it is already vibrating. Note how at first it sounds drum like and progresses to a more metallic sound.

July 31, 2007, at 06:05 PM by Scott Gravenhorst -
Changed lines 57-58 from:

an MCU system reset.

to:

an MCU system reset. The right 3 slide switches select MIDI channel 1 through 8, the left most slide switch enables or disables the nonlinearity.

July 31, 2007, at 06:04 PM by Scott Gravenhorst -
July 31, 2007, at 05:51 PM by Scott Gravenhorst -
Added lines 43-48:

Excitation is applied through logic which sums the current output of IIR1 with the excitation signal. In this experiment, only a rectangular pulse is available, however, simple changes to the code can control the width of the pulse. Current code sets the pulse at a proportion of the waveguide delay line length.

Deleted lines 54-59:

Excitation is applied through logic which sums the current output of IIR1 with the excitation signal. In this experiment, only a rectangular pulse is available, however, simple changes to the code can control the width of the pulse. Current code sets the pulse at a proportion of the waveguide delay line length.

July 31, 2007, at 05:49 PM by Scott Gravenhorst -
Added lines 40-42:

Hard clipping is employed to prevent overflow distortion when the system is excited while it is already vibrating.

Deleted lines 48-50:

Hard clipping is employed to prevent overflow distortion when the system is excited while it is already vibrating.

July 31, 2007, at 05:48 PM by Scott Gravenhorst -
Deleted lines 45-48:

The EAST button is a squelch/dampen control to silence the system. The SOUTH button controls the LED display and the NORTH button causes an MCU system reset.

Added lines 55-58:

The EAST button is a squelch/dampen control to silence the system. The SOUTH button controls the LED display and the NORTH button causes an MCU system reset.

July 31, 2007, at 05:47 PM by Scott Gravenhorst -
Changed lines 46-48 from:

The EAST button is a squelch/dampen control. SOUTH controls the LED display and NORTH is an MCU system reset.

to:

The EAST button is a squelch/dampen control to silence the system. The SOUTH button controls the LED display and the NORTH button causes an MCU system reset.

July 31, 2007, at 05:45 PM by Scott Gravenhorst -
Changed lines 43-44 from:

Both endpoint filters are controlled by the same bandwidth parameter.

to:

Both endpoint filters are controlled by the same bandwidth parameter and behave identically.

July 31, 2007, at 05:43 PM by Scott Gravenhorst -
Changed line 35 from:

max amplitude. Between the threshholds, gain is unity, when the

to:

max amplitude. Between the threshholds, gain is unity. When the

July 31, 2007, at 05:40 PM by Scott Gravenhorst -
Changed lines 42-44 from:

change of the filters' bandwidth value. Both endpoint filters are controlled by the same bandwidth parameter.

to:

change of the filters' bandwidth value when the encoder is rotated. Both endpoint filters are controlled by the same bandwidth parameter.

July 31, 2007, at 05:38 PM by Scott Gravenhorst -
Changed lines 33-34 from:

passing through it. The threshhold of switching from unity gain to low gain is 3/4 of positive max amplitude and 3/4 of negative

to:

passing through it. The threshholds of switching from unity gain to low gain are 3/4 of positive max amplitude and 3/4 of negative

July 31, 2007, at 05:36 PM by Scott Gravenhorst -
Changed lines 26-27 from:

both clocked simultaneously at 500 KHz.

to:

both clocked simultaneously at the sample rate of 500 KHz.

July 31, 2007, at 05:35 PM by Scott Gravenhorst -
Changed line 23 from:

Each RAM can connects through a nonlinearity at the input of

to:

Each RAM can connect through a nonlinearity at the input of

July 31, 2007, at 05:34 PM by Scott Gravenhorst -
Changed lines 18-19 from:

The 2 RAMs are used to pass a signal from one end to the other, each RAM is dedicated to one direction, one left and one right.

to:

The 2 RAMs are used to pass a signal from one end to the other with delay. Each RAM is dedicated to one direction, one left and one right.

July 31, 2007, at 05:34 PM by Scott Gravenhorst -
Changed line 14 from:

simple numerically tunable IIR filters (identical to the filters

to:

simple numerically tunable IIR filters (identical to the filter

July 31, 2007, at 05:33 PM by Scott Gravenhorst -
Changed line 14 from:

simple numerically tunable filters (identical to the filters

to:

simple numerically tunable IIR filters (identical to the filters

July 31, 2007, at 05:32 PM by Scott Gravenhorst -
Changed lines 5-6 from:

Digital Waveguide Experiment

to:

Digital Waveguide Experiment

July 31, 2007, at 05:32 PM by Scott Gravenhorst -
Changed lines 5-8 from:

Digital Waveguide Experiment

Description:

to:

Digital Waveguide Experiment

Description:

July 31, 2007, at 05:31 PM by Scott Gravenhorst -
Changed lines 7-8 from:

Description:

to:

Description:

July 31, 2007, at 05:30 PM by Scott Gravenhorst -
Changed lines 5-75 from:

Digital Waveguide Experiment

to:

Digital Waveguide Experiment

Description:

This project is a digital waveguide experiment (physical model). Access to the system is provided by an embedded MIDI controller.

The main components of the system are two 18 bit wide x 2048 location RAMs (block RAM) acting as digital delay lines, two simple numerically tunable filters (identical to the filters used in the GateMan-I synth), a simple nonlinearity and a numerically moveable pickup.

The 2 RAMs are used to pass a signal from one end to the other, each RAM is dedicated to one direction, one left and one right. The pickup is a selectable tap point on each RAM which is summed to provide the system's output signal to the DAC.

Each RAM can connects through a nonlinearity at the input of it's IIR filter. The output of each filter is then routed to the input of the "other" RAM delay line. The delay lines are both clocked simultaneously at 500 KHz.

Additionally, each filter's output is inverted before applying it to the receiving delay line.

The nonlinearity consists of logic which monitors the delay line output amplitude and controls the gain applied to the signal passing through it. The threshhold of switching from unity gain to low gain is 3/4 of positive max amplitude and 3/4 of negative max amplitude. Between the threshholds, gain is unity, when the signal crosses the threshhold, the gain is reduced. This simple nonlinearity adds harmonic content and makes the sound more interesting, under some conditions it is rather bell-like.

The rotary encoder is programmed to control the IIR filters' bandwidth. The WEST pushbutton switch allows for much faster change of the filters' bandwidth value. Both endpoint filters are controlled by the same bandwidth parameter.

The EAST button is a squelch/dampen control. SOUTH controls the LED display and NORTH is an MCU system reset.

Hard clipping is employed to prevent overflow distortion when the system is excited while it is already vibrating.

Excitation is applied through logic which sums the current output of IIR1 with the excitation signal. In this experiment, only a rectangular pulse is available, however, simple changes to the code can control the width of the pulse. Current code sets the pulse at a proportion of the waveguide delay line length.

Here's an ASCII diagram of the system:

                                                     length
          on/off         BW                          control
            |            |                              |
  +--> nonlinearity --> IIR0 --> sign inversion --> delay line ----->----->----->-------+
  |                                                    |                                |
  |                                                    |                                |
  |                             pickup                 |                                |
  ^       +--------------------> SUM <-----------------+                                V
  |       |                       |                                                     |
  |       |                       +----> OUTPUT                                         |
  |       |                                                                             |
  +-<- delay line <-- hard clip <-- SUM <-- sign inversion <-- IIR1 <-- nonlinearity <--+
            |                        ^                          |            |
          length                     |                          BW          on/off
          control                    +--< Excitation input
July 31, 2007, at 05:30 PM by Scott Gravenhorst -
Added lines 1-5:

Author: Scott Gravenhorst

Verilog, designed for Spartan-3E SK, certainly adaptable for others.

Digital Waveguide Experiment

July 31, 2007, at 05:28 PM by Scott Gravenhorst -