Spesek wrote on 2026-02-07, 23:07:

...

I think it would be simple to implement by adjusting the current GS/XG text displaying function to "decode" the bitmap as text.
What do you think?

In the end I implemented the graphics version since in some Midi files I used for testing the graphics and the text display run in parallel and that would be rather hard to implement with the same text display.
The graphics mode LCD messages use the Channel/Bass Visualization dialog for displaying graphics data. Here is a demo video I recorded:
https://youtu.be/0xJf5wNqB8A

BTW, I have no XG Midi files with corresponding graphics display data so I could not implement it. Do you have such XG Midi files that you can share?

mashakos wrote on 2026-02-03, 02:40:

That worked, nice! Two suggestions: - Option to magnify/scale the UI. Mainly for ppl like me who have DPI scaling disabled in wi […]
Show full quote

Falcosoft wrote on 2026-02-02, 23:27:

I think it's fixed in newest test version: https://falcosoft.hu/midiplayer_66_test.zip […]
Show full quote

I think it's fixed in newest test version:
https://falcosoft.hu/midiplayer_66_test.zip

BTW, FSMP's own topic is here on Vogons:
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

That worked, nice!
Two suggestions:
- Option to magnify/scale the UI. Mainly for ppl like me who have DPI scaling disabled in windows
- Add a "minimize to tray" button in the area indicated?

how did you get that theme?

the channels panic whenever I try mute/solo on any single given channel. is there a way to disable this jarring interruption?

ColomboGMGS2 wrote on 2026-02-09, 08:52:

the channels panic whenever I try mute/solo on any single given channel. is there a way to disable this jarring interruption?

Can you be a little more specific?
I could not reproduce any issues with mute/solo. Here is my test video:
https://youtu.be/NU8EPrXeeMM

Report back, or rather do a video about what works differently on your side.

I have a weird request; is there a way for the OPL3 GM VSTi to operate the emulated chip in "PERCUSSION" channel mode? I have some FM specific MIDIs that only have a IBK for melodic instruments and the percussion is done via "PERCUSSION" channel mode being enabled.

DracoNihil wrote on 2026-02-09, 16:36:

I have a weird request; is there a way for the OPL3 GM VSTi to operate the emulated chip in "PERCUSSION" channel mode? I have some FM specific MIDIs that only have a IBK for melodic instruments and the percussion is done via "PERCUSSION" channel mode being enabled.

Hi,
AFAIK 'Percussion' is a mode that occupies three channels to create 5 distinct drum sounds. So it is primarily for native FM synth programming and not for General Midi playback (it's not compatible with GM channel/drum patch layout).
Since OPL3 GM VSTi is not a low level OPL emulator you cannot set such configuration.
Some more info from Saga:
https://forum.openmpt.org/index.php?topic=624 … g46519#msg46519

Falcosoft wrote on 2026-02-09, 17:55:

Some more info from Saga:
https://forum.openmpt.org/index.php?topic=624 … g46519#msg46519

Huh, I guess I can try to figure out how to recreate percussion mode patches by just not touching the other operator in the instrument patch itself then.

Thanks for the link to that post.

Falcosoft wrote on 2026-02-09, 09:29:

Can you be a little more specific? I could not reproduce any issues with mute/solo. Here is my test video: https://youtu.be/NU8E […]
Show full quote

ColomboGMGS2 wrote on 2026-02-09, 08:52:

the channels panic whenever I try mute/solo on any single given channel. is there a way to disable this jarring interruption?

Can you be a little more specific?
I could not reproduce any issues with mute/solo. Here is my test video:
https://youtu.be/NU8EPrXeeMM

Report back, or rather do a video about what works differently on your side.

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable in fast melodies. But it does affect downtempo ones with long notes.
here goes my demo.

https://youtu.be/xK6pwI242hA

ColomboGMGS2 wrote on 2026-02-10, 06:49:

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable […]
Show full quote

Falcosoft wrote on 2026-02-09, 09:29:

Can you be a little more specific? I could not reproduce any issues with mute/solo. Here is my test video: https://youtu.be/NU8E […]
Show full quote

ColomboGMGS2 wrote on 2026-02-09, 08:52:

the channels panic whenever I try mute/solo on any single given channel. is there a way to disable this jarring interruption?

Can you be a little more specific?
I could not reproduce any issues with mute/solo. Here is my test video:
https://youtu.be/NU8EPrXeeMM

Report back, or rather do a video about what works differently on your side.

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable in fast melodies. But it does affect downtempo ones with long notes.
here goes my demo.

https://youtu.be/xK6pwI242hA

Hi,
The term 'Midi Panic' was not too helpful since it was so radical that it suggested for me that you noticed something that was fundamentally broken.
Watching your video made it clear what your problem was. I introduced All Sounds Off instead of All Notes Off in case of Mute/Solo since All Notes Off messages simply cannot mute looped sustained notes.
But to tell you the truth this problem occurs rather rarely since most sustained notes are not looped and have a proper release phase.
I did not think that a little bit more abrupt muting of notes makes someone think of 'Midi Panic' 😀.
So OK, I reverted the change. You can try the new test version. You should simply overwrite the files in FSMP's folder with the new ones:
https://falcosoft.hu/midiplayer_66_test.zip

Falcosoft wrote on 2026-02-09, 02:01:

In the end I implemented the graphics version since in some Midi files I used for testing the graphics and the text display run […]
Show full quote

In the end I implemented the graphics version since in some Midi files I used for testing the graphics and the text display run in parallel and that would be rather hard to implement with the same text display.
The graphics mode LCD messages use the Channel/Bass Visualization dialog for displaying graphics data. Here is a demo video I recorded:
https://youtu.be/0xJf5wNqB8A

BTW, I have no XG Midi files with corresponding graphics display data so I could not implement it. Do you have such XG Midi files that you can share?

Hi,
Sorry for the late reply, vogons didn't send me an email about it 🙁
The display you added looks very nice! Hoping for a green one for XG 😀

Regarding your question, you can find XG display graphics in Kr.Palto47's XG MIDIs (I linked the whole folder this time):

https://drive.google.com/drive/folders/15GLn- … VkBj0hQw7Sq8Mo2

For example: Era 2 -> touhou 12 -> emotional skyscraper (MU2000EX)
or Era 2-> touhou 11 -> satori maiden (also MU2000EX)

The second one has an animation playing throughout the whole file, apparently some demo XG MIDIs have it as well.

PS: Where did you get that Star Games and 3X3EYES files? They look really cool!

PS/2: Would it be possible for the FSMP to automatically change patch names based on the system? E.g. scva patches in GS, SYXG50/MU1000EX patches in XG.

Spesek wrote on 2026-02-11, 15:48:

Hi, Sorry for the late reply, vogons didn't send me an email about it :-( The display you added looks very nice! Hoping for a gr […]
Show full quote

Falcosoft wrote on 2026-02-09, 02:01:

In the end I implemented the graphics version since in some Midi files I used for testing the graphics and the text display run […]
Show full quote

In the end I implemented the graphics version since in some Midi files I used for testing the graphics and the text display run in parallel and that would be rather hard to implement with the same text display.
The graphics mode LCD messages use the Channel/Bass Visualization dialog for displaying graphics data. Here is a demo video I recorded:
https://youtu.be/0xJf5wNqB8A

BTW, I have no XG Midi files with corresponding graphics display data so I could not implement it. Do you have such XG Midi files that you can share?

Hi,
Sorry for the late reply, vogons didn't send me an email about it 🙁
The display you added looks very nice! Hoping for a green one for XG 😀

Regarding your question, you can find XG display graphics in Kr.Palto47's XG MIDIs (I linked the whole folder this time):

https://drive.google.com/drive/folders/15GLn- … VkBj0hQw7Sq8Mo2

For example: Era 2 -> touhou 12 -> emotional skyscraper (MU2000EX)
or Era 2-> touhou 11 -> satori maiden (also MU2000EX)

The second one has an animation playing throughout the whole file, apparently some demo XG MIDIs have it as well.

PS: Where did you get that Star Games and 3X3EYES files? They look really cool!

PS/2: Would it be possible for the FSMP to automatically change patch names based on the system? E.g. scva patches in GS, SYXG50/MU1000EX patches in XG.

Hi,
1. OK, It's green!
BTW, Thanks for the example files. Testing was much easier this way.

2. I do not remember, hut here they are for download:

3. The situation is more complicated. FSMP does not use fixed/builtin patch names but external instrument definition files (*.ins). Everyone can use their own or use the included ones but FSMP cannot rely on that some of them are always available.
Moreover FSMP has 3 main patch name displaying modes and you can use any of them independently form the output mode. E.g. you can use the loaded SF2 preset names even when an external synth is the actual output or vice versa.
Typically in case of hardware SB SF2 synths and even in case of Bassmidi output the loaded SF2 preset names are more useful than SC-VA/SYXG50 patch names regardless of the Midi system (XG/GS) used by the Midi files.

But I will try to find out some kind of compromise solution.

Hi Falco,
The new display looks great and thanks for the MIDI files!
However I believe I have found a bug in FSMP's seeking algorithm.

When you load the "Idecs Hyper Groove / LATIN" (34H_Latn.mid) 88Pro demo song into FSMP, the seeking behavior is incorrect.
More precisely, the file enables phaser EFX at around 1:20 for the ending drum sequence. If you seek after this time, the EFX is not activated as it should.
Also, after it activates and you seek backwards (for example to 0:10),
the EFX stays on for the drums despite it not being enabled for most of the song when you play the file from the beginning.

It looks like FSMP ignores sysEx when seeking? What do you think?

PS: Regarding the patch names request, choosing a specific *.ins files for XG/GS is of course fine too.
Actually, would it be possible to extend this request to switching
to a specific VSTi for the system (syxg50 for XG and SCVA for GS), or is this too much? 😉

Spesek wrote on 2026-02-13, 02:22:

Hi Falco, The new display looks great and thanks for the MIDI files! However I believe I have found a bug in FSMP's seeking algo […]
Show full quote

Hi Falco,
The new display looks great and thanks for the MIDI files!
However I believe I have found a bug in FSMP's seeking algorithm.

When you load the "Idecs Hyper Groove / LATIN" (34H_Latn.mid) 88Pro demo song into FSMP, the seeking behavior is incorrect.
More precisely, the file enables phaser EFX at around 1:20 for the ending drum sequence. If you seek after this time, the EFX is not activated as it should.
Also, after it activates and you seek backwards (for example to 0:10),
the EFX stays on for the drums despite it not being enabled for most of the song when you play the file from the beginning.

It looks like FSMP ignores sysEx when seeking? What do you think?

PS: Regarding the patch names request, choosing a specific *.ins files for XG/GS is of course fine too.
Actually, would it be possible to extend this request to switching
to a specific VSTi for the system (syxg50 for XG and SCVA for GS), or is this too much? 😉

Hi,
1. Sending SysEx messages while seeking is disabled in FSMP deliberately. It's because some devices (mostly hardware but even some soft synths like Munt) have limited SysEx buffers and you cannot send large amount of SysEx data in a tight loop without risking complete freezing. Some Midi files contain hundreds of SysEx messages with the size of more than ~20KB. In such case even virtual Midi cables detect 'loopback error' and stop working.
In case of short messages FSMP filters out the redundant messages during seeking but in case of SysEx messages you would need full SysEx interpreters for all Midi systems to determine what is a redundant message. So you could only send all SySex messages during seeking. Some synths (e.g. my Dreamblaster X2) completely freeze and require a full restart when I try to do this.
Maybe some heuristics can be added that depending on the amount of SysEx messages enables/disables sending during seek time. This would work with your file since it has relatively few messages.

2. In the end 'Autoselect Patch names' resulted in some headaches because of logical inconsistencies. I had to disable software CTF while it is enabled. It's because so far when CTF was enabled the output device dominated and the Midi file's messages was altered to play properly on the output device according to the selected instrument definition. But now when 'Autoselect Patch names' is enabled FSMP cannot do this anymore since the Midi file (or selected Midi system) dominates and loads the linked instrument definition regardless if the output device is compatible with it or not. So 'Autoselect Patch Names' will be disabled by default and you also have to select 'Custom Patch Names' option explicitly to enable it. The configuration will look like this:

3. Yep, it's too much. It's because FSMP has to restart the whole engine when changing output device. And some Midi files contain multiple different SysEx resets so such restart would happen multiple times. Plugins like SC-VA requires more than 3 seconds to initialize so for many seconds the playback would stall. Not to mention that plugins require different sample rates, volume level, default reset mode etc. so simply changing the plugin during playback is not ideal.
But of course you can use completely fine tuned configurations with the help of Main menu-> Configuration presets. Then with the help of Ctrl + Alt + 'preset number' key combos you can switch between presets without even opening the dialog again.

@Edit:
BTW, I have also added the option to the context menu of Visualization dialog to use inverted colors which resembles more to the colors of the original LCD display:

New test version can be downloaded form here:
https://falcosoft.hu/midiplayer_66_test.zip

Falcosoft wrote on 2026-02-13, 09:47:

Hi, 1. Sending SysEx messages while seeking is disabled in FSMP deliberately. It's because some devices (mostly hardware but eve […]
Show full quote

Spesek wrote on 2026-02-13, 02:22:

Hi Falco, The new display looks great and thanks for the MIDI files! However I believe I have found a bug in FSMP's seeking algo […]
Show full quote

Hi Falco,
The new display looks great and thanks for the MIDI files!
However I believe I have found a bug in FSMP's seeking algorithm.

When you load the "Idecs Hyper Groove / LATIN" (34H_Latn.mid) 88Pro demo song into FSMP, the seeking behavior is incorrect.
More precisely, the file enables phaser EFX at around 1:20 for the ending drum sequence. If you seek after this time, the EFX is not activated as it should.
Also, after it activates and you seek backwards (for example to 0:10),
the EFX stays on for the drums despite it not being enabled for most of the song when you play the file from the beginning.

It looks like FSMP ignores sysEx when seeking? What do you think?

PS: Regarding the patch names request, choosing a specific *.ins files for XG/GS is of course fine too.
Actually, would it be possible to extend this request to switching
to a specific VSTi for the system (syxg50 for XG and SCVA for GS), or is this too much? 😉

Hi,
1. Sending SysEx messages while seeking is disabled in FSMP deliberately. It's because some devices (mostly hardware but even some soft synths like Munt) have limited SysEx buffers and you cannot send large amount of SysEx data in a tight loop without risking complete freezing. Some Midi files contain hundreds of SysEx messages with the size of more than ~20KB. In such case even virtual Midi cables detect 'loopback error' and stop working.
In case of short messages FSMP filters out the redundant messages during seeking but in case of SysEx messages you would need full SysEx interpreters for all Midi systems to determine what is a redundant message. So you could only send all SySex messages during seeking. Some synths (e.g. my Dreamblaster X2) completely freeze and require a full restart when I try to do this.

2. In the end 'Autoselect Patch names' resulted in some headaches because of logical inconsistencies. I had to disable software CTF while it is enabled. It's because so far when CTF was enabled the output device dominated and the Midi file's messages was altered to play properly on the output device according to the selected instrument definition. But now when 'Autoselect Patch names' is enabled FSMP cannot do this anymore since the Midi file (or selected Midi system) dominates and loads the linked instrument definition regardless if the output device is compatible with it or not. So 'Autoselect Patch Names' will be disabled by default and you also have to select 'Custom Patch Names' option explicitly to enable it. The configuration will look like this:

The attachment AutoPatchNames.jpg is no longer available

3. Yep, it's too much. It's because FSMP has to restart the whole engine when changing output device. And some Midi files contain multiple different SysEx resets so such restart would happen multiple times. Plugins like SC-VA requires more than 3 seconds to initialize so for many seconds the playback would stall. Not to mention that plugins require different sample rates, volume level, default reset mode etc. so simply changing the plugin during playback is not ideal.
But of course you can use completely fine tuned configurations with the help of Main menu-> Configuration presets. Then with the help of Ctrl + Alt + 'preset number' key combos you can switch between presets without even opening the dialog again.

@Edit:
BTW, I have also added the option to the context menu of Visualization dialog to use inverted colors which resembles more to the colors of the original LCD display:

The attachment invertedLCD.jpg is no longer available

New test version can be downloaded form here:
https://falcosoft.hu/midiplayer_66_test.zip

Hi,

1. I get where you're coming from. Spessasynth's sequencer just bombs the synth with all sysExes at once when seeking and when I reroute the MIDI output into something like nuked55, it doesn't seem to like that 😀
Though something i thought of would be adding a short delay after each message, maybe like 5ms (configurable?) or similar to let the synth process it, essentially emulating the initial silence in a MIDI file where the synth is getting configured (this would not affect bassmidi mode). This does mean that seeking would take a bit longer though. What do you think?

2. Thanks, the automatic patch selection works great!

3. That's okay, I was just wondering since foo_midi can pick a VST based on the MIDI system.
Though that reminds me of another question:
In Kr.Palto47's MIDI files there's one MIDI (CD Albums -> Magical Astronomy -> Necrofantasia -> XG2000EX -> smf1) that uses 64 channels. FSMP correctly detects it as 64 channels, though it works only with BASSMIDI.
I saw that there's a multi-port VSTi included, though it's only for MIDI ports, not VST plugins.
So I was wondering would it be possible to run 4 SYXG50s at once to play this MIDI file?
I noticed that you can load multiple VST plugins but only as effects, not as instruments.

Spesek wrote on 2026-02-13, 17:08:

1. I get where you're coming from. Spessasynth's sequencer just bombs the synth with all sysExes at once when seeking and when I […]
Show full quote

1. I get where you're coming from. Spessasynth's sequencer just bombs the synth with all sysExes at once when seeking and when I reroute the MIDI output into something like nuked55, it doesn't seem to like that 😀
Though something i thought of would be adding a short delay after each message, maybe like 5ms (configurable?) or similar to let the synth process it, essentially emulating the initial silence in a MIDI file where the synth is getting configured (this would not affect bassmidi mode). This does mean that seeking would take a bit longer though. What do you think?

2. Thanks, the automatic patch selection works great!

3. That's okay, I was just wondering since foo_midi can pick a VST based on the MIDI system.
Though that reminds me of another question:
In Kr.Palto47's MIDI files there's one MIDI (CD Albums -> Magical Astronomy -> Necrofantasia -> XG2000EX -> smf1) that uses 64 channels. FSMP correctly detects it as 64 channels, though it works only with BASSMIDI.
I saw that there's a multi-port VSTi included, though it's only for MIDI ports, not VST plugins.
So I was wondering would it be possible to run 4 SYXG50s at once to play this MIDI file?
I noticed that you can load multiple VST plugins but only as effects, not as instruments.

Hi,
1. Unfortunately I think the situation is more complicated. Not all SysEx messages require the same amount of time to be processed. Typically reset-like messages require rather 50 ms than 5 ms on real HW synths...
I'm also thinking about some kind of compromise solution but to tell you the truth a new option to enable/disable sending SysEx mesasges during seeking seems to be the most reasonable. But even if the option is enabled I think GM/GS/XG etc. reset messages should be skipped during seeking (at least on HW devices). These messages require the longest processing time and while they are processed most synths simply ignore/skip other messages. And GM/GS/XG reset messages in 99% of cases only required once at the very beginning and never needed to be sent again (especially not during seeking).

2. Nice, I'm glad. Thanks for the testing.

3. Currently FSMP alone is not enough to play multi port Midi files through VSTi. You also need my VST MIDI driver to do this:
https://github.com/Falcosoft/vstdriver
For 2- port/32-channel playback you have to simply select either the VST MIDI driver A or B port directly in FSMP and the rest is working automatically since VST MIDI driver supports 0xF5 port select messages. Here is a test video about this:
https://youtu.be/edHM21rWXRg

For 4-port /64-channel playback you also need my WinMM Multiport VSTi included in FSMP's package. Then you also need to start the VST MIDI driver's global proxy component that provides 2 additional ports. Then with the help of WinMM Multiport VSTi you can select 4 S-YXG50 instances at once. Something like this:

Falcosoft wrote on 2026-02-10, 10:00:

Hi, The term 'Midi Panic' was not too helpful since it was so radical that it suggested for me that you noticed something that w […]
Show full quote

ColomboGMGS2 wrote on 2026-02-10, 06:49:

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable […]
Show full quote

Falcosoft wrote on 2026-02-09, 09:29:

Can you be a little more specific? I could not reproduce any issues with mute/solo. Here is my test video: https://youtu.be/NU8E […]
Show full quote

Can you be a little more specific?
I could not reproduce any issues with mute/solo. Here is my test video:
https://youtu.be/NU8EPrXeeMM

Report back, or rather do a video about what works differently on your side.

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable in fast melodies. But it does affect downtempo ones with long notes.
here goes my demo.

https://youtu.be/xK6pwI242hA

Hi,
The term 'Midi Panic' was not too helpful since it was so radical that it suggested for me that you noticed something that was fundamentally broken.
Watching your video made it clear what your problem was. I introduced All Sounds Off instead of All Notes Off in case of Mute/Solo since All Notes Off messages simply cannot mute looped sustained notes.
But to tell you the truth this problem occurs rather rarely since most sustained notes are not looped and have a proper release phase.
I did not think that a little bit more abrupt muting of notes makes someone think of 'Midi Panic' 😀.
So OK, I reverted the change. You can try the new test version. You should simply overwrite the files in FSMP's folder with the new ones:
https://falcosoft.hu/midiplayer_66_test.zip

Your test version is a blast <3
All good here.
btw, sorry for sounding vague. I learned these MIDI stuff and some terminology by basically fooling around,
and I wanna acknowledge that I am willing to learn more about the inner workings, and correct any misunderstandings I have made so far.

Falcosoft wrote on 2026-02-10, 10:00:

Hi, The term 'Midi Panic' was not too helpful since it was so radical that it suggested for me that you noticed something that w […]
Show full quote

ColomboGMGS2 wrote on 2026-02-10, 06:49:

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable […]
Show full quote

Falcosoft wrote on 2026-02-09, 09:29:

Can you be a little more specific? I could not reproduce any issues with mute/solo. Here is my test video: https://youtu.be/NU8E […]
Show full quote

Can you be a little more specific?
I could not reproduce any issues with mute/solo. Here is my test video:
https://youtu.be/NU8EPrXeeMM

Report back, or rather do a video about what works differently on your side.

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable in fast melodies. But it does affect downtempo ones with long notes.
here goes my demo.

https://youtu.be/xK6pwI242hA

Hi,
The term 'Midi Panic' was not too helpful since it was so radical that it suggested for me that you noticed something that was fundamentally broken.
Watching your video made it clear what your problem was. I introduced All Sounds Off instead of All Notes Off in case of Mute/Solo since All Notes Off messages simply cannot mute looped sustained notes.
But to tell you the truth this problem occurs rather rarely since most sustained notes are not looped and have a proper release phase.
I did not think that a little bit more abrupt muting of notes makes someone think of 'Midi Panic' 😀.
So OK, I reverted the change. You can try the new test version. You should simply overwrite the files in FSMP's folder with the new ones:
https://falcosoft.hu/midiplayer_66_test.zip

Update: Something fishy is going on with my new "Sub Aqua" preset I designed keeping step with the same named preset found in some Yamaha PSR.
probably this is just a bassmidi issue...

My tone is designed to go through a delayed filter envelope that goes like this (according to how I hear or at least imagine)
in the initial envelope delay of 0.05 seconds, the tone stays bright during that small time,
Then with a snappy attack (almost sounds like a cut) of 0.001 seconds the tone dips below a low-pass filter of -3100 cents.
When the note is released, then it gradually climbs (or Wahs) back up to the brightness as it quickly fades out.
The overall pattern sounds like an "AMmmmmwuA" rather than an "AWUummmuwuh"

Somehow the snappy attack I mentioned has now become slower.
Even when I remove the attack value entirely, the new bassmidi puts some high attack time value as a placeholder.
So there is a difference between how it sounded before on FSMP 5.8's bassmidi library and the current one.
The current bassmidi version had pretty much turned my sub aqua into nothing more than a "yet another synth bass preset" 🙁
*this same problem is also present in virtualmidisynth 2.12.8 as well.

Test video: https://youtu.be/tTHG1XxfSdg

And also, there is this drum-chorus-prohibition facade I read from that discussion on Un4seen. I tried my best to ignore that difference until I played some old karaoke midi files.
In those tracks, every single channel including drums was set at a high chorus level.
Back then I clearly remembered that every element had had the same level of stereo presence thanks to chorus.
But now that I don't have chorus on drums, I can barely hear them, because all other melodic voices still scream in stereo chorus unbeknownst to the now-weaker drums.
tldr, when chorus is feeling unmusical, we'd willingly turn our chorus knobs shut on drums. But now we are not allowed to turn it on at GS mode,
despite us wanting stereo presence at such times.

ColomboGMGS2 wrote on Yesterday, 10:56:

Update: Something fishy is going on with my new "Sub Aqua" preset I designed keeping step with the same named preset found in so […]
Show full quote

Falcosoft wrote on 2026-02-10, 10:00:

Hi, The term 'Midi Panic' was not too helpful since it was so radical that it suggested for me that you noticed something that w […]
Show full quote

ColomboGMGS2 wrote on 2026-02-10, 06:49:

My apologies for rushed typing. I still find it hard to gather words on what's happening. Of course a MIDI Panic is unnoticeable in fast melodies. But it does affect downtempo ones with long notes.
here goes my demo.

https://youtu.be/xK6pwI242hA

Hi,
The term 'Midi Panic' was not too helpful since it was so radical that it suggested for me that you noticed something that was fundamentally broken.
Watching your video made it clear what your problem was. I introduced All Sounds Off instead of All Notes Off in case of Mute/Solo since All Notes Off messages simply cannot mute looped sustained notes.
But to tell you the truth this problem occurs rather rarely since most sustained notes are not looped and have a proper release phase.
I did not think that a little bit more abrupt muting of notes makes someone think of 'Midi Panic' 😀.
So OK, I reverted the change. You can try the new test version. You should simply overwrite the files in FSMP's folder with the new ones:
https://falcosoft.hu/midiplayer_66_test.zip

Update: Something fishy is going on with my new "Sub Aqua" preset I designed keeping step with the same named preset found in some Yamaha PSR.
probably this is just a bassmidi issue...

My tone is designed to go through a delayed filter envelope that goes like this (according to how I hear or at least imagine)
in the initial envelope delay of 0.05 seconds, the tone stays bright during that small time,
Then with a snappy attack (almost sounds like a cut) of 0.001 seconds the tone dips below a low-pass filter of -3100 cents.
When the note is released, then it gradually climbs (or Wahs) back up to the brightness as it quickly fades out.
The overall pattern sounds like an "AMmmmmwuA" rather than an "AWUummmuwuh"

Somehow the snappy attack I mentioned has now become slower.
Even when I remove the attack value entirely, the new bassmidi puts some high attack time value as a placeholder.
So there is a difference between how it sounded before on FSMP 5.8's bassmidi library and the current one.
The current bassmidi version had pretty much turned my sub aqua into nothing more than a "yet another synth bass preset" 🙁
*this same problem is also present in virtualmidisynth 2.12.8 as well.

Test video: https://youtu.be/tTHG1XxfSdg

...

Hi,
Unfortunately I cannot help with such issues. You should tell such problems to Ian at https://www.un4seen.com/ (forum section).
He is usually very helpful, but of course his and our vision of Bassmidi regarding compatibility sometimes differ and of course usually his version wins.

@Edit:
1. Regarding your ruined tone problem:
In FSMP there is an advanced setting that can only be changed using the registry (HKEY_CURRENT_USER\Software\falcosoft\MidiPlayer) or in the MidiPlayer.ini file. It's called

BassMidiFontInitFlags

. With the help of this flags field you can try/set any present or future values defined by BassMidi. That is:

1// BASS_MIDI_FontInit flags
2#define BASS_MIDI_FONT_MEM			0x10000
3#define BASS_MIDI_FONT_MMAP			0x20000
4#define BASS_MIDI_FONT_XGDRUMS		0x40000
5#define BASS_MIDI_FONT_NOFX			0x80000
6#define BASS_MIDI_FONT_LINATTMOD	0x100000
7#define BASS_MIDI_FONT_LINDECVOL	0x200000
8#define BASS_MIDI_FONT_NORAMPIN		0x400000
9#define BASS_MIDI_FONT_NOSBLIMITS	0x800000
10#define BASS_MIDI_FONT_NOLIMITS		BASS_MIDI_FONT_NOSBLIMITS
11#define BASS_MIDI_FONT_MINFX		0x1000000
12#define BASS_MIDI_FONT_SBLIMITS		0x2000000
13#define BASS_MIDI_FONT_STEREO		0x4000000  

BassMidiFontInitFlags is a bit field which means you can combine all of the above flag values by logical OR operators (which in this case actually equivalent to an arithmetical addition) to get an overall value that you can set.
E.g. to test the BASS_MIDI_FONT_SBLIMITS flag together with the BASS_MIDI_FONT_LINATTMOD flag you can simply add them. That is:
0x100000 + 0x2000000 = 0x2100000 (34603008 in decimal).
I recommend to test the BASS_MIDI_FONT_SBLIMITS flag first since it changed recently (the default was the opposite).

2.

And also, there is this drum-chorus-prohibition facade I read from that discussion on Un4seen. I tried my best to ignore that difference until I played some old karaoke midi files.
In those tracks, every single channel including drums was set at a high chorus level.

I have already built in a workaround to circumvent this 'chorus on drum channels is always disabled in GS mode' limitation into FSMP.
To activate the workaround you should select the 'No SysEx' reset mode option instead of GS and then press the 'Reset' button. Then even in case of GS files you can adjust the Chorus level on drum channels.

Falcosoft wrote on Yesterday, 12:22:

Hi, Unfortunately I cannot help with such issues. You should tell such problems to Ian at https://www.un4seen.com/ (forum sectio […]
Show full quote

Hi,
Unfortunately I cannot help with such issues. You should tell such problems to Ian at https://www.un4seen.com/ (forum section).
He is usually very helpful, but of course his and our vision of Bassmidi regarding compatibility sometimes differ and of course usually his version wins.

@Edit:

And also, there is this drum-chorus-prohibition facade I read from that discussion on Un4seen. I tried my best to ignore that difference until I played some old karaoke midi files.
In those tracks, every single channel including drums was set at a high chorus level.

I have already built in a workaround to circumvent this 'chorus on drum channels is always disabled in GS mode' limitation into FSMP.
To activate the workaround you should select the 'No SysEx' reset mode option instead of GS and then press the 'Reset' button. Then even in case of GS files you can adjust the Chorus level on drum channels.

A bit of a shameless self promotion, but I'm working on significantly extending GS support in my synth. And I noticed that real GS devices indeed allow you to add chorus to drum channels:
By default, it is disabled. However, you can modify each drum key (either via NRPN or SysEx) to have a chorus send value. For example after reset, all 128 drum keys are set to chorus send 0. Setting chorus send to 127 will make this key use the CC#93 value of chorus. 64 is half of that, etc.
Bassmidi already supports drum params to some extent (like tuning, though NRPN only), so I think asking Ian for extending that support is the best solution: Chorus on GS drums and it's GS compliant!
What do you think?

Spesek wrote on Yesterday, 15:46:

A bit of a shameless self promotion, but I'm working on significantly extending GS support in my synth. And I noticed that real […]
Show full quote

Falcosoft wrote on Yesterday, 12:22:

Hi, Unfortunately I cannot help with such issues. You should tell such problems to Ian at https://www.un4seen.com/ (forum sectio […]
Show full quote

Hi,
Unfortunately I cannot help with such issues. You should tell such problems to Ian at https://www.un4seen.com/ (forum section).
He is usually very helpful, but of course his and our vision of Bassmidi regarding compatibility sometimes differ and of course usually his version wins.

@Edit:

And also, there is this drum-chorus-prohibition facade I read from that discussion on Un4seen. I tried my best to ignore that difference until I played some old karaoke midi files.
In those tracks, every single channel including drums was set at a high chorus level.

I have already built in a workaround to circumvent this 'chorus on drum channels is always disabled in GS mode' limitation into FSMP.
To activate the workaround you should select the 'No SysEx' reset mode option instead of GS and then press the 'Reset' button. Then even in case of GS files you can adjust the Chorus level on drum channels.

A bit of a shameless self promotion, but I'm working on significantly extending GS support in my synth. And I noticed that real GS devices indeed allow you to add chorus to drum channels:
By default, it is disabled. However, you can modify each drum key (either via NRPN or SysEx) to have a chorus send value. For example after reset, all 128 drum keys are set to chorus send 0. Setting chorus send to 127 will make this key use the CC#93 value of chorus. 64 is half of that, etc.
Bassmidi already supports drum params to some extent (like tuning, though NRPN only), so I think asking Ian for extending that support is the best solution: Chorus on GS drums and it's GS compliant!
What do you think?

Hi,
If I remember correctly Bassmidi already supports setting individual drum key's chorus send level. The problem is not this, but the default state. For many years Bassmidi by default was compatible with the way Creative's SB HW SF2 synths handled chorus on drum channels (that is no restriction after a GS reset). Then suddenly it changed to be compatible with Roland GS hardware (and thus incompatible with SB HW SF2 synths).

You can restore the old behavior by applying new flags (and FSMP applies this flag when the 'No SysEx' reset option is enabled) but for me such changes would be more acceptable if they were intruduced as opt-in instead of opt-out...