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.)
So... any takers? Noone wants to use their 64-bit plugins in 32-bit OpenMPT or vice versa? :P
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).
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.
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?
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.
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. :)
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.
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.
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).
I will be testing tonight and thanks alot!
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.
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.
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 (http://forum.openmpt.org/index.php?topic=5238.msg40956#msg40956). 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.
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?)
I'm not sure I can notice much of a difference. It seems about the same to me at least.
Here to report issues with KarmaFX Equalizer brided both 32 and 64-bit
It's only outputting NaNs when run in the bridge process. Not sure what might be done differently there, as really it's basically just a translation layer...
Little update: I managed to save one inter-process call per rendered frame when notes or other MIDI data (i.e. Zxx effects) is being sent to plugins - this should reduce the introduced latency and thus crackling a little bit, at least in theory.
Regarding the KarmaFX issue, I'm in contact with the author to find out what's going wrong.
Before I make a bug report, can someone else try the kirnu arp 32 version. The 64 bits version does not give any error.
(http://bildr.no/thumb/cUMxbmg3.jpeg) (http://bildr.no/view/cUMxbmg3)
http://www.kirnuarp.com/kirnu1/index.html
Quote from: Rakib on March 30, 2014, 18:44:57
The 64 bits version does not give any error.
Probably because you're not bridging it? ::)
I don't get any error messages, but the plugin simply hangs here. Probably because it's sending MIDI messages to the host, which is something I haven't really tested so far.
OK it works now!, Thank you for your great work.
And about multitreading... I normally use a lot of VST instruments, and its a bit difficult sometimes to work well(I normally bypass many instances), but If you don't have time it doesn't matter, Thank you Again!!!
that's great that its finaly 64bit.
but sad to say i get crackling in my tracks if i use 30 notCPUhungry vst's like mda,classic etc. and i dont get that if i use old 32bit version of openmpt. also modifying(or just opening the gui) the plugins makes a crackling effect.
actually i have amd phenom quad core 2.10 so i dont think its the best for 64bits.
audio driver latency is very big - up to 250ms but nothing. probably there is a mess with my PC, it become shitty..
could be the latency beetwen all the pluginbridge instances, like was written few posts back.
attached is what i see when comparing 32 and 64.
big up guys!!! :)
As explained before, the crackling happens because of the process synchronization and not because of high CPU load. Every bridged plugins adds a lot of latency and thus you will have to increase your latency and probably also update period settings in OpenMPT if you want to use the bridge. Naturally, this doesn't happen with the 32-bit version since it doesn't require a bridge for 32-bit plugins. And to quote the download page:
QuoteThe 32-bit version should run on all systems. Apart from a slight performance increase, there are some situations in which you can benefit from using the 64-bit version if you have an operating system that can run 64-bit programs:
- If you use no plugins, or most of your plugins are available as 64-bit plugins, use the 64-bit version.
- If you need more than 4 GB of RAM for plugins and samples, use the 64-bit version.
Hence: If you use a lot of 32-bit plugins, keep using the 32-bit version.
I use a lot of vst´s and have the latency set to 200 :)
And yes, i notice an improvement. (32 bit version. )
Parts where im using many heavy cpu vsts, used to crackle about 3 times per pattern, now only once, occasionally twice.
Thats though where im using a lot. (around 100.(though mostly low cpu vsts)
Multithreading would rock, but i understand. Probably someone who can and would have use for it themselves, will do it one day.
You are one of those people that really shouldn't use the plugin bridge. If you use dozens of plugins, you really should use them natively, not bridged.
Quote from: Saga Musix on March 30, 2014, 18:54:41
Quote from: Rakib on March 30, 2014, 18:44:57
The 64 bits version does not give any error.
Probably because you're not bridging it? ::)
I don't get any error messages, but the plugin simply hangs here. Probably because it's sending MIDI messages to the host, which is something I haven't really tested so far.
Is this something you could look at?
You don't want to know how many hours I have already spent trying to fix that one. It's frustrating.
Not sure why this one is a priority for you, though, since there is both a 32-bit and a 64-bit version, meaning that you can use a non-bridged version under all circumstances.
Ok just wanted to see if you had looked at it. But dont worry, I'll have 2 instances of modplug together 32/64 bit.
I only asked because I have used this plugins in so many songs and when you save a preset with this plugin in 32 bit version in doesnt load properly in the 64 bits version. But thanks for trying and I wish you a very nice day.
It might be worth telling the plugin author that the presets are not interchangeable between the two versions then. Maybe he's not even aware of it and it can be fixed on his side.
It's been a long time since any considerable changes have been made to the plugin bridge, but I spent the last three days to completely re-architecture it and hopefully fix most problems that resulted in crashes or hangs. So far all tested plugins work for me, including Kirnu which has been observed above as not working.
While a few smaller fixes will also make it into OpenMPT 1.28, the biggest chunk is only available in OpenMPT 1.29.00.28 or later, which can be downloaded from https://builds.openmpt.org/builds/ soon. Please let me know if there is still any trouble with specific plugins.
Quote from: Saga Musix on September 08, 2019, 16:26:36
Please let me know if there is still any trouble with specific plugins.
Nice, I start :) Full bucket plugins since FB series (FB-3100 for example ) first parameters on start playing pattern or song.
Please only report issues with the plugin bridge in OpenMPT 1.29.00.28 or newer. from what I can see, builds.openmpt.org currently doesn't have that version yet. Any older version still contains the old plugin bridge, please do not report bugs for those (I know it has issues). You will have to wait a few more hours until you can test this.
Also, to make it even more obvious: In this thread, report issues that only happen with the plugin bridge. This is not a general thread for buggy plugins.
I had a look at FB-3100 and there is no bridge-specific issues. However, I observed that the plugin sets its final output volume parameter (in the upper-right corner of the GUI) to 0 whenever an "All Sounds Off" CC message (CC 120) is sent to the plugin. OpenMPT sends this CC to all plugins (no matter if bridged or not), and this seems the the only plugin so far which has a questionable interpretation of that CC. It's just supposed to turn any playing sounds off, but not set the global volume of the plugin to 0. This is something that has to be fixed in the plugin.
In the future, please report plugin-specific bugs which have nothing to do with the plugin bridge on the issue tracker.
I contacted the author of FB-3100 - he confirmed that this is a bug in the plugin and will fix it soon.
Strange, I wrote to him 1 or 2 months ago about this bug, he send me away: " Note that this is no bug of my plugins..."...
And this bug persist in all newest plugins of him from FB3100.
It's no surprise that he didn't understand your bug report because you probably didn't tell him that it's MIDI CC 120 that's misbehaving. ;) It's not an issue that is easily reproducable with other hosts, since most of them probably don't send this CC, which automatically makes plugin developers go "well this is a host-specific problem then" (and that is an entirely understandable reaction). Anyway, I have received a test version of the plugin and was able to confirm that it fixes the issue, so updated versions of the plugins should be available soon.
Nice , TY.
I got notified that updates are now being rolled out for the plugins (not all at the same time though).
Back to topic: Just after I finished that rewrite of the plugin bridge, I did some more experiments and now there's another rewrite under way, with the following improvements:
- Clicking into plugin GUIs will no longer defocus the actual plugin window
- The last few possible hangs should also hopefully get eliminated
Thanks, again Saga, FB plugins now works fine except ModulAir, but, I hope update comming.
The new plugin bridge is now ready for testing (r12060 / OpenMPT 1.29.00.30, now available at https://builds.openmpt.org/). As mentioned above, this should fix any remaining stability issues and also offer visual improvements. Please test it, and let me know in this thread if there are any issues specific to the plugin bridge in that version (if the issue also exists if the plugin is not bridged, file a regular bug report instead).
With this update, bridged plugins should finally feel like first-class citizens in OpenMPT and behave exactly the same as native plugins, apart from the slightly increased processing overhead (and thus latency) - although while working on this improvement I realized how small the overhead really has become on a modern system, so even with low-latency ASIO and a couple of bridged plugins I was able to play my tracks smoothly without any dropouts.
Note: Since they are quite huge, these changes will sadly not make it into OpenMPT 1.28.
Hello, big part of my plugins slowed down loading and opening GUI. Especially ones with resizing or complex GUI. Crashes happens too.
Without the crash dump file or at the very least names of crashing plugins I cannot do anything to help you.
Nevermind, it's my dumb head. I always unzip new version in directory with previous version, and, I think, old bridge files conflict with new ones. Just cleaned directory and unzip, now all works better. Only new versions of Lynx and Aegis vsti's, scaned or added manually, disappears from VST list, after
restarting OPENMPT.
If newly added plugins do not show up in OpenMPT after a restart, it means that it didn't shut down cleanly and was unable to save its settings (if you didn't see a crash dialog, it may still be hanging in the background). I did try adding Xenobioz Aegis to OpenMPT and it did show up again after closing it.
Yes I see crash dialog after few minutes I quit Openmpt, now after repeating add Aegis, I see Openmpt still hang in processes after quiting. Try this with another plugin - all OK.
Tested another synth made with SynthEdit x64 - Kx Polymod. Openmpt hang in processes after quiting too.
I tries Kx Polymod x64 and it doesn't hang or crash here. I doubt your problems are bridge-related. In particular because the bridge is supposed to isolate OpenMPT from this kind of issue. If the bridged plugin was unloaded successfully without hanging, then it cannot be responsible for OpenMPT later hanging during shutdown. By far the most common source of this kind of problem are sound drivers.
Kx Polymod works fine in OpenMpt. Just after loading Kx or other syntedit made synth and closing openMpt, in task manager OpenMpt process not ending. I use Tascam US - 122 mk II card and dont have notable audio driver issues yet.
crash dump here.
The crash appears to originate from C:\Program Files (x86)\Image-Line\Shared\QuickFontCache_x64.dll which means that
1) It's not in our own code (some Image-Line plugin?)
2) The plugin was not inside the plugin bridge - the crash dump comes from the main OpenMPT process.
OpenMPT 1.29.00.31-r12125 64 bit TEST UNICODE
While playing with MauSynth on the MIDI keyboard and then composing a pattern of 8 notes on 16 lines in 1 channel with the computer keyboard, then playing the pattern.
The latency was 20 ms and no crackling occured, for as long as it lasted.
Okay, one last time - if the plugin window doesn't say "32-bit bridged" or "64-bit bridged", you are not using the plugin bridge and should thus not post your issue in this thread!
In your crash dump, MauSynth is loaded directly into OpenMPT, not into the plugin bridge. If a crash appears without using the plugin bridge, it should be reported as a regular bug (like you just did).
OpenMPT 1.29.00.31 testbuild
song, 3 channels, each channel routed to a VST,
1 big sample in an instrument,
various routing options on the VST lanes.
tested plugins, bridged:
SupaPhaser (32 bit)
VFlanger (32 bit)
TapeStop (32 bit)
OtiumFX BassLane (32 bit)
MJRotoDelay (32 bit)
XChorus (32 bit)
Freeverb2 (32 bit)
FreeverbToo (32 bit)
BassChorus_V22 (32 bit)
TDR Kotelnikov (32 bit)
BeyerDynamic Virtual Studio (32 bit)
Unbridged plugin tested:
DBlue Glitch2 (64 bit, unbridged)
No crashes so far.
I did crash Mausynth and Synth1 just on note play in the OpenMPT pattern editor.
Both plugins are 64 bit, so I guess there is no bridge issue.
Both gave an error c00000000005, and they were disabled by OpenMPT.
Also, I got Mausynth to crash twice on pushing play and pause on a small pattern.
The Mausynth plugin gave an infinite buffer repeat sound. I could close OpenMPT thereafter.
The crash was not easily one-step to reproduce, and I filed a bug report twice because I could not add the new crash dump to the old bug report.
I also tested the KORG Mono/Poly on play and pause. That seemed to work.
If OpenMPT bypasses the plugin then it didn't crash (yet). This is a known bug of the 64-bit version of Synth1 (I reported it to the plugin author some years ago but there have been no updates since). For this reason you must use the 64-bit version of Synth1 through the plugin bridge (make sure the appropriate checkbox is checked in the plugin manager) - the plugin bridge doesn't use the same security features as OpenMPT itself, so that issue doesn't happen there.
If MauSynth exposes similar behaviour (I couldn't see OpenMPT bypassing it after giving it a quick test), you might have to bridge it as well. Some plugins simply are buggy and there is nothing we can do about it.