|
From: | S. Christian Collins |
Subject: | Re: [fluid-dev] Velocity to Initial FC default setting |
Date: | Mon, 21 Jan 2008 11:35:56 -0600 |
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. |
[Prev in Thread] | Current Thread | [Next in Thread] |