Hi Chris,
I think it's great that a SoundFont designer is looking to use fluidsynth
and perhaps related technologies ;-) (such as a fluidsynth fork I'm
writing). Yours will be a very interesting perspective to have in this
list.
I have a couple of questions for you:
1. How are you currently using fluidsynth? (from the command line,
probably?).
2. What are you using it for? (perhaps synthesizing MIDI files into
raw audio?).
Regards,
Miguel
On Jan 20, 2008 7:03 PM, S. Christian Collins <[EMAIL PROTECTED]>
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(R)-get
> your "fix". Check it out. <http://www.msnmobilefix.com/Default.aspx>
>
> _______________________________________________
> fluid-dev mailing list
> [email protected]
> http://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
