Me and some other developers have extended the SoundFont standard to add more features, and I've even gotten Polyphone and other SoundFont program devs involved. It can be found at:
https://github.com/SFe-Team-was-taken/SFe/releases/tag/4.0

Also we resurrected Silicon SoundFonts (Section 11 of the SoundFont spec, which was an official SF2-to-ROMpler mode, and I fixed the documentation, and that fix is on my Github), and I made a reference bank.

Hi Zoltan,
I just wanted to ask a question regarding the SF2Pack (more precisely, the SFOGG) format.

How did you compress the Reality GMGS to it? Is there a utility for that, or does FSMP6 have that functionality?
Because the only way I can think of now is using BASSMIDI and coding it to compress the font manually, so I was wondering if there's a nice program for that (can be CLI or GUI, I don't mind)

Thanks in advance!

Spesek wrote on 2025-02-14, 20:22:

Hi Zoltan, I just wanted to ask a question regarding the SF2Pack (more precisely, the SFOGG) format. […]
Show full quote

Hi Zoltan,
I just wanted to ask a question regarding the SF2Pack (more precisely, the SFOGG) format.

How did you compress the Reality GMGS to it? Is there a utility for that, or does FSMP6 have that functionality?
Because the only way I can think of now is using BASSMIDI and coding it to compress the font manually, so I was wondering if there's a nice program for that (can be CLI or GUI, I don't mind)

Thanks in advance!

Hi,
I have a command line sf2packer version. You can download it from here:
https://falcosoft.hu/sf2pack_ogg.zip

Falcosoft wrote on 2025-01-30, 00:51:

The VST framework I use is not open source so I cannot include the source. That's why e.g. Munt VSTi uses 2 dll files: 1 for the plugin and 1 for the MUNT library. This way the the terms of MUNT's LGPL license are not violated since LGPL allows that non-LGPL prgrams (such as Munt VSTi's frontend) link to the LGPL licensed library. The license of NukedSC-55 does not allow such linking and demands any derivative works to be open source.

Maybe you could add CLAP plugin support in Falcosoft MIDI Player and use this: https://github.com/johnnovak/Nuked-SC55-CLAP
But what would be the point of using Nuked SC-55 as a sound module for Falcosoft MIDI Player if Nuked can already work standalone?
Currently it is useful if you want to use two instances of (standalone) Nuked SC-55 for polyphony limits, but how would this be handled if Nuked becomes a CLAP/VST plugin?

HI Zoltan )
Please do same as in MT to GM and GM to MT , but only now for drums XG to GS or GS to XG ) , here more need XG to GS )
I mean what in XG drums track not coincides with GS on base SC-55 mode ) because if I want play XG MIDI on SCVA , I very often get result as in this MIDI file
and also can do SC-88 Pro / 8820 to XG Level 1 )

Roland User wrote on 2025-02-28, 09:24:

HI Zoltan ) Please do same as in MT to GM and GM to MT , but only now for drums XG to GS or GS to XG ) , here more need XG to GS […]
Show full quote

HI Zoltan )
Please do same as in MT to GM and GM to MT , but only now for drums XG to GS or GS to XG ) , here more need XG to GS )
I mean what in XG drums track not coincides with GS on base SC-55 mode ) because if I want play XG MIDI on SCVA , I very often get result as in this MIDI file
and also can do SC-88 Pro / 8820 to XG Level 1 )

XG to GS conversion is not the same at all so it would require a completely different approach. Namely GS can use only SysEx messages to designate drum channels while XG (mostly) uses Bank MSB 127 to designate drum channels.
Of course such conversion can be done but I'm not sure if it's worth the effort.
Your attached Midi file contains a GM reset before the XG one (like most other XG Midi files) that works on Sound Canvas devices including SC-VA. This way the drums on channel 10 also works since in GM mode Bank select messages are ignored by SC-VA. On the GUI of SC-VA you see the '------' on channel 10 as selected drum program because in GM mode only program 0 (Standard) is supported/displayed by SC-VA and the Midi file sets program 16 (Power). BTW, this is actually just a GUI issue since the backend synth engine of SC-VA sets program 16 (Power) anyway.
Be aware that this is because of GM mode so even an XG-GS drum bank conversion (setting Bank MSB to 0 instead of 127) would not change this.
The Midi file does not sound good on SC-VA since this Midi file uses advanced XG specific insertion effects that none of the GS devices support. But no kind of XG/GS drum conversion could help with this problem.

You not understand me ) , maybe I sayd not clear , but I want sayd what in drum sets available difference ) , and I want transform XG drums to GS drums ) also transform SC-8820 drums to XG drums ) for example , if we have diff snare for example snare in XG key 60 and snare in GS key 40 , and this diff I want fixed ) because now if I use XG midi on SCVA ,. so if on key 60 not snare , so I hear other sound what not correct )

I about this )

Roland User wrote on 2025-02-28, 14:04:

You not understand me ) , maybe I sayd not clear , but I want sayd what in drum sets available difference ) , and I want transform XG drums to GS drums ) also transform SC-8820 drums to XG drums ) for example , if we have diff snare for example snare in XG key 60 and snare in GS key 40 , and this diff I want fixed ) because now if I use XG midi on SCVA ,. so if on key 60 not snare , so I hear other sound what not correct )

I about this )

Maybe if you make the transformation file yourself (something similar to PATCHCNV.TXT) that defines what notes you would like to transform to other notes I can add it. Otherwise just forget it 😀.
I have no time and mood to inspect each drum notes.

I was thinked , whatg you have available ins files with durms notes )
But good ) I understand you )
If I find or make this files , I share this )

Roland User wrote on 2025-02-28, 15:56:

I was thinked , whatg you have available ins files with durms notes )
But good ) I understand you )
If I find or make this files , I share this )

If you had a look you would notice that my .ins files never contain drum notes...

Hi Zoltan,
Thanks for that sf2pack software, it was useful in testing the format as before i only had the realityGMGS soundfont to work with 😀

Now, I think I've ran into an issue with FSMP6 regarding RMI. I hope that it's not the same one as others I've reported, because the file is different.

NOTE: This is not a zip, remove .zip as it's just a raw RMI. This is to get vogons to allow the file.

The issues are:
Kicks & snares should be played by MSGS electronic patch. Instead it uses SGM Standard and it's very quiet.
The SFX kit is missing.
The lead flute is missing.

You can compare it with spessasynth for the correct playback. Note that my program uses 96 channels for this file, so maybe that's too much?

FSMP Version: 6.5 (64-bit)
BASS Version: 2.4.13.27
BASSMIDI Version: 2.4.14.16

PS: So is the program abbreviated to FSMP6, FSMP, MP6, MP, SFMP6 or SFMP? Or FSSFMP6?

Spesek wrote on 2025-03-01, 00:39:

Hi Zoltan, Thanks for that sf2pack software, it was useful in testing the format as before i only had the realityGMGS soundfont […]
Show full quote

Hi Zoltan,
Thanks for that sf2pack software, it was useful in testing the format as before i only had the realityGMGS soundfont to work with 😀

Now, I think I've ran into an issue with FSMP6 regarding RMI. I hope that it's not the same one as others I've reported, because the file is different.

NOTE: This is not a zip, remove .zip as it's just a raw RMI. This is to get vogons to allow the file.

The issues are:
Kicks & snares should be played by MSGS electronic patch. Instead it uses SGM Standard and it's very quiet.
The SFX kit is missing.
The lead flute is missing.

You can compare it with spessasynth for the correct playback. Note that my program uses 96 channels for this file, so maybe that's too much?

FSMP Version: 6.5 (64-bit)
BASS Version: 2.4.13.27
BASSMIDI Version: 2.4.14.16

PS: So is the program abbreviated to FSMP6, FSMP, MP6, MP, SFMP6 or SFMP? Or FSSFMP6?

Hi,
1. Yes, the maximum supported channels by FSMP is 64 (4 ports).
The reasons for it is detailed here:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
2. It's simply FSMP.

I see, but is there a reason for this limitation? If the software can handle more than 4 ports, why put an arbitrary limit at all? Even though no hardware used more than 4 ports, why can't new files use more of them? 0x21 can go up to 127 ports, so why not? After all, I believe that FSMP also uses hashmaps for these like spessa, so putting a single port change for port 100 will still result in 2 ports (32 channels) with the port 100 mapped to channels 16-31.
This file was, as previous ones, downloaded off musescore, so if such a popular website can and will use more than 4 ports, why not just remove the limit entirely?
Or does BASSMIDI have a cap?

But I have never encountered a Midi file that used more than 4 ports.

Well, now you have ; )

It seems people want also what and I ) at all , will be cool very very cool if make 16 ports with 16 synths ) I understand what this very very more , but if possible , I was be want this have )

Spesek wrote on 2025-03-01, 17:33:

I see, but is there a reason for this limitation? If the software can handle more than 4 ports, why put an arbitrary limit at al […]
Show full quote

I see, but is there a reason for this limitation? If the software can handle more than 4 ports, why put an arbitrary limit at all? Even though no hardware used more than 4 ports, why can't new files use more of them? 0x21 can go up to 127 ports, so why not? After all, I believe that FSMP also uses hashmaps for these like spessa, so putting a single port change for port 100 will still result in 2 ports (32 channels) with the port 100 mapped to channels 16-31.
This file was, as previous ones, downloaded off musescore, so if such a popular website can and will use more than 4 ports, why not just remove the limit entirely?
Or does BASSMIDI have a cap?

But I have never encountered a Midi file that used more than 4 ports.

Well, now you have ; )

Because Zoltan thinks what need strictly correspond quantity hardware ports )
What for this limit need now ? I not understand )
Because now few who use hardware synthesizers ) now more use software VSTi synthesizers ) and this limit not need )
I really wanted this for other goal , but Zoltan sure what this not need )

Spesek wrote on 2025-03-01, 17:33:

I see, but is there a reason for this limitation? If the software can handle more than 4 ports, why put an arbitrary limit at al […]
Show full quote

I see, but is there a reason for this limitation? If the software can handle more than 4 ports, why put an arbitrary limit at all? Even though no hardware used more than 4 ports, why can't new files use more of them? 0x21 can go up to 127 ports, so why not? After all, I believe that FSMP also uses hashmaps for these like spessa, so putting a single port change for port 100 will still result in 2 ports (32 channels) with the port 100 mapped to channels 16-31.
This file was, as previous ones, downloaded off musescore, so if such a popular website can and will use more than 4 ports, why not just remove the limit entirely?
Or does BASSMIDI have a cap?

But I have never encountered a Midi file that used more than 4 ports.

Well, now you have ; )

Hi,
BassMidi also has a max. channel limitation namely 128 channels/8 ports.
https://www.un4seen.com/doc/#bassmidi/BASS_MI … reamCreate.html
So full 128 ports/2048 channels or the Roland user suggested 16 ports/256 channels are not possible application wide anyway and I do not want to handle different max. channels at different modes/components. Moreover I do not think this is a serious limitation so I do not feel the urge to remove it in Midi Player and all its related components (VSTi etc.).

Well, now you have

Seriously, I still have not found a Midi file where this excessive port number is justified. Of course I could also make a Midi file in 10 minutes where all 16 channels would contain different port select meta events so the file would be a '256- channel' Midi file.
With a little extra work your example Midi file could be modified to be a 4-port/64-channel Midi file without any compromises.
BTW, always creating and using 128-channel streams is not free in terms of performance. In case of BassMidi you cannot modify the channel count dynamically without recreating the full stream. Midi Player uses the same real-time stream during its runtime until recreating it is really necessary (when config is changed or the new offline mode is set etc.). I think 64-channel is a good compromise because my arguments in the above linked post still holds.

99% of the users of my player uses it to listen to Midi files/games made for classic Midi gears. So my player's emphasis is there. Your modern Javascript based player is definitely made for a different audience/user base. 😀
Most likely that's why compatibility with SC-88 demo files (like Y4002_02.MID etc.) is more important for Midi player than for your synth and the other way around for random 96-channel musescore files.

Yes , but why these limitation ?
You can uderstand what if extend from 4 to 16 , you give opportunity use up to 16 synthesizer one synth per channel or 256 channels ) both variants very good )
This also can use for extend polyphony )

Roland User wrote on 2025-03-01, 23:25:

Yes , but why these limitation ?

I did answer this above:

So full 128 ports/2048 channels or the Roland user suggested 16 ports/256 channels are not possible application wide anyway and I do not want to handle different max. channels at different modes/components.

And please, let's stop this again.
I do not care and I do not want to use 16 ports anyway. You have to find someone else if you want this. It's that simple.

I you understand , but I want sayd what you will be see same appeals from users , because MIDI now not limited hardware synths and people want comfortable router and this it does not depend of your desire.
You can refuse do what ask users , but modern MIDI not the same as it was before and in modern MIDI absent older limitations )

Roland User wrote on 2025-03-02, 02:09:

...but modern MIDI not the same as it was before and in modern MIDI absent older limitations )

Hey, that's great! Then you should simply use all the other limitless modern Midi software based on your mentioned 'modern Midi' and simply leave me alone with my old, limited Midi software.
What are you talking about anyway? Midi 2.0?
Midi 2.0 is not supported by any VST 2.x plugins or hosts and never will be.
In Midi 1.0 that all existing VST 2.x hosts and plugins support the number of channels are limited to 16. That's why all existing VST 2.x synth plugins only support 16 channels at once, nothing more. And in the VST world 'ports' are not even mentioned since port select meta events were never really standardized and they are not even part of the Midi 1.0 protocol at all (only SMF files can contain it as a meta event). So VST hosts and VST plugins have no standard way to transfer 'port' information. According to my knowledge only my plugin uses the never really standardized 0xF5 real-time message to tranfer selected port information.
This is how your 'modern, limitless' Midi is working in reality.
BTW, I'm refusing only you. From now on all the time. Good Bye (I'm fed up and finally blocked you. I should have done this long before).