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.
What Midi client you used exactly when you experienced this, and what is the process in steps I should do to be able to replicate the problem?
BTW, you can try 2 things:
1. Set XG/GM/GS reset from the system tray menu.
2. Try to disble KeepDriverLoaded from the registry:
HKEY_CURRENT_USER\Software\VSTi Driver \KeepDriverLoaded = 0
@Edit:
Unfortunately I could not reproduce your problem. E1M8 sounds good to me in case of GZDoom: https://youtu.be/o2f2_zUc508
Last edited by Falcosoft on 2024-03-01, 17:45. Edited 1 time in total.
Well, I'm trying this directly ingame now, namely Woof! or GZDoom (latest versions each). I'm not changing anything about the plugin settings in the driver, everything is at default.
All I'm doing is launch the port and launch the first map of each episode. First three episodes are OK, but D_E1M8 which is played in the first map of E4M1 is playing all kinds of wrong instruments from the very first note onwards.
I've tried different versions of the VST Driver, no change. Different versions of Woof!, no change. With GZDoom or Crispy Doom it seems to work, which indicates it might be a Woof! issue. I will poke the port authors to investigate.
Well, I'm trying this directly ingame now, namely Woof! or GZDoom (latest versions each). I'm not changing anything about the plugin settings in the driver, everything is at default.
All I'm doing is launch the port and launch the first map of each episode. First three episodes are OK, but D_E1M8 which is played in the first map of E4M1 is playing all kinds of wrong instruments from the very first note onwards.
I've tried different versions of the VST Driver, no change. Different versions of Woof!, no change. With GZDoom or Crispy Doom it seems to work, which indicates it might be a Woof! issue. I will poke the port authors to investigate.
As I said before I would need a step by step tutorial how to reproduce the problem. I do not know all your pet Doom source ports so I even do not know how to change maps in case of Woof... 😀
Maybe we would have an advantage if we could exactly tell the authors what the problem is. But for this I need your help first to reproduce the problem: a step by step tutorial...
Forget it, I found the issue. It was my stupidity. For some ports I have a custom MIDI pack installed (which I never used, so I didn't know what it sounds like) and it's replacing several MIDI tracks of the original game. It has nothing to do with any port or driver setting.
Side note:
Is "All Notes/CC off" recommended as a default setting in the taskbar options icon? Not sure if it makes any difference when selected, but "GS Reset" sounds more reasonable to me. Depends on when it's triggered, though.
As for the 2006LE, I assume it will just play with default settings, which are hopefully sufficient (dunno if it's using all 128 voices like the XG50, though).
Trelokkwrote on 2024-03-01, 18:10:Forget it, I found the issue. It was my stupidity. For some ports I have a custom MIDI pack installed (which I never used, so I […] Show full quote
Forget it, I found the issue. It was my stupidity. For some ports I have a custom MIDI pack installed (which I never used, so I didn't know what it sounds like) and it's replacing several MIDI tracks of the original game. It has nothing to do with any port or driver setting.
Side note:
Is "All Notes/CC off" recommended as a default setting in the taskbar options icon? Not sure if it makes any difference when selected, but "GS Reset" sounds more reasonable to me. Depends on when it's triggered, though.
As for the 2006LE, I assume it will just play with default settings, which are hopefully sufficient (dunno if it's using all 128 voices like the XG50, though).
1. OK, It's good to know the problem is not related to this driver.
2. I do not think that GS reset would be the best default option e.g. for S-YXG50 (which is one of the most used plugins). In GS mode S-YXG50 sounds completely different compared to its default state. "All Notes /CC Off" at least cannot change the default state of plugins. But maybe GM could be the best compromise... Almost all popular plugins (Munt VSTi is an exception) sound similar to default in GM mode and in this mode most bank select related problems can be avoided.
But overall even if "All Notes /CC Off" is not the best option for a particular plugin it is definitely the most neutral and most universal option. It always works even in case of plugins that do not even know that SysEx messages exist (e.g. ADLplug, OPNplug) or in case of plugins that have bugs related to SysEx message handling (e.g. Edirol VSC, Edirol Hyper Canvas).
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).
I appreciate you supporting NT 4.0 in this project. Just a note, though, that there's no need to not support a feature on NT due to SSE: SP6 includes a kernel driver, intlfxsr.sys, that enables SSE support. The SP6 installer will install it automatically if it manages to detect your processor as compatible (I had this happen on a Core 2 system with "limit CPUID to 3" enabled in the BIOS), but it can be installed manually. Although ostensibly just for SSE, it evidently allows SSE2 to be used also, and from the looks of it, perhaps even beyond that. I've never run into an "illegal instruction" error running software that ostensibly uses or can utilize SSE2 or higher with this driver installed.
The original driver will reject non-Intel processors as well as Intel processors that offer CPUID levels greater than 3, but see the link above for a patch that disables these checks, enabling it to work on more-or-less any CPU with SSE support. I recommend using the registry entries in the attached REG file (change extension to .reg after downloading) to install it instead of those in the package above, as they omit the Event Log entries. Put the driver in system32\drivers and run the REG file, then reboot. If the driver does not report any errors in the Event Log, it should be working.
loblolly986wrote on 2024-03-06, 18:43:I appreciate you supporting NT 4.0 in this project. Just a note, though, that there's no need to not support a feature on NT due […] Show full quote
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).
I appreciate you supporting NT 4.0 in this project. Just a note, though, that there's no need to not support a feature on NT due to SSE: SP6 includes a kernel driver, intlfxsr.sys, that enables SSE support. The SP6 installer will install it automatically if it manages to detect your processor as compatible (I had this happen on a Core 2 system with "limit CPUID to 3" enabled in the BIOS), but it can be installed manually. Although ostensibly just for SSE, it evidently allows SSE2 to be used also, and from the looks of it, perhaps even beyond that. I've never run into an "illegal instruction" error running software that ostensibly uses or can utilize SSE2 or higher with this driver installed.
The original driver will reject non-Intel processors as well as Intel processors that offer CPUID levels greater than 3, but see the link above for a patch that disables these checks, enabling it to work on more-or-less any CPU with SSE support. I recommend using the registry entries in the attached REG file (change extension to .reg after downloading) to install it instead of those in the package above, as they omit the Event Log entries. Put the driver in system32\drivers and run the REG file, then reboot. If the driver does not report any errors in the Event Log, it should be working.
Hi,
Thanks for the info. I could only test NT4 and the new BassASIO on a VM and only with vanilla SP6. In this case SSE/SSE2 instructions could be executed without illegal instruction errors but seemingly the OS was not aware of the "new" XMM registers and did not save the register states between context switches. This resulted in heavy stability problems with BassASIO. This way out of the box NT4 SP6 + ASIO experience has not been that great and I think it's not worth the effort to support it. Actually it's very hard to find any working ASIO drivers for NT4. I could only test ASIO on NT4 with my dummy test ASIO driver since I could not find any working "real" one. And not everyone would know about your suggested solution and maybe not everyone could identify the problem itself.
BTW, here is an intuitive test result that shows the problem even with your installed driver on a VirtualBox VM with an AMD CPU when running multiple threads that use SSE/SSE2 code (you can see many wrong colored dots inside the Mandelbrot set when you run 2 instances of the test program and you select code paths that use SSE/SSE2). You can repeat the test with and without the installed driver to confirm if it works or not.
Falcosoftwrote on 2024-03-07, 02:14:Hi,
Thanks for the info. I could only test NT4 and the new BassASIO on a VM and only with vanilla SP6. In this case SSE/SSE2 ins […] Show full quote
Hi,
Thanks for the info. I could only test NT4 and the new BassASIO on a VM and only with vanilla SP6. In this case SSE/SSE2 instructions could be executed without illegal instruction errors but seemingly the OS was not aware of the "new" XMM registers and did not save the register states between context switches. This resulted in heavy stability problems with BassASIO. This way out of the box NT4 SP6 + ASIO experience has not been that great and I think it's not worth the effort to support it. Actually it's very hard to find any working ASIO drivers for NT4. I could only test ASIO on NT4 with my dummy test ASIO driver since I could not find any working "real" one. And not everyone would know about your suggested solution and maybe not everyone could identify the problem itself.
BTW, here is an intuitive test result that shows the problem even with your installed driver on a VirtualBox VM with an AMD CPU when running multiple threads that use SSE/SSE2 code (you can see many wrong colored dots inside the Mandelbrot set when you run 2 instances of the test program and you select code paths that use SSE/SSE2). You can repeat the test with and without the installed driver to confirm if it works or not.
WinNT4_SSE_Test.png
mandel1.exe
I couldn't reproduce those artifacts when trying the test program on real hardware with intlfxsr installed (Core 2 Duo E8600 here); all SSE code paths render the graphic cleanly even with more than two instances competing for CPU time, under both uni- and multiprocessor configurations. SSE performs the best, with SSE2 a little slower (go figure), while SSE Scalar is only slightly faster than FPU ASM. I should note that I've updated my NT system with post-SP6a hotfixes and can't rule out that pertinent bugs may have been fixed by that, but I believe the problem you're seeing is because of VirtualBox. It's been some time since I was actively using VirtualBox to run NT, but I do seem to recall having trouble getting the SSE driver working, and it seems like VirtualBox intercepting the SSE instructions regardless of the driver's functionality was something I observed. This was using software virtualization, as the host system I was using did not support VT-x, and for all I know that may have been the culprit, hardware-accelerated virtualization (and much newer guest OSes) being where developer attention was focused by then. The driver did seem to work (to the limited extent I tried SSE-utilizing software at the time) under VMware Player 6/Workstation 10's software virtualization, which I found more satisfactory and better-performing overall in multiple aspects compared to VB (sometimes having to tweak the VM configuration file manually due to the (Player) GUI's inadequacies notwithstanding).
What I would do is, when running on NT 4.0, use the OpenSCManagerW (with SC_MANAGER_CONNECT access), OpenServiceW (with SERVICE_QUERY_STATUS access), and QueryServiceStatus APIs to determine if the intlfxsr service is both present and running, and make SSE-dependent features available if it is. A note about the SSE requirement for the ASIO feature and the need for the intlfxsr driver to use it on NT could be included in your documentation. But this is just a suggestion.
You make a fair point about ASIO availability. I don't have wide knowledge of sound cards with NT drivers, but I know Creative's Sound Blaster Audigy drivers install an ASIO interface (and even an OpenAL interface). The NT drivers can be found on the Audigy driver CDs; later CDs support more card models than earlier ones, with this being the latest I know of (among pre-Audigy 2 CDs). Sadly, I found all the versions I tried to be too buggy for my liking: you know there's a nasty bug when NT's AUTOCHK component fails to detect most of your partitions because of your sound card drivers, and sometimes after running DirectSound-utilizing software, they would crap out altogether, with glitchy screeches coming from the speakers in place of audio, only fixable by rebooting. Not problems I've had with a good old CT4750 or the Turtle Beach Santa Cruz, but the drivers for those don't offer fancy features like ASIO.
SSE performs the best, with SSE2 a little slower (go figure), while SSE Scalar is only slightly faster than FPU ASM. I should note that I've updated my NT system with post-SP6a hotfixes and can't rule out that pertinent bugs may have been fixed by that, but I believe the problem you're seeing is because of VirtualBox.
1. Yeah, it's normal since the SSE code path can put 4 (32-bit) floats into one 128-bit XMM register to calculate 4 pixels simultaneously. The SSE2 code path uses only 2 (64-bit) doubles so it can calculate only 2 pixels at once. The SSE scalar code path only calculates 1 pixel in 1 round the same way as the FPU ASM code path. BTW, the AMD specific 3DNow! code path uses 2 (32-bit) floats in the 64-bit MMX registers to calculate 2 pixels at once.
2. Maybe the problem is because of VirtualBox but I think nowadays the number of users who use NT 4 on a virtual machine instead of a real one can be similar (if not more). So ASIO instability even on VMs is problematic. Moreover the default WaveOut driver works without problems even on VMs. I have an Audigy2 ZS on real hardware but I could not install NT4 on it and this way I cannot test ASIO + NT4 on real hardware.
So until someone really wants to use this rare combination I think I leave this as it is now: no ASIO support on NT4.
1. Added general VST editor primarily for editorless plugins.
2. Added 'Switch UI' button to host editor dialog so general VST editor can be used with any plugins.
3. Added special 'Switch UI' handling for Yamaha S-YXG50 and derivative plugins (YmF-724, Tyrus). In case of these plugins Switch UI button enables the debug panel since these plugins do not expose any VST parameters so general VST editor would be useless.
4. Added new VstMidiProxy component. Vst Midi global proxy enables 2 global ports so multiple clients can use the same ports. If it is enabled it also makes the 2 global ports and loaded plugin ready all the time. Autostart with Windows option is also implemented.
5. Added advanced settings tab to config dialog. On this new tab you can change settings that were available only through the registry so far. You can also start the new global Midi Proxy component from here.
6. Added conversion of short Midi messages sent with midiOutLongMsg(). VSTi plugins usually cannot handle short messages sent as kVstSysExType. So the driver sends short channel messages always as kVstMidiType.
7. Fixed Winamp Midi plugin 3.x ANSI/Unicode bug.
8. Extended save file format to handle multiple VST programs.
9. Config dialog and VST Midi Proxy dialog react to F1(Help) requests.
10. Other minor fixes and enhancements.
This version still works with Windows NT4 SP6/2000/XP/Vista/7/8/10/11.
On NT4 ASIO output mode is not available.
The new VstMidiProxy component requires WinXP SP2+ since it requires LooMidi installed and there is no version of LoopMidi that can be installed on pre WinXP SP2.
PS:
The new VstMidiProxy component actually does what Trelokk and VEG thought the earlier KeepDriverLoaded option did 😀. That is it creates global and always ready ports with always loaded plugin(s).
Does the self-signed code signing certificate actually help with anything? I doubt that it makes antivirus software happier.
Last time I checked the unsigned and the signed versions of the same executable it still made some difference but of course it could be a coincidence. The difference is typically 1 or 2 AV engines. And usually they are not the bigger ones.
Just noticed that the MIDI bug with Road Rash has been fixed in one of the newer CoolSoft MM builds. Nice!
The Road Rash problem should be fixed even without Coolsoft Midi Mapper if you use this VST Midi driver directly as Midi output since this driver also supports midiOutSetVolume() calls the same way.
Just noticed that the MIDI bug with Road Rash has been fixed in one of the newer CoolSoft MM builds. Nice!
The Road Rash problem should be fixed even without Coolsoft Midi Mapper if you use this VST Midi driver directly as Midi output since this driver also supports midiOutSetVolume() calls the same way.
Nice. I'm trying to catch up on things from the past couple of years. From newer graphical wrappers, to even more sound emulators and software. Seems like there is some cool stuff to check out.
Falcosoftwrote on 2024-03-31, 15:44:New version 2.4.0 has been released:
https://github.com/Falcosoft/vstdriver/releases/tag/v2.4.0
Virustotal:
https://www.virustot […] Show full quote
1. Added general VST editor primarily for editorless plugins.
2. Added 'Switch UI' button to host editor dialog so general VST editor can be used with any plugins.
3. Added special 'Switch UI' handling for Yamaha S-YXG50 and derivative plugins (YmF-724, Tyrus). In case of these plugins Switch UI button enables the debug panel since these plugins do not expose any VST parameters so general VST editor would be useless.
4. Added new VstMidiProxy component. Vst Midi global proxy enables 2 global ports so multiple clients can use the same ports. If it is enabled it also makes the 2 global ports and loaded plugin ready all the time. Autostart with Windows option is also implemented.
5. Added advanced settings tab to config dialog. On this new tab you can change settings that were available only through the registry so far. You can also start the new global Midi Proxy component from here.
6. Added conversion of short Midi messages sent with midiOutLongMsg(). VSTi plugins usually cannot handle short messages sent as kVstSysExType. So the driver sends short channel messages always as kVstMidiType.
7. Fixed Winamp Midi plugin 3.x ANSI/Unicode bug.
8. Extended save file format to handle multiple VST programs.
9. Config dialog and VST Midi Proxy dialog react to F1(Help) requests.
10. Other minor fixes and enhancements.
This version still works with Windows NT4 SP6/2000/XP/Vista/7/8/10/11.
On NT4 ASIO output mode is not available.
The new VstMidiProxy component requires WinXP SP2+ since it requires LooMidi installed and there is no version of LoopMidi that can be installed on pre WinXP SP2.
PS:
The new VstMidiProxy component actually does what Trelokk and VEG thought the earlier KeepDriverLoaded option did 😀. That is it creates global and always ready ports with always loaded plugin(s).
vstmidiproxy.png
Hi mate, I've installed your MIDI VST driver and I'm trying to use Roland Sound Canvas VA and replace SAVIHost + LoopMIDI but when I run your program SC-VA emits no sound.
Hi mate, I've installed your MIDI VST driver and I'm trying to use Roland Sound Canvas VA and replace SAVIHost + LoopMIDI but when I run your program SC-VA emits no sound.
There is no such general problem with SC-VA so it must be a configuration related problem on your side. What Midi client do you use?
First you should select the "Show VST dialog when a port is activated" option. Then check that the dialog opens when you start your Midi client and select VST Midi driver port. Then check if SC-VA reacts at all or not. And also check your Midi client is not muted in Windows mixer.
Here is a short how-to video about this: https://youtu.be/EDKNF2BVwmQ
