I'm having a problem with drum tracks not changing when the program changes.
For example, if the drum track is set to program 48 for orchestral, it's
still using standard. No matter what program I use, it just will not change.
It is not working with any soundfonts, not even the default. It does not
work from the gui interface, or when used with a sequencer.
Is there a way to fix this?
From: Eric Welsh <ewelsh@bi...> - 2010-02-06 06:40:35
On Sat, 6 Feb 2010, Raymond Grote wrote:
> I'm having a problem with drum tracks not changing when the program changes.
> For example, if the drum track is set to program 48 for orchestral, it's
> still using standard. No matter what program I use, it just will not change.
> It is not working with any soundfonts, not even the default. It does not
> work from the gui interface, or when used with a sequencer.
> Is there a way to fix this?
Do the soundfonts have instruments defined for drumset 48? Otherwise, if
there are no instruments defined for drumset 48, it will default to
drumset 0 instruments. The same goes for PAT files, there would need to
be a section in gravis.cfg or whichever config file you are using that
defines drumset 48 and which instruments are associated with which
If the soundfonts/patches do define drumset 48, does your midi use GS or
XG SYSEX events to change drumsets? If it does, and if the midi also
neglects to issue a GS or XG SYSEX reset event at the beginning of the
midi to set the synth into GS or XG mode, timidity will correctly ignore
all GS or XG events, since it will not have been set into GS or XG mode.
I have encountered quite a few midi files that don't issue the reset
event, which will cause the drumsets to not change if SYSEX events are
being used to change them.
If timidity is being used in server mode, rather than stand alone file
playing, it will not be able to correctly parse non-standard reset events.
I have several XG midi where a non-standard reset event is used that uses
a different device ID than the documented XG reset event. The file player
code has some workarounds for this, but they evidently never made it into
the server code (or at least not the one I'm using in Windows as a midi
driver). I have only seen this problem on a few XG midi, though.
If someone could give me some pointers on how to get timidity to compile a
driver under Windows, I will happily set about debugging the non-standard
XG reset event problem in server mode. As it is now, I'm only able to
build the standard player with cygwin+mingw32.