I'm detect bug
If play MIDI and on fly remove synth , plugin was freeze.
But if play MIDI and on fly reselect synth , plugin still workable )
This then what need fix , I asked you remake mechanism remove synths add in list synths "none" , you for some reason this ignored and sayd to me as remove synths on right click mouse , but if I so do on fly with play MIDI - will plugin freeze. Please remake deselect synthesizer ,this need do easy per "none" port in list.

Roland User wrote on 2023-12-04, 09:53:

I'm detect bug If play MIDI and on fly remove synth , plugin was freeze. But if play MIDI and on fly reselect synth , plugin st […]
Show full quote

I'm detect bug
If play MIDI and on fly remove synth , plugin was freeze.
But if play MIDI and on fly reselect synth , plugin still workable )
This then what need fix , I asked you remake mechanism remove synths add in list synths "none" , you for some reason this ignored and sayd to me as remove synths on right click mouse , but if I so do on fly with play MIDI - will plugin freeze. Please remake deselect synthesizer ,this need do easy per "none" port in list.

Unfortunately I cannot reproduce your problem again. So this must be a special race condition on your side with the selected Midi out port. There is no such 'general' bug that would affect all kinds of Midi out ports. I have already placed a lock/critical section around both the remove and the change procedures so there is not much more that I can do about it. But the point is you should not remove or change synths while playback is active since it will never work as intended. The messages prerviously sent are already lost so the new synth will be uninitialized (missing programs etc.) Here is my test video:
https://youtu.be/js62DGIPOEM

BTW, re-placing the remove synth option would be more work than you think moreover would make previously saved fxb files invalid so I do not think it's worth the hassle.

Here this bug https://yadi.sk/i/-fEa8MIQHKL4bQ
Delay related to what need be wait 1 minute for restart plugin , I do cut this fragment and start after 60 seconds

Roland User wrote on 2023-12-04, 12:04:

Here this bug https://yadi.sk/i/-fEa8MIQHKL4bQ
Delay related to what need be wait 1 minute for restart plugin , I do cut this fragment and start after 60 seconds

I simply cannot comprehend your video. Please make a video about the moment when the bug happens. I cannot follow which click of the 100+ clicks you made is the one that you really wanted to show.
Or simply follow this rule: Stop playback before you remove/change synths. And let's forget this.

Maybe this because you use Realtime-API , in so time I use Stream API ) I verify this )

Yes the reason is in the flow mode of operation , if use Real-Time all work normaly
Please set default mode real-time.
On logical , Stream-API with zero delay need delete , because this means work in Real Time-API, as I understand zero in Stream API work with error , I suppose that this absolute non normalfor Stream API. Then need set as default Real Time-API , and give opportunity select Stream-API with minimal correct settings for delay )

Roland User wrote on 2023-12-04, 18:01:

Yes the reason is in the flow mode of operation , if use Real-Time all work normaly
Please set default mode real-time.
On logical , Stream-API with zero delay need delete , because this means work in Real Time-API, as I understand zero in Stream API work with error , I suppose that this absolute non normalfor Stream API. Then need set as default Real Time-API , and give opportunity select Stream-API with minimal correct settings for delay )

Stream API with zero delay is not the same as real-time API at all. In your SAVIhost try to set sample rate to 48000 and buffer size to at least 4800 and you will hear the difference immediately.
With stream API the timing is always perfect while with real-time API timing depends on the update period. If buffer size is small then real-time API is good else it is not usable.
So no, I will not delete the option and no, I will not change the default since it gives better result in 99% of use cases (including using it with FSMP). Your use case is the 1%.
And lets's stop here.

I sets all synths as on screen to Roland
But I not understand as settiings
"Stream API with zero delay is not the same as real-time API at all. In your SAVIhost try to set sample rate to 48000 and buffer size to at least 4800 and you will hear the difference immediately."
this need do in WinMM Multi Port VSTi ? If yes , what for ? This plugin only resend midi messages to VST synthesizers , hovewer , if I use Stream-API , crashed midi resend resend mechanism

Roland User wrote on 2023-12-04, 19:28:

I sets all synths as on screen to Roland But I not understand as settiings "Stream API with zero delay is not the same as real- […]
Show full quote

I sets all synths as on screen to Roland
But I not understand as settiings
"Stream API with zero delay is not the same as real-time API at all. In your SAVIhost try to set sample rate to 48000 and buffer size to at least 4800 and you will hear the difference immediately."
this need do in WinMM Multi Port VSTi ? If yes , what for ? This plugin only resend midi messages to VST synthesizers , hovewer , if I use Stream-API , crashed midi resend resend mechanism

Yes, you need to do this in your SAVIHost with WinMM Multi Port VSTi loaded for testing.
The point is that since it is still a VSTi plugin it gets incoming MIDI messages at the rate of the update period (that you set as buffer size in SAVIHost). This is true regardless the plugin uses audio out or not ( it does not).
So depending on VST host settings real-time API can be good or absolutely horrible. On the other hand Stream API can give you perfect timings regardless of the host/buffer size settings since it can use 'deltaFrames' timestamp info of the incoming Midi messages. The real-time API cannot use this info.
Overall:
The real-time API can be only as precise as the update period. Supposing 48KHz sample rate at buffer size of 240 its precision is 5 ms. At buffer size of 480 its precision is 10 ms. At buffer size of 4800 its precision is 100 ms and so on...
Contrary the Stream API is sample offset precise that is <= 1 ms (always, independently of buffer size).

Thank you )
I thought what VST Plugins need set buffers only if need output sound , and I not nkowned what VST Plugins need always set buffers )

Thus, you helped me correct a error in my synthpack

Which buffer size need set in WinMM Multi Port VSTi to play midi per synthesizers with 2048 buffer size ?

Roland User wrote on 2023-12-04, 20:13:

...
Which buffer size need set in WinMM Multi Port VSTi to play midi per synthesizers with 2048 buffer size ?

These are not related. If you want to use the real-time API then set the buffer size of WinMM Multi Port VSTi to as low as possible/reasonable. E.g. to 96 (2 ms) but never higher than 240 (5 ms).
The buffer sizes of the real synths do not matter.

44100 : 256 = 172 ms , right ?
But this was be error
Me need 44100 : 22050 = 2 ms , righ ?
Or 44100 : 500 = 882 smples = 2 ms ?

Roland User wrote on 2023-12-04, 21:52:

44100 : 256 = 172 ms , right ? But this was be error Me need 44100 : 22050 = 2 ms , righ ? Or 44100 : 500 = 882 smples = 2 ms ? […]
Show full quote

44100 : 256 = 172 ms , right ?
But this was be error
Me need 44100 : 22050 = 2 ms , righ ?
Or 44100 : 500 = 882 smples = 2 ms ?

No. In case of 44100 Hz sample rate the buffer size of 44.1 = 1 ms so 44100 : 256 = 5.8 ms.
In case of 44100 you would need 88.2 samples/buffer to get 2 ms. 882 samples means 20 ms not 2 ms.
For 44100 Hz you cannot get exactly 2ms buffer (88.2). Use the nearest available integer close to it.
But I do not understand why you are insisting on 44100 Hz.It's not important for Win MM VSTi at all. Switch to 48000 Hz and your calculations will be easier (2ms = 96 samples and so on).

This not work , I not known why (
All what work this 2048 samples or more
I stoped on 8192 samples per 2048 samples per port

I'm in stupor , if I do that as on attachment - all work stable and not errors , but if I decrease WaveOutBufferSize smaller 2048 samples - all work with bugs. Why ?
Really buffersize need do as summ all buffers for synthesizers or larger ? But not smaller ? Why ? You sayd what Real Time API work at 2 ms , but Stream API need big buffer or this mode so not work as need.
Me need all you sayd about for Real Time API mode , only vice versa if I want this do with Stream API mode.

Roland User wrote on 2023-12-04, 23:40:

I'm in stupor , if I do that as on attachment - all work stable and not errors , but if I decrease WaveOutBufferSize smaller 2048 samples - all work with bugs. Why ?
Really buffersize need do as summ all buffers for synthesizers or larger ? But not smaller ? Why ? You sayd what Real Time API work at 2 ms , but Stream API need big buffer or this mode so not work as need.
Me need all you sayd about for Real Time API mode , only vice versa if I want this do with Stream API mode.

I do not know what you are talking about. This has nothing to do with WinMM Multiport VSTi. Ask SAVIHost's developer (Hermann Seib).

Falcosoft
You include to FSMP plugin OPL3 GM VSTi , and there is some questions :
1) what giving option "Use Dual Synth Mode" and where I can hear diffirence ?
2) whether there is a in plan adding Voyotra SuperSapi mode with drums on 10 channel and not on 16 channel ?
3) whether there is a in plan adding Enhanced ESFM mode ? Especially as this was be in ESS 1868 Melody Sound
I would like to havin ESS1868 emulation as this was be Windows 98 and drivers for ESS1868 Melody Sound ) because this was my second sound card after ESS688 , I remember as good sounded MIDI on this sound card , but I not have old PCwith this hardware )
I owned those what on attachments and first drivers for this card )

Roland User wrote on 2023-12-05, 13:03:

Falcosoft You include to FSMP plugin OPL3 GM VSTi , and there is some questions : 1) what giving option "Use Dual Synth Mode" an […]
Show full quote

Falcosoft
You include to FSMP plugin OPL3 GM VSTi , and there is some questions :
1) what giving option "Use Dual Synth Mode" and where I can hear diffirence ?
2) whether there is a in plan adding Voyotra SuperSapi mode with drums on 10 channel and not on 16 channel ?
3) whether there is a in plan adding Enhanced ESFM mode ? Especially as this was be in ESS 1868 Melody Sound
I would like to havin ESS1868 emulation as this was be Windows 98 and drivers for ESS1868 Melody Sound ) because this was my second sound card after ESS688 , I remember as good sounded MIDI on this sound card , but I not have old PCwith this hardware )
I owned those what on attachments and first drivers for this card )

1. Dual synth mode doubles the available simultaneous voices from 18 to 36. You can hear it (and also can see it on the plugin's interface as actual/max voices) when a Midi file has graeter than 18 note/voice polyphony. Here is a high polyphony Midi file for testing:

2. Not likely in the near future. I think you had better ask ADLplug's authors on Github. ADLplug already supports much more formats than OPL3 GM VSTi.
3. AFAIK ESFM is still not fully reverse engineered (there is a not fully completed register level documentation available on GitHub) and no working ESFM emulation engine has been written so far. So currently there is nothing to use.

Hi,
If someone is interested I have forked the abandoned ASIO2WASAPI project on GitHub to make a private plugin for VST MIDI driver but at the same time I have also updated the main branch so some useful features added to the full ASIO driver and I have also made some important fixes. The driver now supports WASAPI shared mode besides exclusive mode and if sound card driver suppports it Windows 10+ special low latency shared mode can also be used with the driver.
So comparing e.g. to ASIO4ALL when shared mode is used you can still use other audio software even if the ASIO driver is active.

New features/fixes:
1.Fixed supported format query.
2.Fixed non modifiable 100 ms latency problem.
3.Fixed too quiet rendering in case of supported 24-bit PCM format.
4.Count of supported channels is calculated automatically.
5.Supported sample rates are calculated automatically.
6.Added support for default device. Driver can restore itself when default device or audio properties are changed in Windows.
7.Added support for WASAPI shared mode
8. Added Win10+ special low latency shared mode. (This mode needs proper drivers. Usually proprietary vendor drivers from Realtek, NVIDIA etc. do not support low latency shared mode. But generic High Definition Audio driver from Microsoft does support it on Windows 10/11.)
9. Added version info to ASIO control panel.

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

I wish I knew enough about MIDI music to actually make use of some of the things you are doing, but I just wanted to let you know I appreciate them nonetheless.