Issue with percussion in multiport MIDI's

[pqyt]

Hi,

first time poster. Please be kind.

I've stumbled on a problem with following combination of factors:

- BASS 2.4.17.0
- BASS MIDI 2.4.15.3
- RIFF RMI file played using BASS_MIDI_StreamCreateFile().
- The RMI file has an embedded SF2 sound font, 31 tracks, 29 channels and 4 ports.
- The percussion is played on channel 10 with port 0, 1, 2 and 3.

The issue:

- The first note on channel 10 and port 0 uses the correct preset but the next notes are all played with what sounds like a tom drum.
- The drum patterns on channel 10 of port 1 through 3 play using the correct presets.

The RMI file is too big to attach to the post (https://limewire.com/d/528f80dc-4e42-4b47-854d-4223c23f0d5d#cx_2VdcZULwLlfhxDuoFAMVXAFgR1kLmVkCJ5ZDZ9zs) Expires in 7 days.

The external sound font does not matter. To hear the expected result you can use https://spessasus.github.io/SpessaSynth/.

Can anyone confirm the issue and hopefully provide a fix?

[Falcosoft]

I do not know what software you use to insert port preference meta events but it seems the software has a tendency to insert port preference events after other events at the same tick.
The semantics of port preference events on tracks is not exactly defined but seemingly nothing prevents port preferences to change during playback.
Because of this BassMidi most likely only applies the selected port AFTER it finds the port preference event and handles events before the port preference event on the given track as targeted to default port (port 0).
This can explain your problem since track 19 sends the program change 48 (GS Orchestra Kit) event before the port preference 1 event.
This way Bassmidi can rightfully think that program change 48 (GS Orchestra Kit) is trageted at port 0 instead of port 1.
It seems the intended bevavior of the Midi file is to use program 0 (GS Standard kit) on port 0 (the file sets this on track 18) but because of the misplaced port preference 1 event on track 19 the program change 48 (GS Orchestra Kit) overrides this.

So to prevent problems and avoid ambiguous situations the best practice would be to insert port preference meta events BEFORE any channel events on the same track.

This way your Midi file would work with all software that support both multi-port Midi files and embedded SF2 (SpessaSynth, my Falcosoft Soundfont Midi Player and native BASS_MIDI_StreamCreateFile) the same way.



 

[pqyt]

Thx. for your reply.

I'm not the author of the file. Spessasus provided it to me because my foobar2000 plugin https://github.com/stuerp/foo_midi did not handle it correctly. I've been hunting for that bug for quite some time but only recently decided to write a small BASS MIDI test program.

Your answer makes sense. I can move the port selection events in my plugin wherever I want but maybe @Ian can shed some light on how BASS_MIDI_StreamCreateFile() handles it.

[Ian @ un4seen]

I can confirm that a port change only applies to events that come after it in the same track, and the port can be changed multiple times in a track if wanted.

[Falcosoft]

I can confirm that a port change only applies to events that come after it in the same track, and the port can be changed multiple times in a track if wanted.

Hi Ian,
There is a discussion about this problem at the Gihub repo of Foo_Midi:
https://github.com/stuerp/foo_midi/issues/77#issuecomment-2717401791

The conclusion from Spessaus:

If the MIDI track has MIDI port events, the first port applies to starting from the first event, even if the port event is not the first one. This is a behavior that seems to fix most of musescore's MIDI files.