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

[Josh Green]

On Thu, 2003-12-04 at 01:20, Joerg Anders wrote:
> On Wed, 3 Dec 2003, Josh Green wrote:
> 
> > Can you explain in words what the problems ...
> 
> ... not in words but in sounds (see below)
> 

Right, but from what I heard there were examples of 2 seemingly
different problems.
1. Sharp surging attack which then decays to a lower sustained volume.
2. Too quiet



> ... 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.
> 

I'm not saying there isn't a problem. It definitely sounds like there is
one, I was just commenting on how I don't know what would cause this.

> > 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
> 

Uhhhhhhhhhh... Come on now. I think you mis-understood me there. I was
referring to envelope "attenuation" which is a particular parameter in
the volume envelope. This parameter I believe is currently implemented
in regards to the SoundFont specification with FluidSynth. It often is
the cause of instruments playing too quiet. I don't think this is the
same problem as the attack surge though.

> 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.

Ahhh ha!! I hadn't really looked at your patch previously. It appears
this problem is related to MIDI note to volume envelope hold and decay.
These 2 parameters allow for variance of the volume envelope hold and
decay stages based on the MIDI note # being played. You are right, this
parameter is not used that much, in fact I never bothered to really even
get this working in Swami (although it might work). I'll add this to the
TODO list. Thanks again for your report and testing. Cheers.
        Josh Green