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

[S. Christian Collins]

Hello Everyone,

One thing I meant to say in my first e-mail--I am willing to make test
SoundFonts and to examine existing SoundFonts in any way that can help
the FluidSynth team.

If anyone needs help troubleshooting the default vel->fc curve, I have
created a SoundFont 2.1 bank with the following instruments. All
changes are made at the instrument level:

* default - default vel->fc modulators
* no_vel-t-fc - vel->fc modulator removed entirely
* custom_vel-to-fc - secondary source (switch) removed from vel->fc
modulator, creating custom modulator

The instruments beginning with GZ are the same thing, but with the
modifications made to the global zone rather than the individual sample.

I figure that making this bank may not have been necessary to fix the
problem, but I thought it might be helpful for troubleshooting
purposes. To hear the difference, test the bank on a SoundFont
2.1-compatible sound card (such as Audigy series in Windows), and
compare the results with FluidSynth. I can make audio examples if
needed, especially if anybody making changes doesn't have access to an
Audigy series sound card running under Windows.

Here's the link to the test SoundFont:
http://www.schristiancollins.com/temp/vel-to-fc_default_modulator_test.SF2

Please let me know if you need more info.
Thanks,
-~Chris



Josh Green wrote:
> 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
>>
>
>
>
>

---

Need to know the score, the latest news, or you need your Hotmail®-get your "fix". Check it out.