Plugin Bridge - Alpha Testing Required

Saga Musix · March 17, 2014, 03:51:11

As announced before, OpenMPT is going 64-bit and for that purpose, it's also getting a plugin bridge. It can be used to run 32-bit plugins in 64-bit OpenMPT, or 64-bit plugins in 32-bit OpenMPT. Or, if it's necessary, You can run 32-bit plugins in 32-bit OpenMPT (e.g. to use more available RAM on 64-bit systems) or 64-bit plugins in 64-bit OpenMPT (for crash-prone plugins).

A plugin bridge is a separate process that OpenMPT communicates with. Plugins run in this process rather than OpenMPT itself, which is how the "bit border" can be overcome.
While there are non-free bridges like jBridge that do a great job, I have worked on my own, OpenMPT-specific bridge (which is going to work even better, because I can assume things about the host-side that e.g. jBridge can't) for a while and now it's actually in a somewhat usable state. "Somewhat" because it's still prone to crashes under some circumstances, it can freeze with some specific plugins and it's also not the fastest in the world yet. I'd currently consider this to be an alpha version. However, since the set of plugins I test this with is limited, I'm offering a test version for those who'd like to try the bridge out.

Current limitations:
- Inter-process communication is fast, but not the fastest in the world. Audio dropouts can happen even under light load. I will try to optimize this, but that's not a simple task. For example, I can play a tune with about ten plugins with 20ms latency using the plugin bridge, but at 10ms it produces noticeable crackles. Performance seems to be comparable to jBridge or even better, though.

What you have to watch out for and report back:
- Plugin GUIs may freeze when doing certain things. Please tell me which ones you've encountered that show this behaviour. Known plugins: ~~Synth1 (popup sliders), Electri-Q (preset switching), M1 (internal keyboard), ProteusVX~~
- Plugins may crash in some other ways not described above. Simply report those, too.

To automatically use the bridge for any and all plugins (useful during the testing phase), add the line "BridgeAllPlugins=1" to the [VST Plugins] section of your mptrack.ini. Otherwise, only plugins that need it (i.e. plugins with the "wrong" bitness) will use the bridge.

Happy testing!
Get current test builds from http://buildbot.openmpt.org/builds/ (both the 32-bit and 64-bit package contain both versions of the bridge.)

Saga Musix · March 18, 2014, 18:09:28

So... any takers? Noone wants to use their 64-bit plugins in 32-bit OpenMPT or vice versa?

The bridge is becoming more stable every day, and I'd say it's definitely usable with a good bunch of plugins (at least the ones I've tested).

Diamond · March 19, 2014, 00:17:20

Testing with the 64 bit version of OpenMPT and the 32 bit bridge, it seems to work fine with the few plugins I have tried so far. Genesis, Analog Warfare, polyIblit, Classic Delay, Classic Reverb, and FilterBox. I will post again if I experience issues with any others. However, I can only test for sound related issues. LOL any visual artifacts not so much. Unfortunately, there does seem to be quite a bit of crackling as you say, but for me it occurs at anything below about 50 ms latency.

Saga Musix · March 19, 2014, 00:26:41

I just updated the bridge a minute ago, should be a bit more stable and instance sharing for plugins like SideKick is now almost fully implemented (only the GUI toggle to actually enable instance sharing is missing).

Regarding the crackling, what system are you running this on (processor speed / cores, etc), and how many plugin instances per song do you have?

Diamond · March 19, 2014, 00:39:39

Windows 7 x64, AMD dual core 3.2 GHz, and 8 GB DDR2 800MHz. Only one instance per song. I like using VSTs, but I try not to get carried away.

Saga Musix · March 19, 2014, 01:21:42

Hm, really strange that it crackles even at 50ms then. I'd say my laptop specs are lower than that (Core2Duo 2.54 GHz), and as said, I don't have any problems with ten plugins at 20ms. Do you have anything else running in the background?

Anyway, the package above has been updated once again, now you can select for each plugin individually if you want to enable the bridge or not, and you can set whether all instances of the same plugin should share one container.
To continue with the testing, please add the line "BridgeAllPlugins=1" to the [VST Plugins] section of your mptrack.ini. This will force-enable the bridge for all plugins so that you don't have to do that yourself.

Diamond · March 19, 2014, 01:33:13

I do have some minor stuff running in the background. I suppose it is also possible that my Audigy 4 and it's cheap ASIO drivers may be the weak link, but even taking all of that into account, using the 32 bit version of OpenMPT without the bridge I can usually manage 10 ms with no problems. I will eliminate as many background processes as possible though to see if it makes a difference.

Diamond · March 19, 2014, 02:07:31

If I shut down all of my background processes, most of the crackling seems to disappear at about 30 ms. Although none of the VSTs I've tested so far are very CPU intensive.

Saga Musix · March 19, 2014, 02:43:13

Well, I'm not exactly sure what can be done to improve things even more if there's not much stuff running anymore. The problem isn't about how CPU-hungry the plugins are - you can have crackling output at less than 10% of CPU consumption. The problem is that the synchronisation mechanisms between OpenMPT and the bridge process add a lot of unwanted latency. It's difficult to get rid of this basic latency that's always there.

Also, I have updated the package above another time as the plugin selection dialog contained a really stupid bug (the config checkboxes were always greyed out).

Rakib · March 19, 2014, 13:02:18

I will be testing tonight and thanks alot!

Saga Musix · March 20, 2014, 20:03:39

Updated. I removed the periodic redraw code that caused some plugin GUIs to flicker. In some relatively rare cases. your plugin GUIs may now fail to recover from moving around or putting other windows in front of them, but this can be fixed by simply closing and re-opening the plugin editor. Also, keys are now passed back to OpenMPT so that you can trigger notes and shortcuts while the plugin GUI is focussed.

J.Ruegg · March 20, 2014, 20:19:00

Open mod plug in 64 bits!!!, oh yes, Open mod plug gets everytime better

. (will this support multithreading ?)

I have tryed OBXD and it loads well, but don't make any sound (I'm not sure if it was a mistake of mine, or a bug...)
And I have a module with OBXD 32, and have tryed to replace they with OBXD 64 and the Bridge has crashed 31 times(one time per instance).

My english isn't so good, But I hope you can understand.

Saga Musix · March 20, 2014, 21:07:09

Obxd produces sound and doesn't crash here. Have you tried the latest version of the Bridge and the Plugin? The bridge got updated a few minutes before you posted here, so the problem might already be gone.

And regarding multithreading, you can read my very recent answer about that topic here. While building a 64-bit version simply requires changing a compiler switch (and cleaning up the code beforehand), multithreading requires a lot of new code to be written. I know it could help a lot with fighting the plugin bridge latency, but frankly, it's not something I'm very much interested in or have time for at the moment.

Saga Musix · March 21, 2014, 00:45:58

As an experiment, I have raised the priority of audio processing threads in the plugin bridge (32-bit plugins only for now). Does anyone notice any improvements, or does it make things worse regarding crackling?)

Diamond · March 21, 2014, 01:16:12

I'm not sure I can notice much of a difference. It seems about the same to me at least.