Re: [fluid-dev] Velocity to Initial FC default setting

[Josh Green]

Hello Chris,

Thank you for your interest in FluidSynth.  I'm also excited about
future prospects of it and also of project Swami, which uses it as its
synthesizer backend.

Indeed it is quite absurd that the default behavior is to have a
velocity to filter cutoff modulator.  I notice that this has changed
between 2.01 and 2.04 of the SoundFont specification also, which adds to
the confusion.  With both specifications though, it mentions that the
provision that it is only active on volume envelope attacks less than
7ms, is no longer a requirement, but may be adhered to to make a
synthesizer more AWE32 compatible.  It also looks like the secondary
switch (amount source) component of this default modulator has been
removed in the 2.04 spec, which seems a little more sane to me.  Except
for the fact that now I don't see what modulator should be used to
disable this idiotic functionality.  In particular a modulator is
considered identical when all the criteria (source, amount source,
destination and transform) are identical.  So it seems somewhat
impossible to know whether the synthesizer being used uses the 2.01 or
2.04 format of this modulator.  FluidSynth currently uses the 2.01
method (with the switch as the amount source).  I think the easiest way
to disable this is to define the modulator at the global instrument zone
for every instrument.  But as FluidSynth is now, it requires that this
modulator also includes the switch as the secondary source.  This seems
somewhat wrong to me.  Any ideas on how other SoundFont software handles
this?  Perhaps if any modulator is seen with a amount of 0 with velocity
and filter cutoff, it should just assume that the SoundFont is trying to
disable this default modulator.

As for your SoundFont files.  Excellent work!  I'm really impressed by
them.  I was looking recently for a GS compatible SoundFont bank, for
testing with GS MIDI files, and it looks like that is what you have
created.  They sound really good too!  I tested both in the current
development release of Swami and they both worked fine.  It does indeed
look like the Piano SoundFont crashes on FluidSynth stand alone though
(Swami does its own instrument/voice processing).  In particular it
seems its crashing on some of the preset modulator code during note on,
I'll have a look at this later today.

By the way, perhaps you might be interested in hosting your SoundFont
files on http://sounds.resonance.org ?  Its been somewhat dormant, since
I was trying to get the CRAM compression standard finalized, which has
been taking longer than I would have liked.  An alternative would be to
just use some other default compression scheme (like bz2, although CRAM
often beats it pretty nicely) and just announce the web site as is.
Bandwidth is unfortunately somewhat limited on that server too at the
moment, but there is one mirror that has a bit more for the actual
instrument files themselves.

Cheers!
        Josh


On Sun, 2008-01-20 at 13:03 -0600, S. Christian Collins wrote:
> Greetings, fluid-dev group!
> 
> I am new here, but I wanted to contribute in any way I can. Sorry,
> I'm 
> not a programmer, but I am a long-time SoundFont designer and I have 
> been exploring FluidSynth lately as part of my foray into Linux. I 
> believe that FluidSynth is a project of much greater importance than 
> many realize, especially as Creative seems to be dropping the ball
> with 
> their SoundFont support (I won't go into the mess that poses as their 
> drivers). A good, solid SoundFont synth on Linux will also go a long 
> way to encourage musicians to dump Windows and use Linux as their
> music 
> studio of choice, especially now that major projects such as Ardour
> are 
> now adding MIDI support.
> 
> I will discuss the "velocity to filter cutoff" modulator, henceforth 
> referred to as "vel->fc".
> In the SoundFont 2.0 spec, you could not modify the default
> modulators, 
> and the behavior of vel->fc was as follows:
> 
> 1. Setting the volume ADSR attack to 0.008 seconds or higher would
> automatically apply a filter curve so that lower velocities were
> more filtered, with velo=127 being fully unfiltered. This is most
> noticeable when the initial filter cutoff is set to a lower value.
> 2. Setting the volume ADSR attack to 0.006 or higher would not have
> the filter curve applied.
> 
> For a sound designer, this is annoying--if you wanted a fixed filter 
> cutoff point with a slow volume attack, then you had to do a hack
> using 
> the mod env->fc that I won't go into.
> 
> When SoundFont 2.1 came out, designers could now control the
> modulators 
> affecting how MIDI events were translated for each patch, including
> how 
> the filter was affected by velocity, key, etc. This was a wonderful 
> development, but Creative's default vel->fc implementation left me 
> scratching my head. The default vel->fc was implemented using:
> 
> 1. primary modulator = negative concave curve @ -2400
> 2. secondary modulator = switch @ -2400
> 
> Two questions bothered me. First, why should velocity mess with the 
> filter unless the SoundFont author expressly specifies such behavior, 
> and second, why would anyone want a velocity switch as the default 
> behavior? The switch effectively switches to a tighter filter at 
> velocity 63 or lower, leaving a jagged bump in the velocity scale. In 
> all my years of designing SoundFonts, I have never once desired this 
> behavior.
> 
> My solution has been to delete the velo->fc modulator from each patch 
> that I create (I delete it from the instrument level), and create my
> own 
> velo->fc modulator if I need it. However, FluidSynth doesn't seem to 
> notice that I have deleted the velo->fc modulator and still
> implements 
> it, making most of my SoundFonts sound like mush.
> 
> I have been able to circumvent the default velo->fc implementation in 
> FluidSynth by modifying the fluid_mod.c file as follows (section: 
> 'special treatment' for default controller):
> 
> * replace this:
> if ((mod->src2 == FLUID_MOD_VELOCITY) &&
> (mod->src1 == FLUID_MOD_VELOCITY) &&
> (mod->flags1 == (FLUID_MOD_GC | FLUID_MOD_UNIPOLAR
> | FLUID_MOD_NEGATIVE | FLUID_MOD_LINEAR)) &&
> (mod->flags2 == (FLUID_MOD_GC | FLUID_MOD_UNIPOLAR
> | FLUID_MOD_POSITIVE | FLUID_MOD_SWITCH)) &&
> (mod->dest == GEN_FILTERFC)) {
> if (voice->vel < 64){
> return (fluid_real_t) mod->amount / 2.0;
> } else {
> return (fluid_real_t) mod->amount * (127 - voice->vel) / 127;
> }
> }
> 
> * with this:
> if ((mod->src2 == FLUID_MOD_VELOCITY) &&
> (mod->src1 == FLUID_MOD_VELOCITY) &&
> (mod->flags1 == (FLUID_MOD_GC | FLUID_MOD_UNIPOLAR
> | FLUID_MOD_NEGATIVE | FLUID_MOD_LINEAR)) &&
> (mod->flags2 == (FLUID_MOD_GC | FLUID_MOD_UNIPOLAR
> | FLUID_MOD_POSITIVE | FLUID_MOD_SWITCH)) &&
> (mod->dest == GEN_FILTERFC)) {
> return 0;
> }
> 
> This is obviously an inelegant hack. However, the vel-fc programming
> in 
> my SoundFonts sounds as it should. You can test the SoundFont file
> for 
> yourself to see the differences:
> 
> http://www.schristiancollins.com/temp/GeneralUser%20GS%20FluidSynth%
> 20v1.41.sf2.bz2
> 
> It is my intent to design SoundFonts specifically for FluidSynth in
> the 
> future. I believe that this behavior should be modified for future 
> versions of FluidSynth? It will help many more SoundFonts than just
> mine.
> 
> Thanks,
> -~Chris
> 
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> Need to know the score, the latest news, or you need your Hotmail®-get
> your "fix". Check it out.
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fluid-dev