Re: [timidity-talk] PROPER soundfont loading.

[Eric W. <ew...@bi...>]

On Tue, 23 Feb 2010, Chuck Cochems wrote:

> Current method is absolutely horrible. It ONLY seems to load bank 0 from
> the soundfont, and ignore all others, at least in the standalone player
> I tried.

I'll agree that TiMidity has issues with sf2 instrument loading....  But,
given the history of the program, I don't think it is too horrible.
TiMidity started out around 1995 or so using GUS .pat files from the
Gravis Ultrasound.  The GUS used a gravis.cfg file to map individual
instrument files to each midi instrument number.  There were no "banks"
that you could just swap in and out, it was all specified in gory detail
in the gravis.cfg file.  TiMidity worked the same way, since the GUS was
the standard consumer grade midi card at the time.  SF2 support was added
much later on top of the PAT support.  I look at TiMidity more as a GUS
.pat file player that includes some SF2 support.

Although just specifying "soundfont whatevername.sf2" in a .cfg file
doesn't seem to handle the non-0 banks properly, it *IS* possible to get
TiMidity to use all the drumsets and SFX banks correctly.  It's just
painful the way I have done it on my system.  I don't know if there is a
better way or not, I've always just used .pat files, I didn't really get
into SF2 until I started merging FreePats with FluidR3 over the weekend
via config files.  You can use sf2 files in the gravis.cfg and various
other .cfg files similar to how you would use .pat files.  You can specify
each individual bank and each individual instrument within each bank, like
the following:

# loads instruments 49-51 from sf2 bank 0 into timidity bank 0
bank 0

49 %font "FluidR3_GM.sf2" 0 49         # String Ensemble 2 Slow
50 %font "FluidR3_GM.sf2" 0 50         # Synth Strings 1
51 %font "FluidR3_GM.sf2" 0 51         # Synth Strings 2

# loads drums 29-30 from sf2 bank drumset 0 into timidity drumset 0
# drumset loading from sf2 files is denoted with an extra 128 before the
#  bank/instrument
drumset 0

028 %font "FluidR3_GM.sf2" 128 0 28     pan=-21 # Slap
029 %font "FluidR3_GM.sf2" 128 0 29     pan=-19 # Scratch 1 push
030 %font "FluidR3_GM.sf2" 128 0 30     pan=-19 # Scratch 2 pull

You can define other banks and drumsets as well, like GS drumsets 8, 16,
24, 25, 26, 32, 40, 48, 49, 50, etc..  You can define GS SFX drumsets 56
and 127 too.  Proper XG bank support is much more complicated, but is also
possible to configure given the right .cfg file syntax.

Yes, it's a lot of work to specify a line for every single bank and
instrument (however, extra banks only need instruments that differ from
bank 0, they will automatically fall back to bank 0 if missing).  But, if
they are already in a single sf2 file, it's really easy to just copy/paste
a bunch of lines then go down the list and change the instrument numbers
one at a time to specify each instrument separately.  It's a little
tedious... but doable.

Once you have a .cfg file for the bank you want, you can then edit your
timidity.cfg file to source that .cfg file, or a different one if you want
to use a different instrument configuration.  This would sort of work as a
"bank change".

I agree that the SF2 support isn't so great....  SF2 bank loading should
be fixed to handle non-0 banks more easily, so that all it takes is a
single "soundfont" line to correctly load the entire set of banks.
Loading behavior also needs to be fixed so that instruments loaded later
properly overwrite instruments loaded earlier (including PAT files).  I
think most of the problems stem from the behavior of the "soundfont"
directive.  SF2 loading seems to behave as expected when used on a
per-instrument basis with the %font directive.  I suspect the code that
handles the soundfont directive might be the first place to look to see
where the problems might be?  Thank you for bringing this problem to the
developers' attention.

> Also the engine should support all awe32 sysex and NRPN Mainly tis means
> GS sysex for reverb and chorus, and nrpn to control the LFOs and the
> resonant filter.

TiMidity actually DOES support most of the GS and XG SYSEX events,
including chorus and reverb levels on a per-channel basis.  The chorus and
reverb might not sound as good as you'd like, but the support IS there,
it's just the chorus and reverb engines that need some work.  You may have
to enable chorus and reverb support in the preferences, I'm not sure if
they default to ON or not.

Special audio effects, such as reverb, chorus, variation, etc. are
probably the most difficult thing to add to a midi player.  Once the
special effects engines are written, adding the support for the SYSEX
events is easy.  Since special effects are hard to implement, it just
hasn't happened, or if it has, the quality may not be as good as what
you've come to expect from commercial solutions.  Hey, it's free software
written by people in their free time as a hobby, don't be surprised if it
doesn't have all the features of a Roland or Yamaha sound module....

I don't think TiMidity has any linear frequency oscillators at all.
Nor do most other softsynths, or even consumer level hardware for that
matter.  Since pretty much nothing else currently supports this either, I
don't see much of a problem with it being missing....

> You want to play some final fantasy 7 awe midi files. :)

I used to have a Yamaha SW60XG ISA card.  It was awesome.  I bought FF7
for PC and didn't need the included Yamaha S-YXG50 softsynth (for
Win95/98/ME), since I already had the real hardware that was better.  FF7
sounded great.  GS and XG midi sounded great.  I added XG support to
TiMidity and it sounded ... not too bad once all the instrument changing
SYSEX events were supported and configured.  I can confidently say that,
apart from special audio effects such as LFO and Variation, TiMidity does
a good job of supporting GS and XG instruments and instrument changing
SYSEX events, enough to play back midi that sound reasonable, as opposed
to playing with all the wrong instruments due to missing the SYSEX
instrument and drumset change events.  TiMidity sounds WAY better than my
Audigy ever did, since it didn't support GS or XG at all (at least not
that I could tell).  It couldn't even handle 2 drum channels, much less
SFX drum channels.  TiMidity's support is still more GS and XG support
than almost every other solution out there.

If you want near-perfect GS and XG support, your best bet it to aquire an
old copy of Yamaha's S-YXG50 softsynth if you are running XP.  The latest
version you could get from Yamaha was 4.23.14, which was a WDM driver that
was supposed to work under XP (but I could never get it to work).  If you
are running XP, you can download the Microsoft Windows Update 1403848.cab,
which includes an even newer version, WITH the 4 meg ROM instead of the
standard 2 meg ROM.  Extract the CAB file with WinZip or something like
that, then Add New Hardware the driver.  Since it doesn't have an
installer to create the registry entries, you'll need to add them yourself
if you didn't install 4.23.14 from Yamaha beforehand (and use Update
Driver under Device Manager).  See the following link for details:

   http://www.wiki-mirror.us/wiki/Software_synthesizer

It even works as an MPU-401 device under DosBox, so that great DOS midi
players such as MegaMid v1.66 work perfectly :)  Lucas Arts adventure
games also sound very nice with it using ScummVM.

I am currently running it, and I can say that it sounds almost as good as
my SW60XG did on all my XG midi.  It has a few issues with the volume
being set too high internally so that it over-amplifies outside the 16-bit
sample range and pops/crackles every now and then with really
effects-loaded midi, but overall it sounds pretty good.  WAY WAY better
than the default Microsoft GS softsynth.

If you are running Vista, there really isn't much in the way of software
GS or XG support.  Yamaha is currently selling software called MidRadio,
but only in Japanese, and apparently only as a file player.  It uses a
crippled softsynth that only supports XG-Lite (no variation effects), but
has a larger (11 meg) instrument bank than the S-YXG50 (4 meg, same as the
SW60XG).  There is a hack to turn the demo version into a VSTi plugin that
you can be used with midi software that supports VSTi plugins, something
even the full commercial version can't do.  I found some full instructions
over the weekend for how to do that, but I can't find the link at the
moment.  I'm running XP, so the S-YXG50 is good enough for me for now,
especially since it works as a full blown Windows MIDI driver.

> Notably no card that uses .sf2 seems to support portmenteau controller,
> even though GS and XG standard both require it's support.

If it isn't made by Roland or Yamaha, it probably doesn't have much of any
GS or XG support at all :(  I can't blame Creative or other consumer sound
card makers, there just isn't much demand for it.  I *can* however blame
Roland and Yamaha.  Damn them for discontinuing their consumer-level
product lines *AND* their Windows software synthesizers.

> If you wish to make a GS compliant timdity++, you must include this
> controller.

In theory, it should be possible to implement it in TiMidity, especially
since it already implements portamento in MOD files.  But the MOD engine
is completely separate and just emits a series of internal pitch bend
events to create the portamento effect, which is a bit of a hack.  I think
the best solution would be to implement something similar to how
instrument envelopes are currently implemented.  Add a voice variable that
detunes the pitch by X amount.  Add a separate variable that tells it how
much to increment the first variable per time slice.  Add a third variable
that tells it at which point to stop (once the detune value has been
reached).  When a portamento event is issued, calculate the increment rate
and endpoint for the detuning, then pass the modified detuned frequency to
the resampling functions that are already used to change sample pitch.
Three new variables to add to the voice data structure, a new function to
write to calculate/set them on a portamento event, some extra code to
write to increment the detuning value each timeslice.  Cached
pre-resampled notes would also need to be disabled for notes affected by a
portamento.  I think I mostly know which functions and data structure
would need to be edited.  This sounds quite doable to me.  But, I don't
have time for it at the moment, and I don't know about other developers.
Thank you for bringing this to our attention, though.  I wasn't aware that
there was much need or demand for portamento support.  I'd never seen it
used in a midi file before.

-Eric