Yeah, looks really impressive, thank you.

Mudlord (one of the original developers of VST Midi Driver) commented on my fork's Github page revealing some interesting details about what happened to the original driver (from his point of view):
https://github.com/Falcosoft/vstdriver/issues/3

Well, better late than never. I doubt you still needed it at this point, though.

New version 2.3.0 has been released:
https://github.com/Falcosoft/vstdriver/releases/tag/v2.3.0
Virustotal:
https://www.virustotal.com/gui/file/201462a4e … ac015/detection

1. Added Unload VSTi plugin button to unload/remove plugins from list.

2. Plugin list dropdown is extended to show full paths.

3. Improved handling of plugins that do not report vendor/product info (e.g. YAMAHA S-YXG2006LE)

4. Added saving/loading and sending last used SysEx reset at start. This can prevent some plugins to always start in non-optimal default state.
(e.g. YAMAHA S-YXG2006LE always starts in XG mode and in XG mode drums can be a problem when GS files are played).

5. All plugins are kept loaded the same way as SC-VA has been so far. Added KeepDriverLoaded option to registry so you can disable it and revert back to previous behavior. KeepDriverLoaded on means that once the driver is loaded by a Midi client the driver and the system tray menu as well as the currently loade plugin stay loaded until the client is closed. The on state can be useful in case of some Midi/Multimedia players like Van Basco and WMP that always close Midi Out ports when playback is stopped and/or focus is lost (and thus the driver's tray menu also disappears). The off state is somewhat more compatible and conform better to specification.

6. Fixed vsthost's SysEx related memory leak (inherited from previous forks).

7. Fixed rare problem of hanging Midi stream when ASIO/WASAPI output is used.

8. Many other under the hood optimizations and fixes.

This version still works with Windows NT4 SP6/2000/XP/Vista/7/8/10/11 but on NT4 ASIO output mode is no longer available (new version of BassAsio requires SSE support).

Wow, the improvements and new features just keep coming. Thank you! 😀

I'm using it right now and everything is working wonderfully with the MIDI Player.

Thanks for the feedback guys!

The only real hiccup I've had is that FSMP went unresponsive and locked up after I had paused playback and went back to it some time later, which made me have to terminate it and restart it, the first time I used the new driver. Apart from that, there was one other quirk where FSMP's output setting switched to Bass MIDI/SoundFont after I had the player paused for a bit and I had to switch the setting back to the VST MIDI Synth in the output setting selection. I'll see what happens if I try to make it happen a few times, so I don't consider it anything beyond a one-off incident right now and I'm not seeing any signs of instability or erroneous sound/performance that indicates that there is an ongoing issue.

Great update, thanks!

Falcosoft wrote on 2024-02-21, 13:48:

5. All plugins are kept loaded the same way as SC-VA has been so far. Added KeepDriverLoaded option to registry so you can disable it and revert back to previous behavior. KeepDriverLoaded on means that once the driver is loaded by a Midi client the driver and the system tray menu as well as the currently loade plugin stay loaded until the client is closed. The on state can be useful in case of some Midi/Multimedia players like Van Basco and WMP that always close Midi Out ports when playback is stopped and/or focus is lost (and thus the driver's tray menu also disappears). The off state is somewhat more compatible and conform better to specification.

I think that this new behavior should be disabled by default, and the setting could be visible in the configuration program.

VEG wrote on 2024-02-23, 17:24:

Great update, thanks!

Falcosoft wrote on 2024-02-21, 13:48:

5. All plugins are kept loaded the same way as SC-VA has been so far. Added KeepDriverLoaded option to registry so you can disable it and revert back to previous behavior. KeepDriverLoaded on means that once the driver is loaded by a Midi client the driver and the system tray menu as well as the currently loade plugin stay loaded until the client is closed. The on state can be useful in case of some Midi/Multimedia players like Van Basco and WMP that always close Midi Out ports when playback is stopped and/or focus is lost (and thus the driver's tray menu also disappears). The off state is somewhat more compatible and conform better to specification.

I think that this new behavior should be disabled by default, and the setting could be visible in the configuration program.

Have you experienced any problems with this new default?
I have already got complains that the tray menu disappears when you stop playpack in WMP and VanBasco.
Also this bahavior was active in case of SC-VA previously that resulted in inconsistent behavior (and in case of SC-VA the old default is practically not usable with VanBasco/WMP). Now the bahavior is consistent/plugin independent. This new bahavior also results in faster response even in case of lighter plugins.
Just for your interest: The audio engine is released. Only the vst host is kept alive. So you can use any other(soft) synths even when exclusive mode ASIO/WASAPI is set as output for the driver.
Consequently the audio sample transfer between the driver and the host is also stopped so when no port is active there is no processor usage at all.

Ps: I would gladly hear the opinion of other users as well on this subject.

In next version there will be a new tab for "Advanced Settings". Here you can set all the settings that could be set only through registry so far (including the KeepDriverLoaded option).
But since I have not got any convincing argument so far why the old behavior should be the default I think KeepDriverLoaded On stays the default.

If enabled, vsthost would stay loaded even when it's actually not used 99.9% of time. Yeah, I know that it does not consume a lot of resources and modern computers have loads of RAM, but it still does not feel right for a default.

Maybe vsthost could stay loaded for limited (configurable) amount of time after ports are closed? So it could unload itself if it's idle for e.g. 10 seconds.

Personally, I use the driver only for gaming. Actually, for me this on-demand loading was/is quite convenient. If you ask me, having it loaded all the time should NOT be the default.

VEG wrote on 2024-02-28, 18:09:

If enabled, vsthost would stay loaded even when it's actually not used 99.9% of time. Yeah, I know that it does not consume a lot of resources and modern computers have loads of RAM, but it still does not feel right for a default.

Trelokk wrote on 2024-02-28, 21:50:

... If you ask me, having it loaded all the time should NOT be the default.

I feel there is a bit of misunderstanding here. VST Midi driver (including vsthost) is NOT global and never was. It is opened per client and each driver instance is associated to its client. It is still true that if the client that opened the driver is closed then the driver and vsthost instances are closed (this is true for both old and new behavior)
So vsthost does not stay loaded when it is not used by anything. This new behavior only altered what happens when the client that opened VST Midi driver stays open but releases the port(s). This happens e.g. when playback in WMP and VanBasco is stopped. Then these players simply close the opened Midi port(s) and when the next song is played then they re-open the port(s). With the old behavior in case of such plugins as SC-VA this means that you have to wait 5-10 seconds between tracks for the plugin to reload.
When the Midi software that opened the port(s) is closed then VST Midi driver is also closed even with this new behavior (KeepDriverLoaded option On). So it is not the case that vsthost stays opened "when it's actually not used 99.9% of time".
I hope I can make this clearer than before.

@Edit
I have made a demonstration video about the differences of KeepDriverLoaded On/Off states:
https://youtu.be/2SbJDnNrP0g

Oh, this way it looks much better. Thank you for the explanation.

AFAIR, Windows 2000 could play MIDI in explorer's sidebar preview (or was it Windows 98?). Since explorer.exe never closes, I guess the vsthost would continue to run forever. So an idle timeout option still could be "rarely useful".

But it's good as is already anyway.

If it's like that, I guess I am also ok with it. Main thing is it's not a continuous background service. I doubt anyone would be using MIDI excessively enough these days to justify that.

VEG wrote on 2024-02-29, 06:27:

Oh, this way it looks much better. Thank you for the explanation.

AFAIR, Windows 2000 could play MIDI in explorer's sidebar preview (or was it Windows 98?). Since explorer.exe never closes, I guess the vsthost would continue to run forever. So an idle timeout option still could be "rarely useful".

But it's good as is already anyway.

Thanks for this information. I have added explorer.exe as an exception so the driver will always be unloaded when explorer is the client. But actually even with the current version and KeepDriverLoaded option on (when vsthost associated with Windows 2000's explorer.exe stays open) nothing prevents other Midi clients to use the driver. Maybe it has not been clear so far either but you can use as many Midi clients at once with VST Midi driver as you want. Each Midi client can open its own instance of the driver (privided the driver is not set to use exclusive mode ASIO/WASAPI audio output). In this respect VST Midi driver is fully multi-client and does not have such restrictions as traditional Midi Out ports/drivers.

Is there a way to configure the SYXG2006LE through the driver? I know it doesn't have a GUI like the XG50, but stuff like Polyphony should still be accessible somehow, right?

Trelokk wrote on 2024-03-01, 16:34:

Is there a way to configure the SYXG2006LE through the driver? I know it doesn't have a GUI like the XG50, but stuff like Polyphony should still be accessible somehow, right?

Unfortunately no. This plugin does not have any configurable parameters at all so this is not VST driver specific problem. Moreover even if the plugin could be configured any way the configuration could not be preserved since the plugin cannot save any of its data (requesting data for saving results in a completely empty data block).
FSMP has user interface even for editorless plugins but in case of S-YXG2006LE you get this:

We might have a problem. With your latest version, MIDI music suddenly sounds wrong. To be more precise: Wrong instruments are played. I tried with the 2006LE first and thought it's the plugin, so I switched back to the XG50. But it was the same thing.

It didn't happen all the time, but for sure with D_E1M8 of Doom. The song is suddenly brutally butchered, not recognizable at all any more. It wasn't like this with the previous driver version (2.2.0). Tested with Woof! and GZDoom.

UPDATE:
OK, now I am confused. It also happens with v2.2.0 now. What the hell is going on all of a sudden?