[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: jimmy
Subject: Re: [fluid-dev] invalid instrument/drum selection
Date: Thu, 29 Jan 2009 01:06:50 -0800 (PST)

> Hi Jimmy,
> Just keeping the already selected instrument when an
> invalid selection
> is received seems strange to me.  Do you think that would
> create the
> desired effect in most MIDI files?  It is a case of the
> MIDI file
> expecting an instrument to be present, which is not, right?
>  I'm not
> convinced that just keeping the previous instrument
> selection is any
> better than trying to be a little smarter about it,
> depending on the
> mode (GM, GS, XG, etc).  If a SoundFont was loaded, which
> supported all
> the instruments of the playing MIDI file, then there would
> be no issue.
> Best regards,
>       Josh

Hi Josh,

Sure, you decide what's best to implement, when you have a chance that is.  I 
only wish that assume that when I load up several soundfonts, with at least one 
complete GM soundfont, in any order, that FS won't skip out on any XG sound 
selection -- like prog_change channel 5 bank 15231 prog_numb 43.

Since GM only assure bank 0 is available and complete.  Softsynths, and 
soundcards also allow multiple soundfonts to be loaded to override some 
instruments using bank_number and prog_numbers base on some soundfont loading 
order.  Some of those soundfonts may not have complete set of GM instruments.

>From what I know of XG, and XG keyboards, those may have sound banks and drum 
>kits that you and I don't have.  Basically, they are hardware sound modules.

Soundcards with midi, and/or XG supports are PC emulation of those hardware 
sound modules.  FS is just software emulation of such.  And I haven't seen a 
hardware sound module skips any midi sound channels the way FS does.  I have 
played XG sequences onto a Casio keyboard, non-XG of course, and they do sound 
something, not exactly as it may sound on a Yamaha XG keyboard, but it won't 
skip out on any sound at all, probably just use corresponding prog_number of 
the complete GM soundbank it has.  Similar result with a PCI SB 5.1 Live! 
soundcard if I have a GM soundfont loaded -- I haven't tried with just a non-GM 
single-instrument soundfont.

I am fairly certain that most XG sound modules (including electronic keyboards) 
have soundbank 0 that has a complete GM set of instruments.  All other 
soundbanks (non-0) may be virtual pointer to instruments in soundband 0 with 
some or all instruments tweaked with different effects -- similar to 
synthesizer keyboards that allow custom sound editing.  I guess that's the 
case, because many older XG keyboard specs I have seen showed only a few 
megabytes of sound samples.  Even Tyros, Tyros 2, and Tyros 3 (top of the line 
arranger keyboards of its time) have only a few dozen megabytes of sound 

Many of those XG arranger keyboards were implemented on a few "sound engines".  
Even with the same "sound engine" (hardware soundchip, number of effect 
processors, sound samples), I believe those XG keyboards have different number 
of soundbanks and different soundbank numbering schemes (but same GM 
prog_numbering) over the years.

The only fairly certain thing I know about them is that people can record midi 
sequences from those keyboards, or copy style files for those keyboards.  When 
playing back those midi sequences, or styles on a different XG keyboard models 
they will sound differently, even badly, because of different sound engines and 
soundbank numbering schemes, but I don't think any of the sounds are skipped, 
or ignored.

Again, I can't recall where I read it, but I believe that the XG prog_number 
mirrors GM scheme in most cases.  If you insist, I can try to locate that info. 
 Just that XG uses many more sound banks, and the more expensive the hardware, 
the better sound sammples and sound engine they have.  I think XG, and XG-Lite 
are examples of pricing the market.

Best regards,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]