Very good product!
With the latest changes it is in full feature parity with JBridge and it is even much more stable!

The new test version of Midi Player uses this VST2 Bridge solution instead of JBridge and it works perfectly:
https://falcosoft.hu/midiplayer_67_test.zip

Some speed and stability optimizations are still in the works. 😉

Trelokk wrote on Yesterday, 22:00:

Some speed and stability optimizations are still in the works. 😉

During my testing I had absolutely no stability problems. Do your 'speed and stability optimizations' solve a specific problem or they are general ones?
I'm asking because it seems (at least) for me that some of them are questionable from the perspective of 'stability'.
https://github.com/NightFright2k19/VST2Bridge … ment-6671482491

BTW, I have measured the overhead in case of really heavy plugins like the S-MU2000 and Nuked SC-55 based ones and I experienced less than 5 percent. In case of lighter plugins the percentage value can be higher but in case of these light plugins the overhead does not really matter.
So overall I'm not sure that for 1 or 2 percent performance improvement we should risk stability.

Well, what has been made does not seem to cause problems. It can be kept as-is now and nothing further will be done in that direction.

Trelokk wrote on Today, 11:32:

Well, what has been made does not seem to cause problems. It can be kept as-is now and nothing further will be done in that direction.

I think it CAN cause problems. I made ChatGPT generate a test case for the potential problem. Please, show this to Claude. I'm curious what it reacts to it.
There are 2 possible runs. One uses the state before the optimization while the other uses the state after the optimization:
race-test.exe --pre
race-test.exe --post

Analysis is done and the bug has been found/fixed. Should this resolve everything, I guess this should be left alone. Reverting to pre-PR22 is something that should only be considered if there's really no other way.

Trelokk wrote on Today, 13:55:

Analysis is done and the bug has been found/fixed. Should this resolve everything, I guess this should be left alone. Reverting to pre-PR22 is something that should only be considered if there's really no other way.

Hi,
I do not think that this workaround fully fixes the problem. It cleverly only bypasses the case demonstrated by the test 😀
As I said in the comment section of the original PR the only real solution would be to publish msg and depth together as one atomic value and read that value in both the wait and dispatch paths.
The remaining problem is that the DLL still reads msg and depth separately.
A delayed wake-up from the previous audio block can put it into the dispatch check for the next block.
If it reads just before the helper clears it, then it reads the new depth just after the helper raises it then finally it can still dispatch early.

Alright. Reverting PR 22 now. After that, no further messing around with the code. It's finished.

Trelokk wrote on Today, 14:41:

Alright. Reverting PR 22 now. After that, no further messing around with the code. It's finished.

Hmm. You said:
Reverting to pre-PR22 is something that should only be considered if there's really no other way.
I did not even mention reverting the full original PR. I just mentioned how the problem should have been really fixed.
Can I try to solve it the way I think it should work?
This way you could preserve the performance boost + the original Multimedia Class Scheduler related optimizations + Linux/macOS socket improvements.
I cannot test the Linux/macOS socket improvements but I can test all the Windows related changes.

@Edit:
Thinking about this a little more you may be right. Since there have not been any detected problems with the original implementation so far, it does not make much sense to 'fix' it.

Autobuild r20 should work again as expected. 😀