Some GS instruments aren't playing (wrong banks)

[sneakernets]

Today I was playing that Christmas Song midi that I had made some recordings of, it has an instrument choice on Bank 16 Instrument 24, called "Nylon Gt.o". Unfortunately, libADLMIDI sees it at bank 4096?

Is this the midi file or what? It's in SMF0/GS format.

[sneakernets]

Here are the MIDI commands to set up that instrument on Channel 4:

[Wohlstand]

Did you confused MSB or LSB bank codes? I mean in the bank. If something missmatching to standard, Ill fix that in bank editors.

[sneakernets]

Hmm, I picked this configuration:

Is this correct? do I need to add something to MSB for this? 🤔

[sneakernets]

O---ohhh wait I think I know now. I know with GM2, I need to set MSB to "121" and then the LSB to whatever I need. Is that what I'm missing here? I tried that just now and adlmidi still didn't see my guitar...

[Wohlstand]

Bank numbers are parsing by libADLMIDI as unsigned integers, and I think you need to use the calculator to get the binary view of msb/lsb and then convert into decimal. Anyway, I think to solve this inconvenience to give right data format into bank numbers are shown in bank editor's ui to let setup right bank number that will be catched correctly by libADLMIDI's internal. Maybe Ill also provide a test MIDI files for each instrument? I already have a set of test MIDI files for GM set.

[Wohlstand]

Try to use bank ID cointing from 0... Instead of from 1... . I had experimenting with TR-808 on libOPNMIDI and I had found that bank ID is different with -1 from standard.

[freq-mod]

Try to use bank ID cointing from 0... Instead of from 1... . I had experimenting with TR-808 on linOPNMIDI and I had found that bank ID is different with -1 from standard.

-1? What's on scr below works fine for me

[Wohlstand]

Yeah, I meant when bank ID is 26, the 25 must be set as bank ID in the editor. As data are shown as-is as internally in MIDI files. Editors usually adding +1 to bank ID which causes a difference in raw and human views.

[sneakernets]

Ah then we're good!
Anyway here's a release: https://github.com/sneakernets/DMXOPL/releases/tag/v2.11e

[freq-mod]

(somewhat related to sneakernets/DMXOPL#38)
What about cases like that:

Do I need some specific MSB/LSB values to deal with such crap?

[Wohlstand]

I think, I need to look into MIDI file itself, is it valid GS or for something other? For case of GS, MSB is a main bank number when LSB is ignored by GS. Usually if it is 0, then everything must be fine. IF it's GS, but dirty file where are both MSB and LSB used and there are not maching GS bank numbers, that makes misses in full-ranges. As I told before, I must to implement SysEx support to catch GS-Reset event to change the bank number formula. I.e. all LSB values in GS must be zeroed to let foruma be correct.

[freq-mod]

OK, grab .mid then
bls_11t.zip

[Wohlstand]

It seems not a GS:

And I see two bank events:

And yeah, 8*256 + 2 == 2050
And second case:

and:

So, 16*256 + 2 == 4098

The only question what F0 41 10 42 12 00 00 7F 00 01 F7 SysEx event wants to do, in Sonar it was called as "System mode set".

Maybe it's a GS, but looks very weird... Usually GS-targeted MIDI files are having "GS-Reset" SysEx command.

[freq-mod]

It's most likely a SC-88Pro/SC-8850 midi file.

[Wohlstand]

As now SysEx events are implemented, I'm now able to catch "GS Reset" related calls to change behavior of bank changing, so, when GS mode is turned on, LSB part is ignoring, and only MSB is in use. Please test this by yourself.

[freq-mod]

For me it looks and sounds OK so far.

[Wohlstand]

I'll close this as issue has been solved.