Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

RetroGamer4Ever wrote on 2026-01-31, 05:42:

Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Falcosoft wrote on 2026-01-31, 06:52:

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and fut […]
Show full quote

RetroGamer4Ever wrote on 2026-01-31, 05:42:

Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Falcosoft wrote on 2026-01-31, 06:52:

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and fut […]
Show full quote

RetroGamer4Ever wrote on 2026-01-31, 05:42:

Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Backwards and forwards compatibility and significant improvements for using the massive amount of older MIDI 1.0 hardware and software tech already in play took up most of the development time and resources, so it's the biggest part of what's been done. That comes straight from the guy who led the development efforts. 2.0 products are a small amount of what's out there, being used by industry pros and others, so it's all about bringing the past forward, with a path to the future.

RetroGamer4Ever wrote on 2026-01-31, 07:07:

Falcosoft wrote on 2026-01-31, 06:52:

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and fut […]
Show full quote

RetroGamer4Ever wrote on 2026-01-31, 05:42:

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Backwards and forwards compatibility and significant improvements for using the massive amount of older MIDI 1.0 hardware and software tech already in play took up most of the development time and resources, so it's the biggest part of what's been done. That comes straight from the guy who led the development efforts. 2.0 products are a small amount of what's out there, being used by industry pros and others, so it's all about bringing the past forward, with a path to the future.

Let's see what will be your opinion when you have already checked and tried it...
BTW, even the post at Steinberg that Kappa971 linked mostly talks about WinRT and Midi 2.0 devices support in Cubase besides the multi-client capability.

Some quotes from the new MIDI stack's documentation:

The new driver supports both MIDI 2.0 devices as well as MIDI 1.0 devices. By default, we do not currently move existing MIDI 1.0 devices to the new driver because we need to be sure of compatibility first.

The service, transports, and plumbing are all there for MIDI 2.0, however apps will need to use the Windows MIDI Services App SDK to interface with it. The existing WinMM and WinRT MIDI 1.0 APIs cannot support the newer constructs, message scheduling, creating virtual device apps, etc. All of those features are in the new SDK.

That is, they try to preserve compatibility mostly by not touching and not interfering with Midi 1 hardware/drivers/APIs/apps.
This does not sound like that the focus and most of the developments are related to old hardware/software and backward compatibility.

Regarding ARM laptops and the new MIDI 2.0 services:
According to the description the new services will not affect how kernel drivers work on ARM. Old hardware that needs kernel drivers but only has native x86/x64 drivers will not work even with the new MIDI stack on ARM Windows.
So backward compatibility roughly starts with the USB era and does not include the most relevant hardware for old games like the classic Roland and Yamaha gears.
E.g. If you want to use Roland/Yamaha serial port drivers your best option remains an x86 32-bit Windows.

RetroGamer4Ever wrote on 2026-01-31, 07:07:

...
Backwards and forwards compatibility and significant improvements for using the massive amount of older MIDI 1.0 hardware and software tech already in play took up most of the development time and resources,

BTW, I have a very bad feeling because of this:
https://devblogs.microsoft.com/windows-music- … i-driver-limit/

It says:

Midisrv now handles all enumeration of MIDI-capable devices, and uses a completely different way to find the connected Kernel Streaming drivers in the system, including our own MIDI 1.0 and MIDI 2.0 class drivers, as well as third-party KS MIDI drivers. Anything which is not a KS driver, must be implemented in another way.

As well as:

We also recognize that customers may install third-party drivers just due to preference or habit, and that a subset of those drivers continue to make updates to the Drivers32 entries. Therefore, the Windows MIDI Services App SDK includes a tool midifixreg.exe which will reset the registry to the Windows MIDI Services default setup with just wdmaud.drv and wdmaud2.drv. Your devices will continue to work regardless of the KS driver they use because once wdmaud2.drv is loaded, all enumeration happens in the service.

The problems is that all of the user mode soft synth MIDI drivers that retro enthusiasts use are not KS (kernel streaming) drivers but use the old installable multimedia driver architecture (they are simple user mode dlls, there is no accompanying drv/sys device driver component) and rely on the Drivers32 entries in the registry.
This includes the Munt driver, Nuked OPL3 emulation drivers, Coolsoft Virtual Midi Synth as well as VST MIDI driver.
I hope I'm not right but according to the description these drivers will all belong to the 'must be implemented in another way' camp since they have no Kernel Streaming driver component and thus the new Midi service will not enumerate them..

From the same dev blog entry: Anything which is not a KS driver, must be implemented in another way. For example, our built-in loopback endpoints are handled completely in service code, as is the Network MIDI 2.0 preview implementation, and the Virtual Device implementation. We`ve built an infrastructure using classic COM to make it easier to write new transports without having to create kernel drivers, or mess with these registry entries.

Surely, a little elbow grease and tinkering will get everything working, if it doesn't work. They are only starting the initial roll-out of the general release and many things will be changed by the end of the year, as more testing of hardware and drivers are being done. I'll see what is what when the update hits one of my Win 11 laptops.

RetroGamer4Ever wrote on 2026-01-31, 15:29:

From the same dev blog entry: Anything which is not a KS driver, must be implemented in another way. For example, our built-in loopback endpoints are handled completely in service code, as is the Network MIDI 2.0 preview implementation, and the Virtual Device implementation. We`ve built an infrastructure using classic COM to make it easier to write new transports without having to create kernel drivers, or mess with these registry entries.

Surely, a little elbow grease and tinkering will get everything working, if it doesn't work. They are only starting the initial roll-out of the general release and many things will be changed by the end of the year, as more testing of hardware and drivers are being done. I'll see what is what when the update hits one of my Win 11 laptops.

Yep, we have to wait a little and then we will see. I still hope that at least there will be a compatibility setting to make the old driver architecture work as it worked so far. To tell you the truth C/C++ COM programming is not much fun and most likely the required modifications will make the code Win 11+ specific. So either Win 11 specific new forks or in place dynamic code alternations would be required. Neither is ideal considering that e.g. VST MIDI driver's current version can be the same from WinNT4 to Win 11.

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?

My ideal scaling option:
slider that scales in decimal increments,
1 - 1.25 - 1.5 -2 etc.

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

My ideal scaling option:
slider that scales in decimal increments,
1 - 1.25 - 1.5 -2 etc.

Hi,
1. Unfortunately such scaling is not possible currently. The UI is not a bitmap but consists of standard Win32 controls.
2. I do not think that area has a place for another icon, but there can be a compatibility option added to always minimize to tray.

Hi Falco,
I have a quick question regarding FSMP.
I made a quick node script for my synth to act as a realtime MIDI synth and I use FSMP to play back MIDI files for testing.
However I noticed that it seems to send some strange sysExes when playing multi-port MIDI files:

1// Note: The 7F exclusive is stripped from the log messages
2Unknown manufacturer: F5 02 00 F7 
3Unknown manufacturer: F5 01 00 F7 
4Unknown manufacturer: F5 02 00 F7 
5Unknown manufacturer: F5 01 00 F7 

F5 is not a manufacturer ID. According to MMA it's "Reserved for Other Uses".
My best guess is that this sysEx tells the synth "process the following messages on port 1" or similar. Am I correct?

PS:
Since FSMP in collapsed mode already looks similar to a sound canvas (for example the screenshot by mashakos above), would it be possible to add support for GS/XG display bitmap messages? Especially since SYXG50 and SC-VA lack those.
It could be an opt-in feature, and when FSMP processes such message, the display could temporarily show the bitmap image.

For testing I recommend MIDIs by Kr.Palto47 as they have some really cool animations:
https://drive.google.com/drive/folders/1Ed4mX … n3hMpAVPycrn3Hg

And my code for decoding them, might be helpful to you:
https://github.com/spessasus/SpessaSynth/blob … .ts#L1105-L1146

What do you think?

Spesek wrote on 2026-02-07, 21:51:

Hi Falco, I have a quick question regarding FSMP. I made a quick node script for my synth to act as a realtime MIDI synth and I […]
Show full quote

Hi Falco,
I have a quick question regarding FSMP.
I made a quick node script for my synth to act as a realtime MIDI synth and I use FSMP to play back MIDI files for testing.
However I noticed that it seems to send some strange sysExes when playing multi-port MIDI files:

Copy code to clipboard

1// Note: The 7F exclusive is stripped from the log messages
2Unknown manufacturer: F5 02 00 F7 
3Unknown manufacturer: F5 01 00 F7 
4Unknown manufacturer: F5 02 00 F7 
5Unknown manufacturer: F5 01 00 F7 

F5 is not a manufacturer ID. According to MMA it's "Reserved for Other Uses".
My best guess is that this sysEx tells the synth "process the following messages on port 1" or similar. Am I correct?

PS:
Since FSMP in collapsed mode already looks similar to a sound canvas (for example the screenshot by mashakos above), would it be possible to add support for GS/XG display bitmap messages? Especially since SYXG50 and SC-VA lack those.
It could be an opt-in feature, and when FSMP processes such message, the display could temporarily show the bitmap image.

For testing I recommend MIDIs by Kr.Palto47 as they have some really cool animations:
https://drive.google.com/drive/folders/1Ed4mX … n3hMpAVPycrn3Hg

And my code for decoding them, might be helpful to you:
https://github.com/spessasus/SpessaSynth/blob … .ts#L1105-L1146

What do you think?

Hi,
1. These are NOT SysEx messages. The last 0xF7 byte must be appended by your script. 'F7' at the end is not sent by FSMP for sure.
FSMP simply use the infrastructure provided by WinMM to send '0xF5' port select real time messages with the help of midiOutLongMsg() function that is usually used to send SysEx (long) messages but not exclusively.
Actually you can send any kind of short messages (even multiple ones at once) with the help of midiOutLongMsg() function. This has always been supported by WinMM.
More info about the '0xF5' port select message:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
Unfortunately some synths that support this message only recognize the form sent by midiOutLongMsg() and others only recognize the form sent by midiOutShortMsg(). So FSMP sends both if ' Main menu -> Compatibility Settings -> Send Port Select Midi events (f5 xx) is enabled.

2. FSMP already supports the Roland and Yamaha specific text based LCD display messages in its Midi Text/Lyrics window. Supporting graphics would require a completely different infrastructure and considering the relatively few Midi files that actually contain such messages it has not been implemented so far.
Maybe later this will be added, but I cannot promise for sure.

Falcosoft wrote on 2026-02-07, 22:23:

Hi, 1. These are NOT SysEx messages. The last 0xF7 byte must be appended by your script. 'F7' at the end is not sent by FSMP for […]
Show full quote

Spesek wrote on 2026-02-07, 21:51:

Hi Falco, I have a quick question regarding FSMP. I made a quick node script for my synth to act as a realtime MIDI synth and I […]
Show full quote

Hi Falco,
I have a quick question regarding FSMP.
I made a quick node script for my synth to act as a realtime MIDI synth and I use FSMP to play back MIDI files for testing.
However I noticed that it seems to send some strange sysExes when playing multi-port MIDI files:

Copy code to clipboard

1// Note: The 7F exclusive is stripped from the log messages
2Unknown manufacturer: F5 02 00 F7 
3Unknown manufacturer: F5 01 00 F7 
4Unknown manufacturer: F5 02 00 F7 
5Unknown manufacturer: F5 01 00 F7 

F5 is not a manufacturer ID. According to MMA it's "Reserved for Other Uses".
My best guess is that this sysEx tells the synth "process the following messages on port 1" or similar. Am I correct?

PS:
Since FSMP in collapsed mode already looks similar to a sound canvas (for example the screenshot by mashakos above), would it be possible to add support for GS/XG display bitmap messages? Especially since SYXG50 and SC-VA lack those.
It could be an opt-in feature, and when FSMP processes such message, the display could temporarily show the bitmap image.

For testing I recommend MIDIs by Kr.Palto47 as they have some really cool animations:
https://drive.google.com/drive/folders/1Ed4mX … n3hMpAVPycrn3Hg

And my code for decoding them, might be helpful to you:
https://github.com/spessasus/SpessaSynth/blob … .ts#L1105-L1146

What do you think?

Hi,
1. These are NOT SysEx messages. The last 0xF7 byte must be appended by your script. 'F7' at the end is not sent by FSMP for sure.
FSMP simply use the infrastructure provided by WinMM to send '0xF5' port select real time messages with the help of midiOutLongMsg() function that is usually used to send SysEx (long) messages but not exclusively.
Actually you can send any kind of short messages (even multiple ones at once) with the help of midiOutLongMsg() function. This has always been supported by WinMM.
More info about the '0xF5' port select message:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
Unfortunately some synths that support this message only recognize the form sent by midiOutLongMsg() and others only recognize the form sent by midiOutShortMsg(). So FSMP sends both if ' Main menu -> Compatibility Settings -> Send Port Select Midi events (f5 xx) is enabled.

2. FSMP already supports the Roland and Yamaha specific text based LCD display messages in its Midi Text/Lyrics window. Supporting graphics would require a completely different infrastructure and considering the relatively few Midi files that actually contain such messages it has not been implemented so far.
Maybe later this will be added, but I cannot promise for sure.

Hi Falco,
Thanks for the quick reply!

1. That's interesting! I can assure you that these messages are not appended by spessasynth either.
At first I thought that they were appended by node-midi, the NPM package I was using which is a wrapper for the C++ RtMidi library,
but then I checked and it happens in browsers too. So maybe it's appended by wine? I checked on a windows computer and spessasynth doesn't report it.
Which is honestly a shame, because I added support for it and multi-port files work great with it!
Would there be any harm in actually making FSMP send it as a sysEx? F5 is not used by any manufacturer so its safe to use for such a niche use-case I believe.

2. I knew about the text messages, but I noticed it lacks support for the graphical ones. Maybe a temporary solution could be a simple text-based diplay in the lyric window?
For example "***" would be a lit pixel and three spaces would be an empty one. (Because in GS/XG pixels are wide, not tall like fonts)

1************************************************
2***                           ******         ***
3***   ***   ***************   ******   ***   ***
4***         ***         ***   ******         ***
5***   ***   ***         ***   ******   ***   ***
6***   ***   ***************   ******   ***   ***
7***                           ******         ***
8************************************************
9***                                          ***
10************      ***   ******************   ***
11***                                          ***
12************************************************
13   *********                        *********   

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?

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

Hi Falco, Thanks for the quick reply! […]
Show full quote

Falcosoft wrote on 2026-02-07, 22:23:

Hi, 1. These are NOT SysEx messages. The last 0xF7 byte must be appended by your script. 'F7' at the end is not sent by FSMP for […]
Show full quote

Spesek wrote on 2026-02-07, 21:51:

Hi Falco, I have a quick question regarding FSMP. I made a quick node script for my synth to act as a realtime MIDI synth and I […]
Show full quote

Hi Falco,
I have a quick question regarding FSMP.
I made a quick node script for my synth to act as a realtime MIDI synth and I use FSMP to play back MIDI files for testing.
However I noticed that it seems to send some strange sysExes when playing multi-port MIDI files:

Copy code to clipboard

1// Note: The 7F exclusive is stripped from the log messages
2Unknown manufacturer: F5 02 00 F7 
3Unknown manufacturer: F5 01 00 F7 
4Unknown manufacturer: F5 02 00 F7 
5Unknown manufacturer: F5 01 00 F7 

F5 is not a manufacturer ID. According to MMA it's "Reserved for Other Uses".
My best guess is that this sysEx tells the synth "process the following messages on port 1" or similar. Am I correct?

PS:
Since FSMP in collapsed mode already looks similar to a sound canvas (for example the screenshot by mashakos above), would it be possible to add support for GS/XG display bitmap messages? Especially since SYXG50 and SC-VA lack those.
It could be an opt-in feature, and when FSMP processes such message, the display could temporarily show the bitmap image.

For testing I recommend MIDIs by Kr.Palto47 as they have some really cool animations:
https://drive.google.com/drive/folders/1Ed4mX … n3hMpAVPycrn3Hg

And my code for decoding them, might be helpful to you:
https://github.com/spessasus/SpessaSynth/blob … .ts#L1105-L1146

What do you think?

Hi,
1. These are NOT SysEx messages. The last 0xF7 byte must be appended by your script. 'F7' at the end is not sent by FSMP for sure.
FSMP simply use the infrastructure provided by WinMM to send '0xF5' port select real time messages with the help of midiOutLongMsg() function that is usually used to send SysEx (long) messages but not exclusively.
Actually you can send any kind of short messages (even multiple ones at once) with the help of midiOutLongMsg() function. This has always been supported by WinMM.
More info about the '0xF5' port select message:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
Unfortunately some synths that support this message only recognize the form sent by midiOutLongMsg() and others only recognize the form sent by midiOutShortMsg(). So FSMP sends both if ' Main menu -> Compatibility Settings -> Send Port Select Midi events (f5 xx) is enabled.

2. FSMP already supports the Roland and Yamaha specific text based LCD display messages in its Midi Text/Lyrics window. Supporting graphics would require a completely different infrastructure and considering the relatively few Midi files that actually contain such messages it has not been implemented so far.
Maybe later this will be added, but I cannot promise for sure.

Hi Falco,
Thanks for the quick reply!

1. That's interesting! I can assure you that these messages are not appended by spessasynth either.
At first I thought that they were appended by node-midi, the NPM package I was using which is a wrapper for the C++ RtMidi library,
but then I checked and it happens in browsers too. So maybe it's appended by wine? I checked on a windows computer and spessasynth doesn't report it.
Which is honestly a shame, because I added support for it and multi-port files work great with it!
Would there be any harm in actually making FSMP send it as a sysEx? F5 is not used by any manufacturer so its safe to use for such a niche use-case I believe.

2. I knew about the text messages, but I noticed it lacks support for the graphical ones. Maybe a temporary solution could be a simple text-based diplay in the lyric window?
For example "***" would be a lit pixel and three spaces would be an empty one. (Because in GS/XG pixels are wide, not tall like fonts)

Copy code to clipboard

1************************************************
2***                           ******         ***
3***   ***   ***************   ******   ***   ***
4***         ***         ***   ******         ***
5***   ***   ***         ***   ******   ***   ***
6***   ***   ***************   ******   ***   ***
7***                           ******         ***
8************************************************
9***                                          ***
10************      ***   ******************   ***
11***                                          ***
12************************************************
13   *********                        *********   

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?

Hi,
1. As you know in the Midi 1.0 protocol the 'marker' of a SysEx message is the status/1st byte. There is only 1 such byte at the protocol level, namely '0xF0'. In Midi files you can also find so called SysEx Continuation messages which have '0xF7' 1st byte but a Midi player has to remove it before sending such messages since they are not defined at the protocol level.
In case of port select real time messages the '0xF5' is really the status/1st byte! These messages cannot be sent as valid SysEx since the synths that support them would not recognize them.
I do not know what component in your tested Midi software stack designated the '0xF5' part as a 'manufacturer byte' but this is simply wrong considering the syntax of these messages.
A manufacturer byte is only valid inside a real SysEx message like 'F0 xx 00 00 F7' where xx can be considered to be the manufacturer byte.
But '0xF5' cannot be such a byte since according to specification the valid range of data bytes is 0x00-0x7F. So 0xF5 is only valid as a status/1st byte. It cannot be a data byte inside a SysEx message.
But of course we can agree on a custom valid SysEx message like 'F0 66 75 nn F7' where nn would be the port number and use it as a custom port select message.
F0 66... SysEx messages have been used by FSMP for years.

0x66 - Manufacturer ID ASCII 'f'. It seems it's safe to use this as newly issued official ID's are 3 bytes long and start with 0x00, and the used 1 byte ID's are in the range 0x40 - 0x5F.

Re: Falcosoft Soundfont Midi Player

BTW, your problem on Windows is most likely related to virtual Midi cables. None of them I tested supports transferring 0xF5 messages.

2. OK, I will think about this option.

Thank you for linking the conversation. Lately, I found out that I can swap just the BASS/BASSMIDI DLLs while keeping the same player version.

So tonight, while tweaking a filter-envelope-related modulator that turned out not to work with the original BASS/BASSMIDI combo present in the good old FSMP 5.8 (x86), but does work with the newer ones, I tried several combinations of newer DLLs. I ended up using both the fixed bassmidi and bassmidi_nosse DLLs. Even then, I somehow still missed applying UserFX to channel 10 via CC#94.

I do notice the kicks being clear and dry, particularly on channel 10 under GS/GM modes. However, overall, GM/GS drumkits seem unresponsive to whatever VST plugin I plug into CC#94. XG kits work fine though.

I’m not sure whether I’m tripping, missing something obvious, or overlooking some deeper technical detail. For the time being, I double-checked that the DLLs were downloaded from the links in that conversation.

Here’s me testing the new BASSMIDI.dll:
https://www.youtube.com/watch?v=dnpW4MlhmGA

(Sorry about repeating the same things over and over and for any rambling. I don’t mean to be rude or anything.)

Update: I downloaded the latest x86 version of Falcosoft player, and all of my aforementioned drum-sfx problems were solved. Thank you very much!

ColomboGMGS2 wrote on Yesterday, 15:58:

Update: I downloaded the latest x86 version of Falcosoft player, and all of my aforementioned drum-sfx problems were solved. Thank you very much!

You're welcome! It was a long time ago so I had to check this problem again. But yes, as can be read in the conversation between me and Ian a new flag was introduced in Bassmidi ( BASS_MIDI_NODRUMPARAMUSER) so it required code changes also in FSMP:
https://www.un4seen.com/forum/?topic=20320.ms … 42234#msg142234

It seems FSMP version 6.3 was the first one that used the new flag and so fixed this regression:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

I guess I was stuck with an old bassmidi library for too long. Couldn't quite make up my mind to say goodbye to the drum chorus effect, even though I am almost always an XG chorus preset (Chorus 1 (XG)) rather than a GS one.

*I am almost always USING an XG chorus preset