Re: [fluid-dev] FluidSynth problem/"patch"

[Joerg Anders]

On Wed, 3 Dec 2003, Josh Green wrote:

> Can you explain in words what the problems ...

... not in words but in sounds (see below)

> the strings? From the first samples I listened to it sounded like you
> were referring to the attack envelope being too dramatic and causing an
> excessive surge of volume at the beginning of the instrument. From your
> big band tests it sounds more like you are referring to the strings
> being too quiet? Are those the same instrument? ...

... Yes, and of course it does not help to increase the string volume.
Again, have a look at:

  http://rnvs.informatik.tu-chemnitz.de/SYNTH/synth.html

I added an MP3 with increased string volume. This is also very dramatic
because now you hear a terrible loud attack. After the attack the strings
sound as expacted.

> 
> I'm not sure what would cause the attack envelope to be too sharp, ..

... after hearing the example you will be very convinced. There are
also the 2 MIDI files. Thus, you can make your own attemts (the
same happens with FluidR3 soundfont, see
 http://www.hammersound.net). I cannot imagine you get different results.

> FluidSynth's volume envelope attenuation
> currently follows the SoundFont specification...

Believe me: The is an error. Your statement would mean all others
are wrong: The AWE64/32 hardware MIDI synthesizer is wrong, the
the Audigy2 emu10k1 hardware MIDI synthesizer is wrong, all
MIDI synthesizers on M$-Windows are wrong, TiMidity++ is wrong.
Because they all play the bigband example like in bigband_hardware.mp3

> This breaks with a lot of
> EMU8k patches because they don't follow it. The solution would be to
> have FluidSynth detect that an EMU8k is the target for the SoundFont and
> configure itself to the broken (in regard to specs) way in which it
> deals with the attenuation parameter. You can verify that this is the
> cause by changing the attenuation parameter for that instrument with a
> SoundFont editor (such as Swami). 

I assume there is a very rare SF2 statement in strings. (BTW: The
same happens with clarinets, but not with FluidR3 font, only with
8mbgmsfx.sf2)

BTW: I can "fix" the error by applying the following patch:

$ diff -au fluidsynth-1.0.3/src/fluid_voice.c.ori  
fluidsynth-1.0.3/src/fluid_voice.c.new
--- fluidsynth-1.0.3/src/fluid_voice.c.ori      2003-11-26 12:39:45.000000000 
+0100
+++ fluidsynth-1.0.3/src/fluid_voice.c.new      2003-11-26 12:30:25.000000000 
+0100
@@ -1359,6 +1359,7 @@
   case GEN_VOLENVHOLD:                 /* SF2.01 section 8.1.3 # 35 */
   case GEN_KEYTOVOLENVHOLD:            /* SF2.01 section 8.1.3 # 39 */
     count = calculate_hold_decay_buffers(voice, GEN_VOLENVHOLD, 
GEN_KEYTOVOLENVHOLD, 0); /* 0 means: hold */
+    if (count < 98) count = 19464;
     voice->volenv_data[FLUID_VOICE_ENVHOLD].count = count;
     voice->volenv_data[FLUID_VOICE_ENVHOLD].coeff = 1.0f;
     voice->volenv_data[FLUID_VOICE_ENVHOLD].incr = 0.0f;
@@ -1370,6 +1371,7 @@
   case GEN_VOLENVSUSTAIN:             /* SF2.01 section 8.1.3 # 37 */
   case GEN_KEYTOVOLENVDECAY:          /* SF2.01 section 8.1.3 # 40 */
     count = calculate_hold_decay_buffers(voice, GEN_VOLENVDECAY, 
GEN_KEYTOVOLENVDECAY, 1); /* 1 for decay */
+    if (count < 2000) count = 19464;
     voice->volenv_data[FLUID_VOICE_ENVDECAY].count = count;
     voice->volenv_data[FLUID_VOICE_ENVDECAY].coeff = 1.0f;
     voice->volenv_data[FLUID_VOICE_ENVDECAY].incr = count ? -1.0f / count : 
0.0f;

But this is barbarism. I don't know which effects this has to other soundfonts.
And I cannot explain why this fixes the problem.

-- 
J.Anders, Chemnitz, GERMANY (address@hidden)