Just saw the update. Good move with the optional certificate. That will hopefully help to improve the situation. I will certainly install it. Your stuff has kept my MIDI nostalgia going which deserves to be rewarded.

Hi,
Since v1.7 was detected falsely as malicious by McAfee currently more vendors detect it as problematic than at release time...
Mainly that's why I release v1.7.1.
https://github.com/Falcosoft/vstdriver/releases/tag/1.7.1
Virustotal result (2 false positives but there are no major AV vendors among them) :
https://www.virustotal.com/gui/file/795fd03e7 … 385b9b461fa8bc8
The original upload is already 3 days old so I hope this result will not change for the worse. I also think that the result will not be any better than this so please do not click 'Reanalyze' just for fun 😀.

New features:
1. Re-enable MIDI port selection tab if Coolsoft MIDI Mapper is detected on Win8+.
If Coolsoft Midi Mapper is installed VST Midi driver can use it to set default Midi Out port on Win8/10/11 just like on Win Vista/7. This feature adds nothing that Coolsoft Midi Mapper cannot do. It's simply for convenience so you can save one shortcut on your desktop.

2. Actually this release is rather an experiment with self-signed certificates to prevent false positive detection from several AV engines that plagued previous releases. Besides the self-signed installer you can also download a Falcosoft certificate that you can install into your Trusted Root Certificates store (if you trust me). This way this release and future releases can be checked by you and Windows.

Bye.

I'm testing the Roland Hyper Canvas GM2 VST with the 1.7 driver and it sounds absolutely amazing with GM files, even better than the XG VSTI and the GM2-capable VSC-MP1.

Is that one even portable? AFAIK it requires a few registry entries to work, or is there a version I don't know about? How did you get it working in general?

Trelokk wrote on 2023-08-17, 22:23:

Is that one even portable? AFAIK it requires a few registry entries to work, or is there a version I don't know about? How did you get it working in general?

I don't do anything except load the VST dll into the VST host driver, config the VST manually (settings bug doesn't allow saving), and off I go. I don't think I have ever done anything else with it.

RetroGamer4Ever wrote on 2023-08-17, 22:31:

Trelokk wrote on 2023-08-17, 22:23:

Is that one even portable? AFAIK it requires a few registry entries to work, or is there a version I don't know about? How did you get it working in general?

I don't do anything except load the VST dll into the VST host driver, config the VST manually (settings bug doesn't allow saving), and off I go. I don't think I have ever done anything else with it.

No, it's not portable at all. It requires proper full installation. If you copy only its folder with the VST dll and data file to another PC/OS without installing it properly you will get registry errors and the plugin cannot be loaded.

Another problem with this synth (besides the settings saving problem mentioned above) is that in spite of documented SysEx support in the manual in reality it cannot handle SysEx messages at all.

No working SysEx sounds very odd, but I suppose CC had replaced it by that point. The old 90's era GM files that I test with it sound absolutely wonderful and the effects work great, so I wonder what's going on there. I went digging online and found two completely different user manuals for it. The one from Roland's downloads is very weird and not helpful at all. Then I found another one through the search engines that looks proper and tells you how to use the software.

RetroGamer4Ever wrote on 2023-08-18, 14:22:

No working SysEx sounds very odd, but I suppose CC had replaced it by that point. The old 90's era GM files that I test with it sound absolutely wonderful and the effects work great, so I wonder what's going on there. I went digging online and found two completely different user manuals for it. The one from Roland's downloads is very weird and not helpful at all. Then I found another one through the search engines that looks proper and tells you how to use the software.

I was talking about the Html manual that can be found in the Hyper Canvas VST\HELP folder. It has a section called MIDI Implementation. There you can find the supported SysEx messages.
But after another close look I have noticed the following remark:

The System Exclusive Messages received by the Hyper Canvas are; messages related to mode settings, Universal Realtime System Exclusive messages and Universal Non-realtime System Exclusive messages.
[Note] Reception of system exclusive messages is possible only for DXi.

So it seems the VSTi version does not support SysEx messages. It is hard to understand why.
In case of GM files it's hard to notice this problem since in 99% of cases they do not use any SysEx messages. The default Reverb/Chorus effects should work, and actually work, without any SysEx support. You simply cannot change the effect presets and parameters through Midi SysEx messages. CC# 91 and 93 work to set the amount of the effects.

The biggest problem with non-working SysEx messages is that the synth cannot be switched to GM(1) mode that should set the synth to ignore Bank Select messages. Since GS/XG (and even some GM Midi files) often send Bank Select MSB message before a Program Change message the synth can get an invalid Bank Select message on channels and thus non-working Program Change messages which results in default Piano 1 on affected channels.
You have to manually reset the Synth by pressing the GM2 button on the interface after a Midi file sent invalid Bank MSB to a channel in order future Program Change messages to work.
Or you have to use FSMP's Capital Tone Fallback with selected GM1_GM2.ins.

@Edit:
An example. Play this Midi file first (METBLAS9.mid, it's enough to play the first few seconds). It sets Bank MSB to 1 on channels 3 and 4:

Then play a Midi file that uses channels 3 and 4. A good candidate is Doom2 Map01:
Doom2 Map01 download:
download/file.php?id=170218
You can hear right at the beginning that channels 3 and 4 remain Piano (until you reset the synth).

A little preview for the upcoming v 1.8 of VST Midi driver

Together with FSMP it will be able to play 32-channel Midi files automatically by opening the 2nd port when needed. This feature relies on FSMP's ability to transfer the rarely documented 0xF5 port select Midi messages (supported also by S-YXG50 Win9x and WinXP driver aw well as Dreamblaster X2/X3).
AFAIK this will be the easiest way to play back 32-channel Midi files properly since no explicit 2nd port selection or other configuration steps are needed.

Video about the new feature tested with 5 Konami 32-channel Midi files (rather long, almost 30 minutes):
https://youtu.be/edHM21rWXRg

This keeps getting better and better. I remember the days when I was afraid this driver was dead for good and turn into a historical artifact. Now it's back and more amazing than ever.

I came across a 48-channel XG MIDI file in my collection yesterday. I'm looking forward to being able to hear something exotic like that, someday.

RetroGamer4Ever wrote on 2023-08-24, 11:35:

I came across a 48-channel XG MIDI file in my collection yesterday. I'm looking forward to being able to hear something exotic like that, someday.

Yeah, that would require 3 ports 😀 Since 32+ channel Midi files are so rare as a white crow I do not know if it's worth the effort. If I add more ports eventually I think I will skip 3-port implementation and implement 4 ports right away.
BTW, you can use FSMP + WinMM Multiport VSTi to play such files since it supports 4 ports .

VST Midi driver 1.8.0 has been released:
https://github.com/Falcosoft/vstdriver/releases

This time I had no mood to wait for all stupid AV vendors to whitelist the driver, but I have reported the problem to affected ones:
https://www.virustotal.com/gui/file/084a3ed81 … d22ed91/details

Change log:

1. Added running status support. E.g. Van Basco can be set to send running status compressed Midi stream to Midi Out.

2. Added single port 32 channel support. FSMP can send F5 xx port select Midi messages where xx designates the virtual Midi port.
Together with FSMP now it's possible to play 32-channel Midi files automatically by opening the 2nd port when needed.

3. Added Help/ReadMe file to package. A shortcut to ReadMe is created by the installer.
Ps: The content of ReadMe is almost the same as the new Wiki page of the driver on GitHub:
https://github.com/Falcosoft/vstdriver/wiki

4. Installer is modified to create shortcuts for All Users instead of the current one. So driver related shortcuts are available even if you switch user.

For me it ran through just fine. However, I also installed the certificate beforehand.

I'm loving that this exists. However, I've run into a few issues. For ADLplug and OPNplug VSTs, no synth GUI opens and I get 2 errors in a row that say "Cannot save plugin settings!" and "Cannot load plugin settings!" Opening the VST settings manually with the configuration window and clicking "Configure VSTi..." opens up the GUI for the VST but there are no banks present and you can't load any new ones. So it's stuck on default. And besides this, the one that's loaded with Configure VSTi seems to be a separate instance from the one applications use so it wouldn't be helpful anyway.

There seems to be an issue with a few chip emulators like SN76489 by SocaLabs. It has garbled sound (only with the VST MIDI Driver, nothing else) and seems to be choppy and repeats after a note is sounded. Changing the buffer size to low or high changes the speed at which the repeating choppy sounds are audible, but it doesn't go away. (and the GUI dialogue also doesn't open) It's also a 32-bit VST, but I was using the 32-bit Falcosoft MIDI Player for that one.

What about these VSTs could be causing these problems with the driver? Other VSTs like Roland's Virtual Sound Canvas and Syxg50 work fine.

MusicallyInspired wrote on 2023-09-04, 00:39:

I'm loving that this exists. However, I've run into a few issues. For ADLplug and OPNplug VSTs, no synth GUI opens and I get 2 errors in a row that say "Cannot save plugin settings!" and "Cannot load plugin settings!" Opening the VST settings manually with the configuration window and clicking "Configure VSTi..." opens up the GUI for the VST but there are no banks present and you can't load any new ones. So it's stuck on default. And besides this, the one that's loaded with Configure VSTi seems to be a separate instance from the one applications use so it wouldn't be helpful anyway.

There seems to be an issue with a few chip emulators like SN76489 by SocaLabs. It has garbled sound (only with the VST MIDI Driver, nothing else) and seems to be choppy and repeats after a note is sounded. Changing the buffer size to low or high changes the speed at which the repeating choppy sounds are audible, but it doesn't go away. (and the GUI dialogue also doesn't open) It's also a 32-bit VST, but I was using the 32-bit Falcosoft MIDI Player for that one.

What about these VSTs could be causing these problems with the driver? Other VSTs like Roland's Virtual Sound Canvas and Syxg50 work fine.

Hi,
It seems plugins wiritten with the JUICE framework (all your problematic examples) work differently than other plugins.
1. Without rendering samples the plugins cannot handle saving (effGetChunk calls give back 0 result).
In case of VST MIDI Driver configuration no audio rendering happens and this prevents JUICE plugins to give back configuration data.
With some hacking I could get them to work in the configuration dialog somewhat (faking the rendering of some samples before and after opening the VST Editor). You can change settings but changes (e.g in the case of ADLplug) are reflected only when you close and re-open the VST editor dialog. I recommend that you should close/re-open the VST editor dialog after any modifications. It seems saving /loading settings is working now without problems.
2. It seems JUICE framework plugins are not compatible with the way VST MIDI driver opens VST editors in a separate thread. The effEditOpen calls never return from the plugins leaving the editor thread in a frozen state.
Unfortunately I cannot do much about this so you should disable 'Show VST dialog when port is activated' option in case of JUICE plugins.

3. SN76489 by SocaLabs plugin has mono output that was not a well tested scenario and this caused the audio problems. Now it is working although I do not get the point of using a mono-timbral plugin as a system wide synth.
BTW, handling mono output is working differently compared to FSMP since for a system wide synth it seems more resasonable for me to duplicate the left channel so getting the same signal on both the left and right channels.

If you want to try the fixes here is a temporary build of the driver (v1.8.1):
@Edit: test version removed, look at next post

Okay, I now see the banks and can access them. There's a bit of a trick to it to get the selection to stick that I had to work out, but I got it functioning.

Upon changing to a new bank selection, the new selection doesn't change in the bank name field. It doesn't look like any settings change. And if I try to do anything else in the GUI at that point it will hang and has to be force-closed. Then I have to close the configurator window itself (for the driver) and I get the "cannot save plugin settings!" error. But if I select the bank name and close the GUI window immediately without touching anything else and reopen it I'll find that the new bank indeed has been selected and I can now make other changes in the GUI as needed. When I close the GUI and the VST driver configurator window, I get no errors and the new settings persist when the next MIDI device accesses the VST driver. If you change banks multiple times, however (even with closing and reopening the GUI with the configurator), it will freeze/hang regardless and you have to force close again and start over. So it seems you can only get one bank change in with the close/reopen method before it hangs. Though if you make one change, close the GUI, close the configurator, reopen the configurator, and reopen the GUI it can work that way. Just a few extra steps. It's a bit sketchy but it does work now! If there's a way that can be ironed out that would be fantastic, but if not at least it functions with a bit of quirkiness.

As for the SN76489 VST, I had forgotten that it was mono. That did confuse me as well. There is actually a better plugin called SN-EMU which has LFO functions as well that the SocaLabs one doesn't have (being the simplest implementation of the chip). SN-EMU works a lot better and doesn't have the garbled sound issue (and isn't mono, which would explain it). So I'm happy with that!

The Genny VST seems to no longer be allowed to be configured anymore with the driver so it's unusable (the button is grayed out in the configurator). I assume that's just the way it is and nothing can be done about it, which is fine. We do have OPNplug as well which works as well as ADLplug.

Many thanks for looking into this issue either way!

MusicallyInspired wrote on 2023-09-04, 17:48:

Okay, I now see the banks and can access them. There's a bit of a trick to it to get the selection to stick that I had to work o […]
Show full quote

Okay, I now see the banks and can access them. There's a bit of a trick to it to get the selection to stick that I had to work out, but I got it functioning.

Upon changing to a new bank selection, the new selection doesn't change in the bank name field. It doesn't look like any settings change. And if I try to do anything else in the GUI at that point it will hang and has to be force-closed. Then I have to close the configurator window itself (for the driver) and I get the "cannot save plugin settings!" error. But if I select the bank name and close the GUI window immediately without touching anything else and reopen it I'll find that the new bank indeed has been selected and I can now make other changes in the GUI as needed. When I close the GUI and the VST driver configurator window, I get no errors and the new settings persist when the next MIDI device accesses the VST driver. If you change banks multiple times, however (even with closing and reopening the GUI with the configurator), it will freeze/hang regardless and you have to force close again and start over. So it seems you can only get one bank change in with the close/reopen method before it hangs. Though if you make one change, close the GUI, close the configurator, reopen the configurator, and reopen the GUI it can work that way. Just a few extra steps. It's a bit sketchy but it does work now! If there's a way that can be ironed out that would be fantastic, but if not at least it functions with a bit of quirkiness.

As for the SN76489 VST, I had forgotten that it was mono. That did confuse me as well. There is actually a better plugin called SN-EMU which has LFO functions as well that the SocaLabs one doesn't have (being the simplest implementation of the chip). SN-EMU works a lot better and doesn't have the garbled sound issue (and isn't mono, which would explain it). So I'm happy with that!

The Genny VST seems to no longer be allowed to be configured anymore with the driver so it's unusable (the button is grayed out in the configurator). I assume that's just the way it is and nothing can be done about it, which is fine. We do have OPNplug as well which works as well as ADLplug.

Many thanks for looking into this issue either way!

Hi,
I have added fake rendering of samples to configuration dialog. This way ADLplug's editor behaves better and changes are reflected real time. The only problematic part is the virtual piano (do not ask why, just do not touch it) but it is not relevant at config time anyway. The (positive) side effect of this modification is that other plugins may also appear to be more alive at config time (e.g. displaying the proper sample rate etc.).
Also fixed the problem with Genny VST that demands audioMasterGetTime/vstTimeInfo support from the host despite the fact that it is an optional feature according to VST specification.
New test version:
@Edit: test version removed, look at next post

Finally I could make the editors of plugins written in JUCE framework (e.g. ADLplug, OPNplug, SN76489 by SocaLabs etc.) work in runtime with the driver. I could do this by renaming the vsthost32/64.exe to vstbridgeapp32/64.exe 😀
Let me tell the story of this discovery since I think it's interesting. First I noticed that 32-bit JUCE plugin editors do not work in 64-bit Cubase either when I open Cubase with its short file name
(I mean something like this: C:\PROGRA~1\STEINB~1\CUBASE~2\CUBASE~1.EXE). The problem was the same as with VST Midi Driver: the calls to effEditOpen never return. But the plugin editors worked perfectly when Cubase was started by clicking on the exe (Windows explorer). I downloaded the source of JUCE framework and noticed that every plugin written in JUCE detects VST hosts by hard coded paths and file names! I mean something like this:

1 if (hostFilename.containsIgnoreCase   ("Adobe Premiere"))        return AdobePremierePro;
2 if (hostPath.containsIgnoreCase       ("SONAR 8"))               return CakewalkSonar8;
3 if (hostFilename.containsIgnoreCase   ("Cakewalk.exe"))          return CakewalkByBandlab;
4 if (hostFilename.containsIgnoreCase   ("GarageBand"))            return AppleGarageBand;
5 if (hostFilename.containsIgnoreCase   ("Cubase10.5.exe")  || hostPath.containsIgnoreCase    ("Cubase 10.5"))       return SteinbergCubase10_5;
6if (hostFilename.containsIgnoreCase   ("VSTBridgeApp"))          return SteinbergCubase5Bridged;
7...

I do not think I have to explain why this detection method is a shitty one. First it cannot work properly with short file names and portable versions. Second VST specification has well defined methods how to ask host's vendor/product info.
I have also noticed a remark in the code that when some hosts are detected then a special handling becomes active to prevent editor thread related problems. One of them was 'SteinbergCubase5Bridged' which is detected by the filename containing 'VSTBridgeApp'. So I renamed vsthost32/64 accordingly and it works.
(I have also thought about asking JUCE authors to include vsthost as a host that requires this alternative handling but unfortunately it could not cure the problem of existing plugins that will not be recompiled.)
BTW, It could have been done much more elegantly if I could report fake VST host info the standard way through audioMasterGetVendorString/audioMasterGetProductString.
JUCE is a relatively often used framework so overall I think the renaming can be justified. I'm just hoping that there will not be another VST framework with a similar detection pattern...
Here is the test version to try:

Oh wow nice work! I will try this when I get home after work. I did try your previous fix and ADLplug worked great after that. I got constant hangs and crashes with OPNplug though. But I guess this fix solves the problem at its root.