Spesek wrote on 2024-08-02, 20:53:

Thanks for your detailed response Zoltan. I would like to address it here. About the bank offsets: What about midi with embedde […]
Show full quote

Thanks for your detailed response Zoltan.
I would like to address it here.
About the bank offsets:
What about midi with embedded preset at bank 1?
My program currently produces .rmi files with bank offset of 1 (as the soundfont is embedded) and for example when the midi wants preset 1:80 (square), it makes it 2:80.
This seems to work with your program as well. I've uploaded 2 RMIs here: https://filetransfer.io/data-package/r0Y31KbQ#link

About sfogg:
It sounds very similar to The SoundFont3 Format which spessasynth supports (and so does FSMP6, since the RMIs I uploaded use ogg vorbis and it can read them no problem)
But trying to load sfogg with spessasynth causes the samples to sound like whitenoise, meaning incorrect offsets. So I'll try to reach out to Ian as you suggested.

About mod2midi:
It's a super cool piece of software! Though, it seems to be a bit incorrect with the samples and pitch bends.
Try unreeal superhero 3 and compare it with OpenMPT or VLC. it sounds a little off. It would be great if you could fix it, but if it's not your priority, I completely understand.

About your second post:
Yes, spessasynth currently doesn't support mixing soundfonts, although I've added an unpolished version of it that's hidden away. But adding a sort of "override soundfont" sounds simple enough, thanks for the suggestion!

PS:
The RMIDIs with embedded SF2 are super cool IMO. They could fix the biggest problem of MIDI: different sounds across different devices.
Also exporting them with the Sf3 format (Ogg vorbis compression) and trimmed samples like my program does, the is smaller to something like a wave file of the same length!
Maybe if we could get the big players like VLC and fluidsynth to support them, they could become mainstream. What do you think?

Thanks again for your response,
spessasus

Hi,
1. Yes, in this case all banks should be calculated with a +1 offset. So bank 1 becomes bank 2, bank 2 becomes bank 3, and bank 127 becomes 128 (a Drum bank!!!).
So this way you can also make melodic presets available at Drum channels. E.g. with a bank offset of 127 all banks of the soundfont from bank 1 are associated to drum channels.
Actually this is the way the Soundfont Bank Manager (sfman32) of hardware SF2 synths from Creative Labs always worked. Bassmidi also follows this logic.
So overall the logic behind the bank 1 as default is due to Creative demo files that most likely reflected the constrains of original SB hardware (bank 0 was in ROM and cannot be changed with regular sfman32 functions). Because of this Creative's demo files most of the time also presuppose a full GM bank at bank 0.
Modern software based SF2 synths have no such restriction and according to my experience so far most users expect custom soundfonts to be loaded to bank 0 by default. That's why there is an option for it in MidiPlayer.
But most likely the best solution would be a new field inside the outer info block (e.g. 'DBNK') of the rmidi file where you could define the destination bank/bank offset explicitly. If this field did not exist the bahaviour would be the current one (bank 1 by default but could be changed by the sofware) otherwise the explicitly defined value would be the destination bank.

2. Yes, you should definitely ask Ian. He is very helpful. He regularly answers even the most technical questions about Bass related stuff on the forum at un4seen.com.

3. I cannot promise anything regarding mod2midi 😀. BTW, Have you tried the latest version 6.4 of FSMP packaged with mod2midi v1.2.3? It fixed some pitch bend related errors. I hear no obvious problems with unreeeal_superhero_3.xm on latest version.

4. I'm not particularly good at convincing anyone about anything, but I could try to convince Ian about supporting rmidi files with embedded SF2 in Bassmidi.
I have absolutely no contacts to other projects like VLC and FluidSynth. So this would be your job 😀

i can confirm for manually loaded user banks. if you load a user bank into bank 1, 1 is added to all the bank numbers in the soundfont. if you load it into bank 2, 2 is added to the bank numbers in the soundfont. that's how things work..

I'm not sure if all embedded banks are user banks, but it's a reasonable assumption, because user banks can be loaded and unloaded without loosing the main bank, and user banks cannot override bank zero.

Bank zero CAN be replaced, but only with a MAIN bank, not a USER bank. which means a full GM bank. How else would you load 4mbgmgsmt? that said, cards without installed sims probably only let you load user banks.

zaphod77 wrote on 2024-08-03, 13:54:

...
Bank zero CAN be replaced, but only with a MAIN bank, not a USER bank. which means a full GM bank. How else would you load 4mbgmgsmt? that said, cards without installed sims probably only let you load user banks.

Hi,
I said: "Bank 0 cannot be changed with regular sfman32 functions".
Bank 0 cannot be replaced with SFMAN32.dll calls when the used interface is either ID_SFMANL100API or ID_SFMANL101API. These 2 interfaces were the only ones available and publicly defined by Creative (AWE32/64 era). You can use these interfaces also with later cards (SB LIve!, Audigy etc.) but when SF_LoadBank() is used you cannot change bank 0 even on later generation of cards (you get an SFERR_BANK_INDEX_INVALID error). AFAIK you have to use aweman32 specific calls to do this on AWE32/64 cards but obviously aweman32 is not available in case of later SB cards.
But there are some not publicly defined/reverse engineered specific interfaces in SFMAN32 that can be used on later cards that can change bank 0.
Of course you could and can change bank 0 with official apps by Creative supplied by the drivers. But I talked about publicly available APIs (in SFMAN32).

ah. yeah i can understand why that's not allowed. which does mean that every bank embedded in a file is a user bank, because that's the only way to load them without the control panel app for the card.

zaphod77 wrote on 2024-08-03, 17:19:

ah. yeah i can understand why that's not allowed. which does mean that every bank embedded in a file is a user bank, because that's the only way to load them without the control panel app for the card.

Yep, basically that is the case.

Falcosoft wrote on 2024-08-03, 04:44:

Hi, 1. Yes, in this case all banks should be calculated with a +1 offset. So bank 1 becomes bank 2, bank 2 becomes bank 3, and […]
Show full quote

Spesek wrote on 2024-08-02, 20:53:

Thanks for your detailed response Zoltan. I would like to address it here. About the bank offsets: What about midi with embedde […]
Show full quote

Thanks for your detailed response Zoltan.
I would like to address it here.
About the bank offsets:
What about midi with embedded preset at bank 1?
My program currently produces .rmi files with bank offset of 1 (as the soundfont is embedded) and for example when the midi wants preset 1:80 (square), it makes it 2:80.
This seems to work with your program as well. I've uploaded 2 RMIs here: https://filetransfer.io/data-package/r0Y31KbQ#link

About sfogg:
It sounds very similar to The SoundFont3 Format which spessasynth supports (and so does FSMP6, since the RMIs I uploaded use ogg vorbis and it can read them no problem)
But trying to load sfogg with spessasynth causes the samples to sound like whitenoise, meaning incorrect offsets. So I'll try to reach out to Ian as you suggested.

About mod2midi:
It's a super cool piece of software! Though, it seems to be a bit incorrect with the samples and pitch bends.
Try unreeal superhero 3 and compare it with OpenMPT or VLC. it sounds a little off. It would be great if you could fix it, but if it's not your priority, I completely understand.

About your second post:
Yes, spessasynth currently doesn't support mixing soundfonts, although I've added an unpolished version of it that's hidden away. But adding a sort of "override soundfont" sounds simple enough, thanks for the suggestion!

PS:
The RMIDIs with embedded SF2 are super cool IMO. They could fix the biggest problem of MIDI: different sounds across different devices.
Also exporting them with the Sf3 format (Ogg vorbis compression) and trimmed samples like my program does, the is smaller to something like a wave file of the same length!
Maybe if we could get the big players like VLC and fluidsynth to support them, they could become mainstream. What do you think?

Thanks again for your response,
spessasus

Hi,
1. Yes, in this case all banks should be calculated with a +1 offset. So bank 1 becomes bank 2, bank 2 becomes bank 3, and bank 127 becomes 128 (a Drum bank!!!).
So this way you can also make melodic presets available at Drum channels. E.g. with a bank offset of 127 all banks of the soundfont from bank 1 are associated to drum channels.
Actually this is the way the Soundfont Bank Manager (sfman32) of hardware SF2 synths from Creative Labs always worked. Bassmidi also follows this logic.
So overall the logic behind the bank 1 as default is due to Creative demo files that most likely reflected the constrains of original SB hardware (bank 0 was in ROM and cannot be changed with regular sfman32 functions). Because of this Creative's demo files most of the time also presuppose a full GM bank at bank 0.
Modern software based SF2 synths have no such restriction and according to my experience so far most users expect custom soundfonts to be loaded to bank 0 by default. That's why there is an option for it in MidiPlayer.
But most likely the best solution would be a new field inside the outer info block (e.g. 'DBNK') of the rmidi file where you could define the destination bank/bank offset explicitly. If this field did not exist the bahaviour would be the current one (bank 1 by default but could be changed by the sofware) otherwise the explicitly defined value would be the destination bank.

2. Yes, you should definitely ask Ian. He is very helpful. He regularly answers even the most technical questions about Bass related stuff on the forum at un4seen.com.

3. I cannot promise anything regarding mod2midi 😀. BTW, Have you tried the latest version 6.4 of FSMP packaged with mod2midi v1.2.3? It fixed some pitch bend related errors. I hear no obvious problems with unreeeal_superhero_3.xm on latest version.

4. I'm not particularly good at convincing anyone about anything, but I could try to convince Ian about supporting rmidi files with embedded SF2 in Bassmidi.
I have absolutely no contacts to other projects like VLC and FluidSynth. So this would be your job 😀

Hi again Falco,

I think I've found a problem or a weird behavior with FSMP6 (version 6.4).
This RMI file uses XG and the instruments are incorrect.
SpessaSynth plays these correctly.

There's strat clean guitar (preset 27) on channel 2 when the instrument should be the embedded saw wave (Called "Roland Saw Lead").
I've looked at the file through the FSMP6's event explorer and didn't find a single program change referring to preset 27.

Also the gator kit (preset 17) is not used.
The bank is correctly set to 127 which indicates drums, and even subtracting 1 from it makes it 126, which still is a drum channel for XG
Yet your player opts to use the stock drums from the main soundfont (falcomod in this case).

A screenshot if that helps.

Also about mod2midi: it's still not correct 😒
The first instrument should sound like a square wave but sounds like a saw wave.
Also the pitch bends are correct, but too fast. Check around 25 seconds mark and compare it with VLC to see what I'm talking about. Again, I understand if you don't want to fix it, but it would be cool if you did.

PS: Regarding the RMIDI format, I'll update my code for writing RMIDIs with the DBNK chunk and add it to the wiki page i wrote.
Maybe it could become sort of "unofficial specification" for the MID+SF2 format, because it has a huge potential.

Spesek wrote on 2024-08-03, 20:06:

Hi again Falco, […]
Show full quote

Falcosoft wrote on 2024-08-03, 04:44:

Hi, 1. Yes, in this case all banks should be calculated with a +1 offset. So bank 1 becomes bank 2, bank 2 becomes bank 3, and […]
Show full quote

Spesek wrote on 2024-08-02, 20:53:

Thanks for your detailed response Zoltan. I would like to address it here. About the bank offsets: What about midi with embedde […]
Show full quote

Thanks for your detailed response Zoltan.
I would like to address it here.
About the bank offsets:
What about midi with embedded preset at bank 1?
My program currently produces .rmi files with bank offset of 1 (as the soundfont is embedded) and for example when the midi wants preset 1:80 (square), it makes it 2:80.
This seems to work with your program as well. I've uploaded 2 RMIs here: https://filetransfer.io/data-package/r0Y31KbQ#link

About sfogg:
It sounds very similar to The SoundFont3 Format which spessasynth supports (and so does FSMP6, since the RMIs I uploaded use ogg vorbis and it can read them no problem)
But trying to load sfogg with spessasynth causes the samples to sound like whitenoise, meaning incorrect offsets. So I'll try to reach out to Ian as you suggested.

About mod2midi:
It's a super cool piece of software! Though, it seems to be a bit incorrect with the samples and pitch bends.
Try unreeal superhero 3 and compare it with OpenMPT or VLC. it sounds a little off. It would be great if you could fix it, but if it's not your priority, I completely understand.

About your second post:
Yes, spessasynth currently doesn't support mixing soundfonts, although I've added an unpolished version of it that's hidden away. But adding a sort of "override soundfont" sounds simple enough, thanks for the suggestion!

PS:
The RMIDIs with embedded SF2 are super cool IMO. They could fix the biggest problem of MIDI: different sounds across different devices.
Also exporting them with the Sf3 format (Ogg vorbis compression) and trimmed samples like my program does, the is smaller to something like a wave file of the same length!
Maybe if we could get the big players like VLC and fluidsynth to support them, they could become mainstream. What do you think?

Thanks again for your response,
spessasus

Hi,
1. Yes, in this case all banks should be calculated with a +1 offset. So bank 1 becomes bank 2, bank 2 becomes bank 3, and bank 127 becomes 128 (a Drum bank!!!).
So this way you can also make melodic presets available at Drum channels. E.g. with a bank offset of 127 all banks of the soundfont from bank 1 are associated to drum channels.
Actually this is the way the Soundfont Bank Manager (sfman32) of hardware SF2 synths from Creative Labs always worked. Bassmidi also follows this logic.
So overall the logic behind the bank 1 as default is due to Creative demo files that most likely reflected the constrains of original SB hardware (bank 0 was in ROM and cannot be changed with regular sfman32 functions). Because of this Creative's demo files most of the time also presuppose a full GM bank at bank 0.
Modern software based SF2 synths have no such restriction and according to my experience so far most users expect custom soundfonts to be loaded to bank 0 by default. That's why there is an option for it in MidiPlayer.
But most likely the best solution would be a new field inside the outer info block (e.g. 'DBNK') of the rmidi file where you could define the destination bank/bank offset explicitly. If this field did not exist the bahaviour would be the current one (bank 1 by default but could be changed by the sofware) otherwise the explicitly defined value would be the destination bank.

2. Yes, you should definitely ask Ian. He is very helpful. He regularly answers even the most technical questions about Bass related stuff on the forum at un4seen.com.

3. I cannot promise anything regarding mod2midi 😀. BTW, Have you tried the latest version 6.4 of FSMP packaged with mod2midi v1.2.3? It fixed some pitch bend related errors. I hear no obvious problems with unreeeal_superhero_3.xm on latest version.

4. I'm not particularly good at convincing anyone about anything, but I could try to convince Ian about supporting rmidi files with embedded SF2 in Bassmidi.
I have absolutely no contacts to other projects like VLC and FluidSynth. So this would be your job 😀

Hi again Falco,

I think I've found a problem or a weird behavior with FSMP6 (version 6.4).
This RMI file uses XG and the instruments are incorrect.
SpessaSynth plays these correctly.

There's strat clean guitar (preset 27) on channel 2 when the instrument should be the embedded saw wave (Called "Roland Saw Lead").
I've looked at the file through the FSMP6's event explorer and didn't find a single program change referring to preset 27.

Also the gator kit (preset 17) is not used.
The bank is correctly set to 127 which indicates drums, and even subtracting 1 from it makes it 126, which still is a drum channel for XG
Yet your player opts to use the stock drums from the main soundfont (falcomod in this case).

A screenshot if that helps.

Also about mod2midi: it's still not correct 😒
The first instrument should sound like a square wave but sounds like a saw wave.
Also the pitch bends are correct, but too fast. Check around 25 seconds mark and compare it with VLC to see what I'm talking about. Again, I understand if you don't want to fix it, but it would be cool if you did.

PS: Regarding the RMIDI format, I'll update my code for writing RMIDIs with the DBNK chunk and add it to the wiki page i wrote.
Maybe it could become sort of "unofficial specification" for the MID+SF2 format, because it has a huge potential.

Hi,
1. Your koishi Midi file on track 1 contains explicit XG SysEx part parameter messages to set patches (these SysEx messages can be seen even in event viewer). And the event time of these SysEx messages are later than the event time of the program change messages on the same channel.
So sorry to say but in this case Midi Player plays this file correctly and your player does not. If you want Midi player to play this file the same way as yours you should disable Main menu -> SysEx options -> Enable SysEX in Files.
(BTW, I do not know why this Midi file is programmed this way. Usaually program change messages should be completely missing or at least should be consistent when XG SysEx messages are used to set programs on parts.)

Alright, I see.
I didn't know that XG could set programs like that. My bad.
Also, what's the program you took a screenshot of? It seems to explain the sysExes which would help me a lot with implementing them!

PS: What about the drums though? Are they set to something else via sysEx too?

Spesek wrote on 2024-08-03, 20:53:

PS: What about the drums though? Are they set to something else via sysEx too?

2. in SF2 specification bank 127 never means a Drum bank (always bank 128 is the drum bank). Since most SF2 soundfonts are GM/GS compatible and so bank 127 means an MT-32 compatible melodic bank (look at e.g. 4GMGSMT.SF2 from Creative) in case of XG files Bassmidi re-maps bank 128 to bank 127 so that regular SF2 soundfonts can be used to listen to XG Midi files.
But you can force such 'XG compatible' soundfonts to use bank 127 as Drum bank if you name the presets in bank 127 to contain XG drumset names such as 'Standard', 'Room', 'Rock' etc. at program 0, 8, 16 respectively.

Falcosoft wrote on 2024-08-03, 20:59:

Spesek wrote on 2024-08-03, 20:53:

PS: What about the drums though? Are they set to something else via sysEx too?

in case of XG files Bassmidi re-maps bank 128 to bank 127 so that regular SF2 soundfonts can be used to listen to XG Midi files.

That's what my program does as well. When XG is on and bank is set to 127, it becomes a drum channel.
And that's what's happening in koishi.rmi. In the screenshot I posted earlier, the system shows XG and bank MSB is set to 127.
The embedded soundfont has the "Gator Kit" at bank 128, program 17, so it should get remapped to 127:17 and play fine. Why doesn't that happen?

Spesek wrote on 2024-08-03, 21:11:

That's what my program does as well. When XG is on and bank is set to 127, it becomes a drum channel. And that's what's happenin […]
Show full quote

Falcosoft wrote on 2024-08-03, 20:59:

Spesek wrote on 2024-08-03, 20:53:

PS: What about the drums though? Are they set to something else via sysEx too?

in case of XG files Bassmidi re-maps bank 128 to bank 127 so that regular SF2 soundfonts can be used to listen to XG Midi files.

That's what my program does as well. When XG is on and bank is set to 127, it becomes a drum channel.
And that's what's happening in koishi.rmi. In the screenshot I posted earlier, the system shows XG and bank MSB is set to 127.
The embedded soundfont has the "Gator Kit" at bank 128, program 17, so it should get remapped to 127:17 and play fine. Why doesn't that happen?

It's because of the +1 bank offset. Gator Kit is available at bank 1 on channel 10 (or other drum channels) and bank 0 of channel 10 is mapped to bank 127 by Bammidi.
I could simulate what was happening with the embedded soundfont this way:

So I think it should be placed at bank 127 in the SF2 to load it to default drum bank (128) when +1 offset is used. But this is just a theory I have not tested it yet.

Falcosoft wrote on 2024-08-03, 21:35:

It's because of the +1 bank offset. Gator Kit is available at bank 1 on channel 10 (or other drum channels) and bank 0 of channe […]
Show full quote

Spesek wrote on 2024-08-03, 21:11:

That's what my program does as well. When XG is on and bank is set to 127, it becomes a drum channel. And that's what's happenin […]
Show full quote

Falcosoft wrote on 2024-08-03, 20:59:

in case of XG files Bassmidi re-maps bank 128 to bank 127 so that regular SF2 soundfonts can be used to listen to XG Midi files.

That's what my program does as well. When XG is on and bank is set to 127, it becomes a drum channel.
And that's what's happening in koishi.rmi. In the screenshot I posted earlier, the system shows XG and bank MSB is set to 127.
The embedded soundfont has the "Gator Kit" at bank 128, program 17, so it should get remapped to 127:17 and play fine. Why doesn't that happen?

It's because of the +1 bank offset. Gator Kit is available at bank 1 on channel 10 (or other drum channels) and bank 0 of channel 10 is mapped to bank 127 by Bammidi.
I could simulate what was happening with the embedded soundfont this way:

The attachment gator1.png is no longer available

The attachment gator2.png is no longer available

The attachment gator3.png is no longer available

Thanks Zoltan,
So how should i implement the RMIDI writing logic?
Currently my bank select is same as fluidsynth's for XG:
if msb is 120, 126 or 127, the channel is set to drums: force bank 128 and ignore cc32. Else cc32 is the bank number.

And my rmidi writing logic:
if no gs or xg, assume gs and add a GS on at the start.
For non-drum channels:
Verify that the program:bank combo exists in the soundfont used for export, otherwise change it to something that exists.
Shift every bank by 1.
For drum channels:
if gs: add gs drums on if channel is not 9 (default drums)
if xg: set bank to 127. This works with both fluid and my program since subtracting 1 is 126, which is still a drum channel according to the issue i linked earlier.
This logic doesn't seem to work with FSMP6 though, which is the main target for RMIDIS as it's currently the only compatible software i know that works with them.

What do you think? How should i tweak the XG logic for writing drums on RMIDIs for it to work with MP6?

Spesek wrote on 2024-08-03, 21:51:

Thanks Zoltan, So how should i implement the RMIDI writing logic? Currently my bank select is same as fluidsynth's for XG: if m […]
Show full quote

Falcosoft wrote on 2024-08-03, 21:35:

It's because of the +1 bank offset. Gator Kit is available at bank 1 on channel 10 (or other drum channels) and bank 0 of channe […]
Show full quote

Spesek wrote on 2024-08-03, 21:11:

That's what my program does as well. When XG is on and bank is set to 127, it becomes a drum channel.
And that's what's happening in koishi.rmi. In the screenshot I posted earlier, the system shows XG and bank MSB is set to 127.
The embedded soundfont has the "Gator Kit" at bank 128, program 17, so it should get remapped to 127:17 and play fine. Why doesn't that happen?

It's because of the +1 bank offset. Gator Kit is available at bank 1 on channel 10 (or other drum channels) and bank 0 of channel 10 is mapped to bank 127 by Bammidi.
I could simulate what was happening with the embedded soundfont this way:

The attachment gator1.png is no longer available

The attachment gator2.png is no longer available

The attachment gator3.png is no longer available

Thanks Zoltan,
So how should i implement the RMIDI writing logic?
Currently my bank select is same as fluidsynth's for XG:
if msb is 120, 126 or 127, the channel is set to drums: force bank 128 and ignore cc32. Else cc32 is the bank number.

And my rmidi writing logic:
if no gs or xg, assume gs and add a GS on at the start.
For non-drum channels:
Verify that the program:bank combo exists in the soundfont used for export, otherwise change it to something that exists.
Shift every bank by 1.
For drum channels:
if gs: add gs drums on if channel is not 9 (default drums)
if xg: set bank to 127. This works with both fluid and my program since subtracting 1 is 126, which is still a drum channel according to the issue i linked earlier.
This logic doesn't seem to work with FSMP6 though, which is the main target for RMIDIS as it's currently the only compatible software i know that works with them.

What do you think? How should i tweak the XG logic for writing drums on RMIDIs for it to work with MP6?

So I think XG drum presets should be placed at bank 127 in the SF2 to load it to default drum bank (128) when +1 offset is used. But this is just a theory I have not tested it yet.

BTW, The biggest problem is that SF2 is much more GS than XG oriented. SF2 has only 1 bank dimension (by convention CC#0 - Bank MSB) while XG requires 2 bank dimensions (Bank MSB+LSB). So making a single XG compatible SF2 file is not possible even in theory. And so this bank offset logic is also working best in GS mode.

@Edit:
I have tested and placing XG drum presets at bank 127 seems to work in case of embedded SF2 files with default destination bank 1 (+ 1 offset).

Falcosoft wrote on 2024-08-03, 21:55:

So I think XG drum presets should be placed at bank 127 in the SF2 to load it to default drum bank (128) when +1 offset is used. […]
Show full quote

Spesek wrote on 2024-08-03, 21:51:

Thanks Zoltan, So how should i implement the RMIDI writing logic? Currently my bank select is same as fluidsynth's for XG: if m […]
Show full quote

Falcosoft wrote on 2024-08-03, 21:35:

It's because of the +1 bank offset. Gator Kit is available at bank 1 on channel 10 (or other drum channels) and bank 0 of channe […]
Show full quote

It's because of the +1 bank offset. Gator Kit is available at bank 1 on channel 10 (or other drum channels) and bank 0 of channel 10 is mapped to bank 127 by Bammidi.
I could simulate what was happening with the embedded soundfont this way:

The attachment gator1.png is no longer available

The attachment gator2.png is no longer available

The attachment gator3.png is no longer available

Thanks Zoltan,
So how should i implement the RMIDI writing logic?
Currently my bank select is same as fluidsynth's for XG:
if msb is 120, 126 or 127, the channel is set to drums: force bank 128 and ignore cc32. Else cc32 is the bank number.

And my rmidi writing logic:
if no gs or xg, assume gs and add a GS on at the start.
For non-drum channels:
Verify that the program:bank combo exists in the soundfont used for export, otherwise change it to something that exists.
Shift every bank by 1.
For drum channels:
if gs: add gs drums on if channel is not 9 (default drums)
if xg: set bank to 127. This works with both fluid and my program since subtracting 1 is 126, which is still a drum channel according to the issue i linked earlier.
This logic doesn't seem to work with FSMP6 though, which is the main target for RMIDIS as it's currently the only compatible software i know that works with them.

What do you think? How should i tweak the XG logic for writing drums on RMIDIs for it to work with MP6?

So I think XG drum presets should be placed at bank 127 in the SF2 to load it to default drum bank (128) when +1 offset is used. But this is just a theory I have not tested it yet.

BTW, The biggest problem is that SF2 is much more GS than XG oriented. SF2 has only 1 bank dimension (by convention CC#0 - Bank MSB) while XG requires 2 bank dimensions (Bank MSB+LSB). So making a single XG compatible SF2 file is not possible even in theory. And so this bank offset logic is also working best in GS mode.

@Edit:
I have tested and placing XG drum presets at bank 127 seems to work in case of embedded SF2 files with default destination bank 1 (+ 1 offset).

I think I've found a roadblock.
You see, spessasynth makes a clear distinction between drum and melodic channels (just like fluidsynth).
This means that there's an internal boolean which shows if it's drums or not.
If it's set to drums, when the program change is called, the channel always looks for a preset with bank of 128.
BASS (and FSMP6) doesn't seem to work like this and simply sets the channel's 10 bank to 128 (and all others that receive GS DT1 sysEx)
and in the case of XG, it copies 128 to 127 like you've described.
And you're right about XG, it can't really work. (Though soundfont internally stores bank as a 16 bit value so ideas like this one exist.)

The problem
And putting the drumset at bank 127 poses a few problems:
What if some soundfont uses a preset on bank 127 and wants it in the embedded RMIDI? It would override the preset and potentially break things.
If you extract the soundfont, you'd have to manually change bank from 127 to 128 to make the soundfont work with anything other than the embedded midi.

My suggested solution
My suggestion is to add that same boolean for drum channels for FSMP6 like in fluid and spessa.

The logic is very simple:
Synth initialization:
set drums to false on everything except channel 0x9.

Channel change:
If new port added (via meta message), same stuff but with a 16 channel offset.
If GS DT1 is encountered, flag the drums on the channel as true or false (depending on the sysEx).
If XG is on and bank is 120, 126 or 127, flags the drums as true, else false.

Program selection:
if channel is drums, always use bank 128.
If channel is melodic, use the bank select.

On drum change:
simply execute a program change with the current program.
For example:

GS Version:
Channel is set to 0:16 drawbar organ.
Tt receives a GS DT1 so the "drum" flag is set to true.
Then call a program change with program 16.
The channel turns into 128:16 power kit.

XX version:
XG is set to on.
Channel is set to 0:25 classic steel guitar.
Channel's bank is set to 127.
Bank offset is 1 so the bank is effectively 126.
126 is a drum kit according to the XG spec so the "drum" flag is set to true.
Program change is called with program 25.
The channel turns into 128:25 TR-808 kit.

The benefits of this solution
Koishi.rmi was just an rmidi with all banks shifted by 1 except for drums.
This solution would make the bank offset be 1, so the midi setting bank on 127, would result in 126, which is still a drum channel, making the MIDI work.
This makes XG midis "just work" in the embedded soundfonts without any soundfont modifications.
And this solution would not break any current XG midis (127 is still drums).

Please consider this change. I'd also add a clear note on the RMIDI wiki page that for XG in RMIDIS drums always have to be 127.

PS:
BTW, how do you edit your posts? I can't find a button for it.

Spesek wrote on 2024-08-03, 23:14:

I think I've found a roadblock. You see, spessasynth makes a clear distinction between drum and melodic channels (just like flui […]
Show full quote

I think I've found a roadblock.
You see, spessasynth makes a clear distinction between drum and melodic channels (just like fluidsynth).
This means that there's an internal boolean which shows if it's drums or not.
If it's set to drums, when the program change is called, the channel always looks for a preset with bank of 128.
BASS (and FSMP6) doesn't seem to work like this and simply sets the channel's 10 bank to 128 (and all others that receive GS DT1 sysEx)
and in the case of XG, it copies 128 to 127 like you've described.
And you're right about XG, it can't really work. (Though soundfont internally stores bank as a 16 bit value so ideas like this one exist.)

The problem
And putting the drumset at bank 127 poses a few problems:
What if some soundfont uses a preset on bank 127 and wants it in the embedded RMIDI? It would override the preset and potentially break things.
If you extract the soundfont, you'd have to manually change bank from 127 to 128 to make the soundfont work with anything other than the embedded midi.

My suggested solution
My suggestion is to add that same boolean for drum channels for FSMP6 like in fluid and spessa.

The logic is very simple:
Synth initialization:
set drums to false on everything except channel 0x9.

Channel change:
If new port added (via meta message), same stuff but with a 16 channel offset.
If GS DT1 is encountered, flag the drums on the channel as true or false (depending on the sysEx).
If XG is on and bank is 120, 126 or 127, flags the drums as true, else false.

Program selection:
if channel is drums, always use bank 128.
If channel is melodic, use the bank select.

On drum change:
simply execute a program change with the current program.
For example:

GS Version:
Channel is set to 0:16 drawbar organ.
Tt receives a GS DT1 so the "drum" flag is set to true.
Then call a program change with program 16.
The channel turns into 128:16 power kit.

XX version:
XG is set to on.
Channel is set to 0:25 classic steel guitar.
Channel's bank is set to 127.
Bank offset is 1 so the bank is effectively 126.
126 is a drum kit according to the XG spec so the "drum" flag is set to true.
Program change is called with program 25.
The channel turns into 128:25 TR-808 kit.

The benefits of this solution
Koishi.rmi was just an rmidi with all banks shifted by 1 except for drums.
This solution would make the bank offset be 1, so the midi setting bank on 127, would result in 126, which is still a drum channel, making the MIDI work.
This makes XG midis "just work" in the embedded soundfonts without any soundfont modifications.
And this solution would not break any current XG midis (127 is still drums).

Please consider this change. I'd also add a clear note on the RMIDI wiki page that for XG in RMIDIS drums always have to be 127.

PS:
BTW, how do you edit your posts? I can't find a button for it.

Hi,
The whole soundfont bank management logic belongs to Bassmidi library not to FSMP. So if you want to change something related to it you have to convince Ian not me.
But honestly I do not think you will succeed because of 2 things:
a. It has been working this way for more than a decade and I do not think Ian would like to introduce breaking changes in this area.
b. It works in a way that is compatible with the soundfont bank management logic of hardware SF2 devices form Creative (AWE, Live!, Audigy etc.). And I also think that these devices should be the reference and not other soft synths.

But here are my reflections to your points anyway:
1. Bassmidi already has a boolean flag (MIDI_EVENT_DRUMS) that designates if a channel is actually a drum channel or not. Of course it can change even during playback since this status is time dependent (e.g. a channel can be a drum channel in the 1st half of the song and a melodic one in the 2nd half).
It works essentially the same way as you described but it has nothing to do with the bank management/bank offset logic.

2. The only difference between the logic you described and the logic Bassmidi follows is that Bassmidi considers the bank domain as a continuous space. This means that if you define a destination bank/bank offset that is different from 0 then all banks in the SF2 soundfont shift together (including the drum bank 128). This is true regardless of the actual Midi system (GS/GM2/XG).
That is in case of +1 bank offset the original drum bank will be available at bank 1 on drum channels and at bank 0 on drum channels bank 127 of the SF2 will be available. In contrast your logic always selects bank 128 of the SF2 regardless of the bank offset/destination bank.
As I told you previously:

Yes, in this case all banks should be calculated with a +1 offset. So bank 1 becomes bank 2, bank 2 becomes bank 3, and bank 127 becomes 128 (a Drum bank!!!).
So this way you can also make melodic presets available at Drum channels. E.g. with a bank offset of 127 all banks of the soundfont from bank 1 are associated to drum channels.

3. This bank offset logic is consistent and works perfectly in GS mode since in GS mode Bank MSB value has nothing to do with the drum channel status. The only purpose of Bank MSB in GS mode is to select the proper bank calculating with stacked soundfonts and different bank offset values of different soundfonts. The problem with XG is that you cannot make the drum channel selection logic consistent with the bank offset logic because in XG Bank MSB value should be used for both.
The original hardware SF2 synths had no such problem since they know nothing about XG and absolutely ignored Bank MSB 127 as a drum channel determining sign. But they were XG compatible in the sense that channel 10 was always a drum channel for them so most XG files sounded well as long as they used channel 10 for drums.

4.

Spesek wrote on 2024-08-03, 23:14:

What if some soundfont uses a preset on bank 127 and wants it in the embedded RMIDI? It would override the preset and potentially break things.
If you extract the soundfont, you'd have to manually change bank from 127 to 128 to make the soundfont work with anything other than the embedded midi.

This is not a real problem since a soundfont is either GS or XG compatible. It cannot be both. A GS compatible soundfont should have an MT-32 compatible bank at bank 127 and should not be used with XG Midi files. In the same way an XG compatible soundfont should have an XG compatible drum bank at bank 127 and should not be used with GS Midi files. This is analogous to Midi files anyway: you cannot have a Midi file that uses both GS and XG specific banks and is both GS and XG compatibleat at the same time.

So in case of soundfonts intended to be used with XG midi files always put XG Drum presets at bank 127. This works all the time regardless of embedding or not. Another benefit is that this also works with hardware SF2 synths from Creative since they do not use any re-mapping logic so your only chance to get drums with an XG Midi file on a channel (that is different from channel 10) is if you put Drum presets at bank 127.

Here is an example XG compatible SF2 soundfont that I think has the most ideal structure (of course with compromises). It is not GS compatible in the sense that it cannot be used for MT-32 emulation and GS variation tones but it uses 2 drum sets so it is still somewhat GM/GS compatible. It has 2 drum banks: an XG compatible drum bank at bank 127 and a GS compatible drum bank at bank 128:

PS:
You can use the pencil like icon at the right hand side of the post's header to edit it.

Falcosoft wrote on 2024-08-04, 06:18:

Hi, The whole soundfont bank management logic belongs to Bassmidi library not to FSMP. So if you want to change something relate […]
Show full quote

Spesek wrote on 2024-08-03, 23:14:

I think I've found a roadblock. You see, spessasynth makes a clear distinction between drum and melodic channels (just like flui […]
Show full quote

I think I've found a roadblock.
You see, spessasynth makes a clear distinction between drum and melodic channels (just like fluidsynth).
This means that there's an internal boolean which shows if it's drums or not.
If it's set to drums, when the program change is called, the channel always looks for a preset with bank of 128.
BASS (and FSMP6) doesn't seem to work like this and simply sets the channel's 10 bank to 128 (and all others that receive GS DT1 sysEx)
and in the case of XG, it copies 128 to 127 like you've described.
And you're right about XG, it can't really work. (Though soundfont internally stores bank as a 16 bit value so ideas like this one exist.)

The problem
And putting the drumset at bank 127 poses a few problems:
What if some soundfont uses a preset on bank 127 and wants it in the embedded RMIDI? It would override the preset and potentially break things.
If you extract the soundfont, you'd have to manually change bank from 127 to 128 to make the soundfont work with anything other than the embedded midi.

My suggested solution
My suggestion is to add that same boolean for drum channels for FSMP6 like in fluid and spessa.

The logic is very simple:
Synth initialization:
set drums to false on everything except channel 0x9.

Channel change:
If new port added (via meta message), same stuff but with a 16 channel offset.
If GS DT1 is encountered, flag the drums on the channel as true or false (depending on the sysEx).
If XG is on and bank is 120, 126 or 127, flags the drums as true, else false.

Program selection:
if channel is drums, always use bank 128.
If channel is melodic, use the bank select.

On drum change:
simply execute a program change with the current program.
For example:

GS Version:
Channel is set to 0:16 drawbar organ.
Tt receives a GS DT1 so the "drum" flag is set to true.
Then call a program change with program 16.
The channel turns into 128:16 power kit.

XX version:
XG is set to on.
Channel is set to 0:25 classic steel guitar.
Channel's bank is set to 127.
Bank offset is 1 so the bank is effectively 126.
126 is a drum kit according to the XG spec so the "drum" flag is set to true.
Program change is called with program 25.
The channel turns into 128:25 TR-808 kit.

The benefits of this solution
Koishi.rmi was just an rmidi with all banks shifted by 1 except for drums.
This solution would make the bank offset be 1, so the midi setting bank on 127, would result in 126, which is still a drum channel, making the MIDI work.
This makes XG midis "just work" in the embedded soundfonts without any soundfont modifications.
And this solution would not break any current XG midis (127 is still drums).

Please consider this change. I'd also add a clear note on the RMIDI wiki page that for XG in RMIDIS drums always have to be 127.

PS:
BTW, how do you edit your posts? I can't find a button for it.

Hi,
The whole soundfont bank management logic belongs to Bassmidi library not to FSMP. So if you want to change something related to it you have to convince Ian not me.
But honestly I do not think you will succeed because of 2 things:
a. It has been working this way for more than a decade and I do not think Ian would like to introduce breaking changes in this area.
b. It works in a way that is compatible with the soundfont bank management logic of hardware SF2 devices form Creative (AWE, Live!, Audigy etc.). And I also think that these devices should be the reference and not other soft synths.

But here are my reflections to your points anyway:
1. Bassmidi already has a boolean flag (MIDI_EVENT_DRUMS) that designates if a channel is actually a drum channel or not. Of course it can change even during playback since this status is time dependent (e.g. a channel can be a drum channel in the 1st half of the song and a melodic one in the 2nd half).
It works essentially the same way as you described but it has nothing to do with the bank management/bank offset logic.

2. The only difference between the logic you described and the logic Bassmidi follows is that Bassmidi considers the bank domain as a continuous space. This means that if you define a destination bank/bank offset that is different from 0 then all banks in the SF2 soundfont shift together (including the drum bank 128). This is true regardless of the actual Midi system (GS/GM2/XG).
That is in case of +1 bank offset the original drum bank will be available at bank 1 on drum channels and at bank 0 on drum channels bank 127 of the SF2 will be available. In contrast your logic always selects bank 128 of the SF2 regardless of the bank offset/destination bank.
As I told you previously:

Yes, in this case all banks should be calculated with a +1 offset. So bank 1 becomes bank 2, bank 2 becomes bank 3, and bank 127 becomes 128 (a Drum bank!!!).
So this way you can also make melodic presets available at Drum channels. E.g. with a bank offset of 127 all banks of the soundfont from bank 1 are associated to drum channels.

3. This bank offset logic is consistent and works perfectly in GS mode since in GS mode Bank MSB value has nothing to do with the drum channel status. The only purpose of Bank MSB in GS mode is to select the proper bank calculating with stacked soundfonts and different bank offset values of different soundfonts. The problem with XG is that you cannot make the drum channel selection logic consistent with the bank offset logic because in XG Bank MSB value should be used for both.
The original hardware SF2 synths had no such problem since they know nothing about XG and absolutely ignored Bank MSB 127 as a drum channel determining sign. But they were XG compatible in the sense that channel 10 was always a drum channel for them so most XG files sounded well as long as they used channel 10 for drums.

4.

Spesek wrote on 2024-08-03, 23:14:

What if some soundfont uses a preset on bank 127 and wants it in the embedded RMIDI? It would override the preset and potentially break things.
If you extract the soundfont, you'd have to manually change bank from 127 to 128 to make the soundfont work with anything other than the embedded midi.

This is not a real problem since a soundfont is either GS or XG compatible. It cannot be both. A GS compatible soundfont should have an MT-32 compatible bank at bank 127 and should not be used with XG Midi files. In the same way an XG compatible soundfont should have an XG compatible drum bank at bank 127 and should not be used with GS Midi files. This is analogous to Midi files anyway: you cannot have a Midi file that uses both GS and XG specific banks and is both GS and XG compatibleat at the same time.

So in case of soundfonts intended to be used with XG midi files always put XG Drum presets at bank 127. This works all the time regardless of embedding or not. Another benefit is that this also works with hardware SF2 synths from Creative since they do not use any re-mapping logic so your only chance to get drums with an XG Midi file on a channel (that is different from channel 10) is if you put Drum presets at bank 127.

Here is an example XG compatible SF2 soundfont that I think has the most ideal structure (of course with compromises). It is not GS compatible in the sense that it cannot be used for MT-32 emulation and GS variation tones but it uses 2 drum sets so it is still somewhat GM/GS compatible. It has 2 drum banks: an XG compatible drum bank at bank 127 and a GS compatible drum bank at bank 128:

The attachment DB50XG.zip is no longer available

PS:
You can use the pencil like icon at the right hand side of the post's header to edit it.

Hi again and thanks for the long and detailed response.
I think I know why it isn't working:
The embedded soundfont puts drums on 128.
This is kind of a problem.
The new soundfonts
You see, I'm quite new to the whole soundfont and MIDI standard (you can probably tell based on my lack of knowledge about XG sysExes and creative cards).
I know that most (if not all) modern soundfonts are made using software like Polyphone. That program describes the bank 128 as drum bank in the docs. A lot of new soundfonts simply do just that and... That's it. For example This super high quality soundfont (would recommend BTW) that I've been using has drums on bank 128. I have around 50 soundfonts and only a single one (Called "Yamaha XG Sound Set") has drums on 127 and 128.
The XG workaround
Then there's the fluidsynth. It is (to my knowledge) the most popular sf2 based midi synth (not to mention the fact that it's used in VLC which is even more popular).
So people download soundfonts such as the one I linked earlier, or one recommended by fluidsynth (called FluidR3_GM which also has drums on bank 128.) And expect it to "just work."
This works for GM and GS on creative, but not for XG as you've described (for a stock one it should, but for one that uses multiple drums it does not).
So everyone works around this: fluid and spessa force the bank to 128 when 127 is encountered and BASS (based on your description earlier) copies the presets with bank 128 to bank 127 with XG.
And this works great! Except the embedded RMIDI.

The bank offset problem
To be honest, I still don't completely understand it. Why is it 1? Why is there an offset at all? The RMIDI should be self-contained (like XM) and provide all samples and instruments to play the midi without modifying it.
But it seems to be fine, except for XG. So I think I have a solution that would require both of us to implement what you've suggested: the DBNK chunk.

The DBNK chunk
As you've mentioned before:

But most likely the best solution would be a new field inside the outer info block (e.g. 'DBNK') of the rmidi file where you could define the destination bank/bank offset explicitly. If this field did not exist the bahaviour would be the current one (bank 1 by default but could be changed by the sofware) otherwise the explicitly defined value would be the destination bank.

So I propose this exact solution. Since RMIDI format is not handled by BASS but by FSMP6, we're free to implement it
Koishi.rmi is just koishi.mid with a bank offset + SpessaSynthGMGS.sf3 combined. Playing koishi mid normally works fine, so the bank offset is the culprit.
I'll just make the RMI specify bank offset of 0 (it can be changed by the user exporting the file) which will leave the midi unmodified and play fine on both spessa and FSMP6.
But, to maintain compability, if no dbnk is specified, the bank offset would be 1, like earlier.
If you agree to the DBNk solution, I'll add it to the wiki page for RMIDI (you can also create an official specification on your site, I'll delete mine and link to yours since you're the creator of the mid+sf2 format 😀 )

For now, I could make the embedded sfont copy bank 128 to 127, but I think the dbnk would be a far more flexible solution.

Let me know what you think,
spessasus

PS:
Where?

Spesek wrote on 2024-08-04, 11:01:

The bank offset problem To be honest, I still don't completely understand it. Why is it 1? Why is there an offset at all? The RM […]
Show full quote

The bank offset problem
To be honest, I still don't completely understand it. Why is it 1? Why is there an offset at all? The RMIDI should be self-contained (like XM) and provide all samples and instruments to play the midi without modifying it.
But it seems to be fine, except for XG. So I think I have a solution that would require both of us to implement what you've suggested: the DBNK chunk.
...

Hi,
I think it has already been expained in previous posts, but let me summarize it again:
My RMIDI format is nothing more than Mid+SF2 pairs packed together. Mid+SF2 pairs have already been supported in FSMP for a long time so the logic remained the same. And the reason behind the working logic of Mid+SF2 pairs are the following:
1. The original Mid+SF2 demos from Creative used this +1 bank offset convention. If you pack them together into RMIDI format they only work if this +1 bank offset logic still holds. My MOD/XM module converter (mod2midi) also preserved this convention. If you pack the converted Mid+SF2 pairs into RMIDI it should preserve the same logic.
2. FSMP still supports SF2 hardware synths and on earlier ones you cannot even replace bank 0 programatically. But Creative demos packed into RMIDI format (and also my own converted Mid+SF2 pairs) work perfectly on classic hardware if the +1 bank offset convention is used.

I think you should not delete the documentation from your site since it is hardly likely that I will document the format in the near future. The 'DBNK' proposal is as much official as it can be so you can include it in your description. It think it should be a word sized numerical value (2 bytes), not a string. Possible values currently should be in the 0 - 127 range. I will implement it in FSMP when I will have enough free time.

It should be there (may be you have not enough posts to edit).

From what i understand, .rmi is a midi file, and an optional .DLS file

Not a .sf2 file.

Here are some actual .rmi with dls examples

https://archive.org/details/RIFF-MIDI-DLS

and they play back properly in winamp, which is the only free player which understands them properly. sadly as winamp is not open source, we can't "use the source" to solve the dillema.

the replacement for .rmi, which is .XMF, is 100% confirmed to use included .dls files with no offset. it can include either one, or multiple, and if multiple are included, it's required that they not overlap each other, though they are allowed to overlap with the GM/2 instruments. In this file format, there's sequencer specific meta data that chooses whether a given track is supposed to use gm1, gm2, or the included .dls instruments. In this way, both gm bank 0 and .dls bank 0 ae accessible.

I'm guessing that the older abandoned .rmi spec doesn't have this, but the dls level 1 spec states that dls 1 softsynths are not even required to support bank changes. this means that the included dls file is intended to overlay any existing gm bank that may be present. which means offset zero.

Bottom line is combining a midi file anda user bank to create a .rmi simply does not work. that's not how the format is supposed to work.

.mid+.sf2 of same name separate is supposed to be a user bank, because that's the only way a userland player can play it back on real hardware.

.rmi is embedded midi file, with optional embedded .dls file which is overlayed over any existing bank with offset zero.

so the proper way to convert the .mid+sf2 to ".rmi" is to default to offset 1 in the conversion, unless the .sf2 includes a full gm bank or includes anything in bank 128, in which case default the offset to zero. if the offset is one, the bank numbers should be increased before being stored into the .rmi file.

and well rmi is still supposed to have .dls, not .sf2 and i'm not sure if sf2 can be fullt converted to dls.

Note that the .xmf format is extensible, and you can define the format of ".mid+.sf2" include an offset for the .sf2 file.

TL:DR; if you are making a .rmi, modify the bank to remove the offset during the conversion. or create a .xmf variant that allows specifying the offset.

zaphod77 wrote on 2024-08-04, 15:14:

From what i understand, .rmi is a midi file, and an optional .DLS file […]
Show full quote

From what i understand, .rmi is a midi file, and an optional .DLS file

Not a .sf2 file.

Here are some actual .rmi with dls examples

https://archive.org/details/RIFF-MIDI-DLS

and they play back properly in winamp, which is the only free player which understands them properly. sadly as winamp is not open source, we can't "use the source" to solve the dillema.

the replacement for .rmi, which is .XMF, is 100% confirmed to use included .dls files with no offset. it can include either one, or multiple, and if multiple are included, it's required that they not overlap each other, though they are allowed to overlap with the GM/2 instruments. In this file format, there's sequencer specific meta data that chooses whether a given track is supposed to use gm1, gm2, or the included .dls instruments. In this way, both gm bank 0 and .dls bank 0 ae accessible.

I'm guessing that the older abandoned .rmi spec doesn't have this, but the dls level 1 spec states that dls 1 softsynths are not even required to support bank changes. this means that the included dls file is intended to overlay any existing gm bank that may be present. which means offset zero.

Bottom line is combining a midi file anda user bank to create a .rmi simply does not work. that's not how the format is supposed to work.

.mid+.sf2 of same name separate is supposed to be a user bank, because that's the only way a userland player can play it back on real hardware.

.rmi is embedded midi file, with optional embedded .dls file which is overlayed over any existing bank with offset zero.

so the proper way to convert the .mid+sf2 to ".rmi" is to default to offset 1 in the conversion, unless the .sf2 includes a full gm bank or includes anything in bank 128, in which case default the offset to zero. if the offset is one, the bank numbers should be increased before being stored into the .rmi file.

and well rmi is still supposed to have .dls, not .sf2 and i'm not sure if sf2 can be fullt converted to dls.

Note that the .xmf format is extensible, and you can define the format of ".mid+.sf2" include an offset for the .sf2 file.

TL:DR; if you are making a .rmi, modify the bank to remove the offset during the conversion. or create a .xmf variant that allows specifying the offset.

We were talking about a 'new' kind of rmi format that includes a Mid file and embedded SF2 soundfont that has never been specified before officially. It has been supported only by FSMP so far. But Spesek is more ambitious than me and he would like to make it a new standard. But even if this will not succeed at least two players/engines will support the new format: FSMP and his SpessaSynth.
BTW, this format is real riff Midi in the sense that this is also a valid RIFF file and the Midi part can be played by any players that can handle riff Midi files (similarly to riff Midi files that contain embedded DLS).

My point is that the .xmf format was specifically designed for just this exact purpose, and the correct thing to do is either make a new extension, or add it as an extension to .xmf, instead of suborn the existing one.