Falcosoft wrote on 2023-07-03, 20:41:

According to the Github repo old school WinMM Midi should work even with the new Midi stack. Only Directmusic will be fully drop […]
Show full quote

RetroGamer4Ever wrote on 2023-07-03, 19:33:

https://devblogs.microsoft.com/windows-music- … -midi-services/

According to the Github repo old school WinMM Midi should work even with the new Midi stack. Only Directmusic will be fully dropped.
https://github.com/microsoft/midi
midi2.png

Technically speaking, DM was dropped many years ago, though it remains functional and Microsoft even has a giant pile of available dev-lit that you can use to get started with implementing it in software, even though the SDK they had for it is long outdated and mostly unusable on today's Windows. They just haven't removed DM from the Windows codebase for whatever reason, and it has been left intact since the Windows XP days. I don't see it going away until Microsoft initiates the 32-bit legacy code purge - for security purposes - that we have heard about over the past few years. What we need to do is figure out where the discussions for this are taking place and put our 45-cents in the jar, cause there really isn't much out there for us at this point, is there?

RetroGamer4Ever wrote on 2023-07-05, 10:39:

...I don't see it going away until Microsoft initiates the 32-bit legacy code purge - for security purposes - that we have heard about over the past few years

As you can read in the new Windows MIDI Services Github repository the exact time when this Directmusic purge will happen is when the new Midi 2.0 compatible Midi stack repleces the current one.
At least the compatibility matrix presented on the page strongly suggests this. This will be a feature update in order Windows to be Midi 2.0 compatible and seemingly this has nothing to do with security or 32-bit related legacy code cleanup.

Hi,
Finally I have decided to make a fork from Arakula's fork. The reason is that DB50XG's version is rather for special cases. It is only more useful for ones that need very low latencies (instead of more precise Midi timings) for real-time jamming with a Midi keyboard. Otherwise it has only drawbacks (mostly thanks to Bass related problems).
So here is the new repository and also a new release:
https://github.com/Falcosoft/vstdriver/releases/tag/v1.0.0

New features compared to the ones shared in this topic:

1. Added option to show VST Editor when port is used. It works for both ports but it works best when only 1 port is used by the client. When both ports are used by a single client at the same time it's better to set this option to off. ( I think this was the most important addition in DB50XG's version so I ported this feature.)

2. Fixed modal configuration dialog and VST dialog editor buggy z-order behavior at config time. (topmost status is set for both).

3. Vsthost32/64 has been optimized for 2 ports (the original is for 3 ports inherited from foo_midi).

Bye.

Thank you, Falcosoft, for taking the time and trouble to make an actual fork of this very useful program. Since everybody else have abandoned their forks, it makes the most sense to start over with a new fork that will be maintained into the future. Also, more people will be able to find the program, as an actual fork, rather than just a brief mention on an obscure thread on VOGONs. Thank you for your continued work on this very useful program.

New version:

1. Added options to modify Sample Rate and Buffer Size.
2. Fixed VST Editor threading problem that resulted in no sound output when Editor dialog is closed under Win7/XP 32-bit.
3. Both port A and Port B can be used with VST Editor dialogs even if both ports are opened by the same client.
4. Added proper version info to installer.

https://github.com/Falcosoft/vstdriver/releases

VST Midi driver dual port test:
https://youtu.be/adrYZ_lVHtg

@Falcosoft: I'm trying to understand what you are demonstrating on your dual port test video. Were you able to achieve greater polyphony than is usually possible with the Yamaha S-YXG50 by running 2 instances of it simultaneously and splitting up the workload? If so, that is really cool!

DragonSlayer wrote on 2023-07-08, 04:06:

@Falcosoft: I'm trying to understand what you are demonstrating on your dual port test video. Were you able to achieve greater polyphony than is usually possible with the Yamaha S-YXG50 by running 2 instances of it simultaneously and splitting up the workload? If so, that is really cool!

Hi,
No, not exactly. I would have liked to demonstrate that VST Midi driver works perfectly also with so called 32-channel (2-port) Midi files. And you can also inspect on the VST dialogs how the different ports are used. This kind of Midi files simply cannot be played back with a single 16-channel port correctly (regardless if your 1 port has enough polyphony or not). But as you say the authors (in this case Konami) may have decided to use 2 ports/32-channels because of polyphony constraints. The other reason could be the constraint of 16 simultaneously usable instruments on 1 port.

This feature is new in the sense that DB50XG's abandoned version killed 2 ports compatibility and the abandoned Arakula fork had no possibility to inspect VST dialogs during playback.

Even though this is not quite as exciting as I had first thought, it is still a great achievement and has a lot of potential for future experimentation. I'm excited to see what you will be able to achieve next with this project. 😀

DragonSlayer wrote on 2023-07-08, 07:36:

Even though this is not quite as exciting as I had first thought, it is still a great achievement and has a lot of potential for future experimentation. I'm excited to see what you will be able to achieve next with this project. 😀

Most VSTi synths have no problem with polyphony. But they only support 16 channels maximum. That's why 2 working ports are important.
Polyphony constraint is more of a problem for earlier hardware devices such as SC-55. My WinMM Multi port VSTi has an even/odd channel separation option for such devices so you can use 2 of them to increase polyphony for normal 16 channel Midi. But this is not related to VST Midi driver.

More MIDI channels = more MIDI goodness. 😀

Holy moly, a driver that's even getting updated? I must be dreaming! Fingers crossed this one won't stop working like the old versions did!

Hi,
New version v1.2.0:
https://github.com/Falcosoft/vstdriver/releases/

1. Added Volume/Output Gain slider control to config dialog.

2. All port/instance related bugs are fixed now.

3. Increased priority for rendering threads.

4. Added proper centralized versioning to all projects. Config dialog also shows current version of the package.

5. 192 kHz option added to Sample Rate selector. Be aware that one of the most popular plugins (namely S-YXG50) is NOT compatible with this sample rate.

6. Updated config dialog icon.

Ps: Most likely there will be no further updates for a while. I hope I have fixed the most obvious problems and added the most important missing features. I don't think there are many low hanging fruits left.
Other new features most likely would require more development time and I have no much free time (work, other projects etc.)
But this does not mean that I will abandon the project. If you find any new (or old) bugs of course I will try to fix them.
So any feedback is welcome.

Some hints about the new options:
1. Sample rate: The best option is if you select the sample rate to be the same as the audio card's sample rate selected on Windows -> Speaker Properties -> Advanced tab. This way no resampling is necessary by Windows. The only problem is that some plugins are sample rate dependent or work best with a particular sample rate. E.g. S-YXG50 works best only with 44100/48000 Hz. On other frequencies it produces bad output (most noticeable at 32000 and 192000 Hz , but 96000 Hz is alo problematic). Munt VSTi has the most proper timing on 32000 Hz. OPL3 plugins has the best emulation accuracy at 49716 Hz. Of course in these cases the emulation accuracy is more important than some resampling.
Generally 48000 Hz is the most compatible one.

2. Buffer size: lower size means lower latency but the sound output is more fragile (intermittent pauses because of high CPU consumption etc.). So it is always a compromise. For a general Midi usage scenario (where real-time jamming is not the most important) I recommend values in the 80-160 ms range. Too high latency can result in disturbing delay between visual effects (such as virtual piano, Midi channel volume displays etc.) and audible audio.

3. Output Gain: it increases/decreases the output level after the plugin has already rendered the sound so it cannot prevent clipping in the synth's digital domain. For plugins that include volume/gain slider on the VST editor interface (such as S-YXG50) it may be more useful to use the editor in real-time. But e.g. in case of SC-VA where the sound output level is rather low even at maximum this feature can be useful. It can be also useful for editorless plugins.

Wow, another new version, so soon. Thank you! 😀

Is it possible to have Capital Tone Fallback added as well? Unless it's already in and I didn't realize.

It would require a lot of work since at least the way it works in FSMP needs instrument definition file parsing/interpreting and customizable Midi processing. None of them exists currently in the driver. I do not think I will add it in the near future.

Fair enough. TBH I am not able to tell how necessary the feature would be for the average user. Anyway, what we have so far is definitely already a lot more than I could've hoped for, so I'm celebrating every update to this project.

Yet another new version 😀

1. Added 4 channel audio output option. This way you can enjoy surround Midi sound. If option is enabled then Port A is assigned to Front speakers and Port B is assigned to Rear speakers.
You can use my Midi Player (use included WinMM MultiPort VSTi) or Midi Trail to play back 32-channel Midi files where Midi channels 1-16 can be played on port A and Midi channels 17-32 on port B. Example 32-channel Midi files:
https://falcosoft.hu/ch32_midis.zip
Rendered 4-audio channel example of 32-channel KIKAN.MID:
https://falcosoft.hu/kikan_4ch.ogg

2. Fixed SC-VA VST editor display bug after parts section opened/closed.

3. Fixed VST editor related problems when both ports are used at the same time (opening 2nd instance right after 1st one could kill vsthost).

4. Other minor fixes and enhancements.

Still works with Windows XP/Vista/7/8/10/11 but on WinXP proper 4-channel playback greatly depends on sound card drivers.

PS:
Besides 32-channel Midi playback you can also use 4 channel audio option for gaming. E.g. if you assign DosBox Midi to port B then game music would sound from rear speakers while normal game audio/digital effects from front speakers.

If anyone needs some test files for multi-port, I've got some from the old QuestStudios site that are intended to be used with the StudioCanvas models that added that feature to the SoundCanvas design.

RetroGamer4Ever wrote on 2023-07-14, 17:09:

If anyone needs some test files for multi-port, I've got some from the old QuestStudios site that are intended to be used with the StudioCanvas models that added that feature to the SoundCanvas design.

Thanks, would you attach them for testing?

Here ya go. These were made on/for the last generation of Roland SC hardware modules, which then became the StudioCanvas line. They apparently didn't work with the old VSC software synth due to it's limitations, but the new VST driver with multi-port could possibly get around that.