Re: [fluid-dev] invalid instrument/drum selection problem

[Josh Green]

Hello Jimmy,

On Mon, 2008-01-07 at 10:20 -0800, jimmy wrote:
> Hi Josh,
> 
> I'm sure the different specs for GM, GS, XG, XG-lite
> basically made up their own "specific scenarios". 
> From what I see, each channel is like a patch cord
> into a mixer, if the Cello-ist broke a string, it may
> not be ideal but a Timpani-ist or a Guitar-ist from
> the openning band wouldn't mind jumping in as a
> replacement if they can play along,
> 
> The thing is I and possibly most other folks don't
> know and prefer not to know which MIDI files are GM,
> which are GS, which are XG.  Especially, I don't want
> ot have to convert those files, or restart the player
> with different options for different MIDI files.  I'd
> rather have the player plays through a pre-exisitng,
> or an impromptu playlist.
> 
> I'd like the player to handle it reasonably (best that
> it can).  Plus, I don't want to sit down to listen to
> a few random MIDI files and it sounded like the
> drummer and a few other musician walked off the stage
> on a live show -- if you know what I mean.  I also
> don't want to hear the "Grand Pianno Quintet" either
> :-)
> 

Agreed.  It should just work :)  I was just reading that that was
actually part of the GM standard.  When a GM enable Sysex message is
received, its supposed to map all channels to Grand Piano.  Its up to
the MIDI file to switch to other programs at that point.  As for
substituting for GS, its just a matter of using the same program number
but bank 0 (if the instrument isn't found).  I'm not sure what sort of
logic beyond that should be used to substitute an instrument, although
it may indeed be different for XG MIDI files.


> As for instrument mapping from GS, or XG to GM, we
> could try, but it is going to be pretty involved.  I'm
> not sure if continually looking up several different
> tables for each channel is going to affect real-time
> performance, but that's something I will try to
> remember with code changes.
> 

As I mentioned, GS is supposed to be relatively backwards compatible, in
that instruments with the same program number, but in different banks,
are somewhat of a group.  They are similar.  So substituting bank 0
should be fine.  I'd like to look more at the XG standard to figure out
what that mapping is.  How many MIDI files really use XG is another
question though.  I don't think it makes sense to go out of the way to
try and be smart and map completely different standards to GM, with
tables and what not.  The computation would be minimal, but it just
complicates things and too much "smartness" can be a bad thing.  It
would be nice to get statistics on what MIDI standards are used by the
body of public MIDI files out there and do what needs to be done to get
them to just work.

> By the way, the midi file I mentioned from the my
> first email:
> 
>   
> www.geocities.com/TheTropics/Cabana/4967/caballo.mid
> 
> cause several channels to go away in verstion 1.0.7,
> and 1.0.8.  It seems to play somewhat reasonable with
> my patch, fwiw.  If I run into other troublesome
> suspects and need to ask for help handling them,
> people on this list will probably hear from me again. 
> It is definitely not a threat ;-)
> 
> Lot's of rambling from me, not sure any of it helps
> ;-)  Take care,
> 

It definitely does help.  There are a number of things that need to be
improved with FluidSynth.  I rarely use FluidSynth to play MIDI files,
although it is my plan to use it for that purpose in the future, for
faster than real-time rendering of my own pieces and self made SoundFont
files to audio files.  So a lot of these issues haven't really been
identified.

What audio driver are you using for FluidSynth?  As has been brought up
on the mailing list before, and what I just got bit by, was the fact
that certain audio drivers don't work properly with very short note
on/off durations, which are sometimes used for percussion.  Basically
the note will just not sound at all.  I've found that Jack works fine,
but ALSA and likely OSS probably don't.  This also needs to be fixed,
but will likely require a bit of work.

> Jimmy
> 

Best regards,
        Josh