ModPlug Central

I have not found a recent update on the forums about the status of using VST3's in OpenMPT.

I am asking because NI (Native Instruments) has dropped some VST2 versions of there plugins.  My plug-ins were 'updated' and the VST2 version was removed by NI's Native Access.

I also have Wave's plugins that are all VST3 that I would like to use.   

Does anybody know the current statues of VST 3 in OpenMPT ?

Any suggestions for Free/OpenSource VST 3 to VST2 host, if they make such a thing  ?

No, there are no immediate plans for VST3 support. Many plugin and host creators didn't make the move because it's a very flawed and at the same time very complex plugin interface. Some VST3 plugins secretly still export a VST2 interface, so even if a plugin claims to just be a VST3 plugin, you can try loading it into OpenMPT.

Will openmpt support Chinese in the future  :)

Please do not ask unrelated questions in existing threads; open a new thread for new questions please.

The current code base of OpenMPT doesn't allow for easy localization; it's most likely something that will happen when/if we switch to the Qt framefork for multi-platform support, as it has great localization support.

Any chance of reconsidering the anti-VST3 stance now that the VST 2.4 SDK is no longer available ?

There are still plenty of ways to write VST2.4 plugins and people will continue to do so (I'm not a lawyer but I think that a lot of things they claim with regards to what you are allowed to do with the VST2 SDK these days are legally questionable at best).
VST3 is a monster SDK that is terribly complex and noone but Steinberg asked for, and on top of everything, it's either proprietary or GPL-licensed (the latter is incompatible with OpenMPT's BSD license). As long as noone writes a more permissive implementation of the VST3 interface (that may very well be me but I have more important stuff to do at the moment), it's unlikely to happen.

Quote from: Saga Musix on November 08, 2020, 01:16:57
Some VST3 plugins secretly still export a VST2 interface, so even if a plugin claims to just be a VST3 plugin, you can try loading it into OpenMPT.

Do you have any examples of this actually working, it just saddens me that many new plug-ins is only available in vst3 format only.

I only tested a few VST3s but it worked with most of them. Lynx, Kx PolyMod, Roland Concerto, SquashIt are a few examples. Not sure if the latest changes to the VST3 SDK still allow for this, most of those files are a couple of years old (but even some plugins from that timeframe don't work so it's not just about age).

I dont get it, is modplug tracker able to load files ending with *.vst3?
I have not been able to do so.

VST3 files are just renamed DLL files. Some of them may contain the VSTPluginMain entry point (the function in a DLL file that identifies a plugin to be a VST2 plugin) in addition to the VST3 entry point. If OpenMPT can find that entry pointin the file, it can load it as a VST2 plugin. Otherwise it can't. It's really up to the plugin. Maybe all plugins you tried don't have this additional entry point.

I have found a VST host program that allows some major  functionality with VST3 and OpenMPT.

This can be loaded as a VST in OpenMPT, allowing for use (bridge) of VST3!

Element VST2/3 Host : https://kushview.net/element/ (https://kushview.net/element/)

Here is a download link for an older version, available without support :
https://github.com/kushview/Element/releases/download/0.41.1/element-win64-0.41.1.exe (https://github.com/kushview/Element/releases/download/0.41.1/element-win64-0.41.1.exe)

I was able to use my Waves VST3 delays, reverbs, and compressors and others with no problems.  VST instruments also worked!

thank you very much for element, it is exactly what I was looking for

Sad...

If you find it sad and this issue is important to you, you could help by asking Steinberg to license their VST3 SDK from GPL to SDK. That would be the most important step to have any chance for legal VST3 support as long as there are no third-party implementations (which are being worked on as far as I'm aware, but only for plugins at the moment and not for hosts, I think).
Until then, I'll try to get VST shell plugin support into OpenMPT 1.31, which would allow for vst3shell to be used with OpenMPT.

I dont think, Steinberg will listen me. But anyway new  free and open source plugins comes out in vst3 format mostly and is a future do you want it or not. I like vst2 better, but reality is other -for example I can't open SurgeXT(awesome opensource synth)  in Openmpt. And IMO not many OpenMPT users are hard commercial plugins users. So it is for future of Openmpt ;)

Yeah, they wouldn't listen to me either. The only thing that will work is if we all do it. Which is why I have a bit of hope for CLAP (https://www.kvraudio.com/forum/viewtopic.php?t=574861) to eventually replace VST3 as the go-to format for new plugins, but we'll see. It's definitely more likely at this point that OpenMPT gains CLAP or LV2 support than VST3.

I'm afraid that World War III is more real, than CLAP.

how does element have vst3 but we dont? what does getting vst3 entail exactly? If it is money to get a licence, maybe we should let people know who use ompt so we can all donate more. vst3 is just getting bigger and bigger, we have to get it at some time.

It has nothing to do with money. VST3 can be either licensed under a proprietary license agreement with Steinberg, or through the GPL license, but the GPL license is not compatible with OpenMPT's more permissive BSD license - it would essentially force OpenMPT's code to be released under the GPL license as well. It would be technically possible to use the proprietary license together with OpenMPT as far as I understand, but I'd rather not sign contracts with Steinberg that they can change at their will at any point in time (as they tried before to make VST3 developers stop developing VST2s by forbidding them through their contract to use the VST2 SDK).

Quote from: Saga Musix on February 18, 2022, 08:36:46
It has nothing to do with money. VST3 can be either licensed under a proprietary license agreement with Steinberg, or through the GPL license, but the GPL license is not compatible with OpenMPT's more permissive BSD license - it would essentially force OpenMPT's code to be released under the GPL license as well.

What about making a gpl add on, ... so something that is entirely separate from ompt, it is its own little bit of software, with a separate installation process etc, but it is kinda a thing you install that makes changes to your ompt... idk just spitballing here on how we might be able to press the erect middle finger againt the faces of the people responsible for all that crap.
So it wouldnt be a vst, or anything like that, just a separate 'add on' that can be installed by anyone who wants it, made entirely gpl, it finds your ompt folder/s and adds on vst3 support.
would that still leave us vulnerable to steinberg?
Another way to look at it or lable it would be like a modification or mod for ompt.

Quote from: Exhale on February 18, 2022, 14:40:26
What about making a gpl add on,

That would be legally possible.

HOWEVER:

• First, OpenMPT needs to get an abstract plugin interface at all. This is something that I would love to see anyway, as it would cleanup interfacing with current (VST2, DMO, custom tracker plugins) (and future (CLAP, LV2/DSSI/LADSPA, ...)) different plugin architectures. Currently, each plugin architecture is somewhat hard-coded ad-hoc, which is far from optimal.
• A proper abstract plugin interface will also maybe require or encourage a rewrite of the Plugin Bridge, working on the same API level as the abstract plugin interface.
• If any functionality ever gets added to that abstract plugin interface that is in any way VST3-specific, or derived from VST3, or makes particularly interfacing with VST3 simpler, this would make OpenMPT immediately GPL3.
• I will not touch any GPL3 code at all (for various reasons), so if OpenMPT gets VST3 support in any way, shape, or form without a strictly separately developed abstract plugin interface, OpenMPT looses 1 of its current 2 maintainers.
• This all would be a huge amount of work.

Quote from: manx on February 18, 2022, 14:56:04
3. If any functionality ever gets added to that abstract plugin interface that is in any way VST3-specific, or derived from VST3, or makes particularly interfacing with VST3 simpler, this would make OpenMPT immediately GPL3.
4.I will not touch any GPL3 code at all (for various reasons), so if OpenMPT gets VST3 support in any way, shape, or form without a strictly separately developed abstract plugin interface, OpenMPT looses 1 of its current 2 maintainers.
5.This all would be a huge amount of work.

The last thing I think anyone wants is our beloved ompt's code to become more restrictive which is why I suggested something entirely different, a separate bit of software, an add-on or a mod that isnt technically a part of modplug... so modplug stays the same, except maybe the other changes you suggested, the ones that are strictly essential but will have their own functions in base modplug, and then the add on / mod will have all the legal trouble if shit hits the fan as a separate bit of its own gpl software... and thus hopefully you would remain to work on the more permissive licenced ompt while whomever is brave enough to take on the mod / add-on can do so... maybe there could be a bit of code in modplug to make something like this more smooth, but it wouldnt necessarily have to have any of the vst3 code in it, surely it could be more general than that sort of like a plug socket to plug the mod into.

I am just busy looking up both licences and I will read through them, I am not a lawyer, but yeah I have heard people have a problem with the gpl3 licence not just here, but I think I have heard similar thoughts elsewhere, although I havent really heard much because I cannot program or understand law all that much even though every human is forcefully obligated to understand some law.
Either way I am hoping that my idea sort of paints a loophole we can hopefully exploit... I mean all sorts of software has add ons that arent the same licence as the base software, like photoshop has effects and stuff you can download that are made entirely by different people than adobe, some free some paid... minecraft has mods of various kinds, some free some paid and on and on... the lists are endless. They cant expect a mod / add on for software to force the base software into a new licence.

And yeah, I most certainly dont think a change like this would be anything but "a huge amount of work"... my only hope here is to put a sign board up for another rout that might be possible for those who are willing to take that road, a little bit of hope for those who would like to use vst3 in modplug to dream of at least. Maybe open a debate about if the base software's licence isnt touched, and a mod / add-on is created under its own licence, people like you, who I have full trust have perfectly respectable and legitimate objections wont have to compromise morals so that something that is looking like it might be essential can have a way to become a part of the ompt project, even as a separate project.

The way I picture it, you download modplug as normal, install it the way it is now... then if you want vst3 you download and install the vst3 mod, it makes a separate directory in your modplug folder, in which is contains everything it needs and, although when you are in modplug it looks like you are just opening vst3s like you would any other vst, any code that is needed for that to happen is executed outside of what is actually modplug.
I think I am making sense here... idk... I mean I have tried making my own mods for minecraft before, and those are just jar files if I remember correctly, but I used a bit of software that made the mod for me, I just used a visual interface. But that jar file wasnt minecraft, it was a totally separate and entirely optional thing to add to minecraft, and mojang could certainly not be held accountable for what that jar file would do.

Quote from: Exhale on February 18, 2022, 15:11:30
The way I picture it, you download modplug as normal, install it the way it is now... then if you want vst3 you download and install the vst3 mod

That "VST3 mod" could simply be vst3shell, which I already mentioned above, which is an existing product and the only thing it requires to implement is VST shell plugin support. It's a lot more realistic to happen anytime soon than any other sort of "official" VST3 support.

Quote from: Saga Musix on February 18, 2022, 16:52:11

Quote from: Exhale on February 18, 2022, 15:11:30
The way I picture it, you download modplug as normal, install it the way it is now... then if you want vst3 you download and install the vst3 mod

That "VST3 mod" could simply be vst3shell, which I already mentioned above, which is an existing product and the only thing it requires to implement is VST shell plugin support. It's a lot more realistic to happen anytime soon than any other sort of "official" VST3 support.

ok thanks, that clarifies things I guess. I guess I got carried away trying to suggest something that someone who might not even be a part of the present team could make on their own if they had the know how and the drive to do it... idk... back to making music again I guess.

As of r21326 (OpenMPT 1.32.00.22), there is support for VST2 shell plugins. This means that it is now possible to use the aforementioned vst3shell plugin as a way to get VST3 plugins into OpenMPT. It hasn't been tested much, and some plugins crash in vst3shell when unloading the plugin and the plugin's GUI was never opened (it also happens when doing the same in Renoise, so it's not a bug in OpenMPT's shell implementation). I will probably report that problem to the vst3shell author to see if it's a bug in the plugin. Please let me know if there are any other issues with it.

that is certainly exciting, I will look into trying it out as soon as I am able, there are a lot of vst3 vsts out there now that I have wanted to try for years, but I will have to remember their names.

One thing that might turn into a frequently asked question once more people use this: Whenenver a plugin is loaded through a shell plugin, OpenMPT updates its list of plugins that are contained within the shell plugin. Practically this means that if you have two VST3s A and B, and you decide to remove A from OpenMPT's plugin list, it will get re-added as soon as you load plugin B, which may look counter-intuitive at first.
I'm not sure if there's a good way to avoid this - it is of course beneficial that if the shell plugin contains any new plugins that the user sees them without having to do a manual rescan, and I think this convenience is more important than removing potentially unwanted plugins (why do you have the plugin installed if you don't want to see it in your plugin list?).

Quote from: Saga Musix on August 04, 2024, 22:07:35As of r21326 (OpenMPT 1.32.00.22), there is support for VST2 shell plugins.

This is excellent news!

I would like to give this a try when I have some time, but I had removed Visual Studio from my system a few years ago and cannot install and build because of a lack of HD space.

I have several Waves VST2  shells I could try.

Is there a way to download a pre-built (portable preferably)  version of 1.32.00.22 or greater ?

Latest test builds can always be obtained from https://builds.openmpt.org/ - alternatively you can update your main OpenMPT installation by setting the update channel to "Development" instead of "Release".

I gave this a quick try with Waves shell v11 and v14 both audio plugins and VSTi's.

They Worked!  I did not notice any issues.  I only was able to test for about 5 minutes, but all audio , knobs, and GUI worked!

Thank you!

That's great to hear :)

would adding a direct download within ompt (probably in the f12 setup - a button to press) for the latest vst3shell download and instant install into modplug compromise ompt's license, or be against the shell creators desires for its implementation? Unless it is already in the build in such a way, or already directly installed with r21326 (OpenMPT 1.32.00.22).

Edit : if it is possible then I would suggest it could be a toggle on install of ompt too. that way vst3 implementation becomes as seamless as is possible with our presently proposed system.

Most likely there will be a note in the FAQ (and maybe even the main website's feature overview) about loading VST3 plugins that would mention vst3shell, but it's unlikely that a closed-source component that has known issues (some plugins will crash on uninitialization, as mentioned before) and that we cannot vet for security issues and the like will be part of the OpenMPT installation, optional or not. In particular I'm not going to put my code-signing certificate on such a component, and that would be required to make antivirus software complain less about "insecure" downloads. It should be everyone's individual decision whether they trust a third-party component. We've done the same in the past with recommending VST2MID in the FAQ before OpenMPT had a built-in MIDI plugin.

Hello,

I just found this topic about VST3 support in OpenMPT. And I see there is now a recent development on this to allow to use the VST3Shell (found here : https://www.kvraudio.com/forum/viewtopic.php?t=565924).

I installed the latest development version of OpenMPT and put the content of that zip into C:\VST\VST3Shell. The VST is found in OpenMPT when I scan that folder. But I don't understand what to do now. The VST I would like to use is Surge, placed also in C:\VST\Surge (it's not found by OpenMPT as it's a VST3).

I was expecting the VST3Shell to have a GUI to chose the right VST3 but the button is grayed.

How do you use it and load your VST3 using this method?

Thanks to all

VST3 plugins generally need to be installed into a standardized location, which is C:\Program Files\Common Files\VST3 for 64-bit plugins and C:\Program Files (x86)\Common Files\VST3 for 32-bit plugins.

Quote from: Saga Musix on August 15, 2024, 16:15:11VST3 plugins generally need to be installed into a standardized location, which is C:\Program Files\Common Files\VST3 for 64-bit plugins and C:\Program Files (x86)\Common Files\VST3 for 32-bit plugins.

Thank you, it works now. I installed the VST using its installer instead of the zip file (I try to avoid installers when possible to put everything in a folder, that may be shared between programs). The Surge XT appears in the list and I can put it in FX1.

It seems to work as expected but I noticed something strange : the very first note is not played. Maybe this is plugin-related and not OpenMPT, or there is something that is sent to the VST to initialize it. If I put the note on the second row in the pattern, it plays. I didn't test much of it, this plugin is advanced and has a lot of parameters and presets.

Now, I know this is a workaround to use VST3 and may not be fully compatible with some instruments. And another thing is that this little DLL is not open source and is probably not maintained by its developer. But it's still better than nothing.

I cannot tell for sure but it is entirely possible that this is a bug in Surge and not necessarily related to the VST3 shell. There are quite a few plugins which don't expect to receive note-on data on the very first processing call (especially in combination with the "all sounds off" / "all notes off" MIDI CCs OpenMPT sends when stopping playback), since what OpenMPT does is a bit unusual compared to other DAWs (they keep running the audio all the time, even when playback is stopped, so it is extremely unlikely there to run into this situation).

I found a way (don't understand why) : setting the effect to "Arpeggio continue" (J00) on the first note played by Surge. It has something to do with the mode (Poly, Mono...). The VST works successfully for me.

That "works" because of a quirk of how the arpeggio effect is implemented: The arpeggio itself will not be doing anything, but on the first tick of the second row, OpenMPT will re-trigger the base note of the arpeggio. So essentially your workaround is exactly the same as simply playing the note on the second row instead of the first. If you need to be able to trigger a note on the first row, I would suggest to insert an empty 1-row pattern at the very start of your song and just not put any notes in it. Then start your track as usual on the second pattern.

Quote from: Saga Musix on August 16, 2024, 16:33:27I would suggest to insert an empty 1-row pattern at the very start of your song and just not put any notes in it. Then start your track as usual on the second pattern.

That's also a possible workaround  :) Now, my use of OpenMPT is mainly as a hobby and because it has the feeling of legacy trackers, like OctaMED for Amiga which I used many years ago. So I don't care too much as long as it sounds the way I like.

I have noticed a minor detail when using the shell VST's.    When instruments from VST shells are shown in the plugin manager, they are given a speaker icon instead of an instrument icon.  This happens with all of the Waves instruments. 

The logic that identifies instrument plugins works the same for shell plugins as it does for other plugins (at least one of these three conditions must apply: plugin must either report the "synthesizer" effect category, has no input channels or has the "effFlagsIsSynth" flag set).

If the Waves plugins should be registered as instruments but are not identified as such, then they might not be identifying themselves correctly as instrument plugins. All VST3 instruments that I have installed identify correctly as instruments, so this is not an OpenMPT bug.

Ok.   These are VST2 Wave Shells, if that makes a difference.  Maybe that is why they are not showing as instruments ?

I was able to test more today with the Wave's Plugins, and no issues!  Midi Learn worked as well.

As said, the logic always works the same. For OpenMPT it does not matter if the shell plugin is a wrapper around VST3 plugins or if it's a "real" VST2 plugin, as long as the plugin correctly reports one of the three attributes I mentioned in my previous post, it will be considered to be an instrument. Two out of three of those conditions you can confirm yourself: Which plugin category (folder) do those plugins show up in? Probably "Unsorted", I guess? And once you load the plugin, what does OpenMPT report for "I/O type"? Probably "Stereo-In, Stereo-Out"?

1.  OpenMPT shows an I/O type of No Input, Stereo Out for the Plugins when they are loaded

2.  They are listed under the "Instrument Plugins" in the plugin manager, just with a speaker icon vs a keyboard icon and they do function as they should.

Ah, I see now what the issue is; there's a cache flag that OpenMPT uses to determine whether a plugin is an instrument that was only updated once for the shell itself, but if the plugins inside the shell reported something different, it was not updated anymore. In this particular case, the shell plugin didn't claim to be an instrument plugin. r21525 should fix this issue. For plugins already loaded into OpenMPT's list of known plugins, the display can be fixed by inserting the plugin into a song - or you can remove the plugins from the list to force a rescan.

When scanning Waves folders, a lot of plugins are showing a message of OpenMPT PLugin Bridge 'File is not a plugin' "Do you want to try to load the plugin natively ? [YES] [NO].  Sometimes the error is 'Specified Module not Found'

Would it be possible to add a checkbox that would allow a default of yes or no for the remaining items to be scanned ? So  user intervention is NOT needed while scanning ?  I have to either hit tab  , enter , or click 'no' for about 100 plugins in one folder.  There are several Waves folders.  One Wave folder for Each 'Version' (Waves V11, Waves V12, ...)

EDIT:  I realized I can hold down "N" and that works, but an automated feature would be nice....

The code that handles plugin loading currently doesn't really allow for something like that - the scanning process shouldn't show any messages at all, but since they are triggered by some code much deeper down, it's not possible to suppress them. It's on my TODO list to rewrite this code eventually, but it's currently pretty low priority.

I have downloaded the latest development build -r21781 TEST amd64, and I have been unable to get the Waves Instruments to show up.

I am not certain if there is something I did not scan, or if they now do not load properly.  The last time I got them to load was with an older version that was around when I posted that all was working properly except the 'speaker' icon was showing instead of the 'synth' icon showing.

Any suggestions ?

I have scanned all the Waves plugins Version folders, and they cannot be found.

I have scanned all the folders with the .bundle files and they are not there.

Is there something else I am not scanning correctly ?

I would suggest as a first step to try to load the same plugins into a host again where you are confident they should work. I was unable to get them to work either when I simply downloaded the older versions and I think that might be because I did not actually have a license associated with those plugins, so they simply failed to load.
If that works, you could try going back to older test versions at https://builds.openmpt.org/builds/ and check if you can find the latest version that still loads them.

Has the behavior changed for scanning plug-ins ?  I remember being able to add a path, then new plugins were scanned for on restart.  It seems like the path settings are not getting saved properly either.   

Unless I am forgetting about a setting.....

No, OpenMPT never automatically scanned for plugins on startup. It would verify that plugins are still present, which might take a while and thus show a dialog if a lot of plugins are registered. But new plugins are only added when you explicitly add them in the plugin selection dialog. The VST plugin path specified in the setup dialog (https://wiki.openmpt.org/Manual:_Setup/Paths_/_Auto_Save) is used as the default path for this, but this path is never scanned automatically for plugins.

Quote from: Saga Musix on October 03, 2024, 08:57:19I would suggest as a first step to try to load the same plugins into a host again where you are confident they should work. I was unable to get them to work either when I simply downloaded the older versions and I think that might be because I did not actually have a license associated with those plugins, so they simply failed to load.
If that works, you could try going back to older test versions at https://builds.openmpt.org/builds/ and check if you can find the latest version that still loads them.

I have not had the time to check further into this.  One issue is there are multiple Waves shells, and scanning all of them with a different version of OpenMPT is very time consuming.  I tried a few versions back, but was unable to get them to work.  I don't know if that me not scanning the correct Waves Shell, or some other issue. 

Do you know of any way to view inside the Wave Shell so I can isolate which Wave Shell I need to scan specifically ? I tried to check with Reaper and Cubase, but I could not find the root shell file.

Unfortunately the only way to know what's inside a shell plugin is by loading it. OpenMPT only does a bare minimum of work when scanning plugins, so I would assume that just the process of loading the plugin file itself is already taking a considerable amount of time.

I have had some time to check and all is still working well with the Waves Shell plugins.