VST3 support

[CapRat]

Awesome Plugin! Could you support vst3?

[falkTX]

Although I do not like VST3 as an API, it is better than VST2 in some ways. When an opensource host (that is not a demo tool) is released with VST3 support, I will begin adding such support in DPF. Until then, interest is pretty minimal on my side

[CapRat]

Thank you very much, for the fast Answer. Until now i think Reaper and Tracktion Waveform can load vst3 Plugins and ardour will support it in near Future. Looking forward how things will develop. Thanks for your nice and amazing Work!

[falkTX]

Tracktion/Waveform is based on Juce, so its VST3 support does not apply to Linux.

Let's see when VST3 becomes more popular, for now it is not that much at all...

[falkTX]

VST3 support has "started" in the travesty branch. Since the VST3 SDK is, in my opinion, quite awful and still has licensing issues (you either release as GPLv3 or sign a deal with a company with bad history) a reimplementation of the core headers was done. This reimplementation is in pure C, contrary to the official one that is C++.

While the C headers should be enough to have a fully working plugin, there is very little to see when it comes to DPF. We can already build a VST3-compatible object with DPF, but it will have no plugins inside. I am 100% focused on finishing the pugl/graphics update, and only after this will tackle the VST3 stuff.

[noisecode3]

That's great, I think I like DPF not to include steinbergs SDK. its more punk that way

[jpcima]

Some thought about current work in develop:

• GetPluginFactory should be V3_API (aka stdcall)
• UTF-16 support seems like it will be needed at some point. Can these helpers go in DISTRHO::String? Also, strncpy seems duplicated in the implementations.
• This is a stable and no-dep library for UTF conversions. Can we namespace it into DISTRHO and reuse it? https://github.com/boostorg/locale/blob/develop/include/boost/locale/utf.hpp
• Can we accept use of <atomic> for the reference counter?

[falkTX]

We should use strlcpy instead of strncpy, but that function is not very wide-spread/supported yet.

It makes sense to have string related functions in DPF extras, some could go in the String class yes (so we can create regular utf-8 string from a utf-16 one, and export the string class buffer to a utf-16 thing)

I will have to see about boost license, needs to be compatible with MIT/ISC/BSD and allow commercial use. If that is the case, then all fine.

atomic is welcome, that was my plan for the ref counter.

at some point it will make sense to update DPF to use C++11 overall, but focus right now should be to get develop branch up to speed with the old master one. Needs a lot of testing with existing plugins to make sure nothing broke. I think I will just do the work for SVG support, and then stop adding more features/APIs until a stable version is reached. is there anything else critical we are missing? (I know of the DSP->UI message passing situation, but due to time constraints and focus, I will leave that for later)

[jpcima]

is there anything else critical we are missing?

Not anything to call critical, but VST3 has definitely some nice-to-have.

• dynamic parameter names, and key names
• the note expression interface (host-supported MPE)
• accessing the plugin type, for display purpose in the editor
• the plugins wrappers VST3 to AU/AAX of Steinberg; they are part of public.sdk not covered by GPL but 3-clause BSD
• the MIDI learn

[falkTX]

is there anything else critical we are missing?

Not anything to call critical, but VST3 has definitely some nice-to-have.

* dynamic parameter names, and key names

Is this more standardized compared to VST2? On VST2 it was a mess due to updateDisplay opcode not being well documented.

For key names, is this alike midnam?

* the note expression interface (host-supported MPE)

This is a tricky one. Not even LV2 has this right now.. I dont have experience with MPE or MIDI2, so this part needs to be done by you or someone else.

* accessing the plugin type, for display purpose in the editor

I have always been a little against this. The plugin should work the same way no matter the exported format. Would it be enough to add this on the UI side? To prevent plugin/DSP behaviour changes on that side.

* the plugins wrappers VST3 to AU/AAX of Steinberg; they are part of public.sdk not covered by GPL but 3-clause BSD

We can only use those if we target VST3 SDK, correct?

* the MIDI learn

Already possible with the "request parameter change" API. https://distrho.github.io/DPF/group__PluginMacros.html#ga5a33bc5567795bdbbaab32313fabc652

[jpcima]

Is this more standardized compared to VST2?

Yes, see kParamTitlesChanged

For key names, is this alike midnam?

It's about it, except the names are defined per-program. There are also keyswitches, which afaik midnam doesn't have.

Would it be enough to add this on the UI side?

Beside the display, this is useful for keeping logs in case of errors. The plugin type is definitely a piece of information that is desirable to know, and either side would be interested about accessing it.

We can only use those if we target VST3 SDK, correct?

Unless rewriting it in travesty, certainly it will still depend on some GPL parts of VST pluginterfaces. The software is a wrapper which dlopen's the VST3 as a sub-bundle of AU/AAX. The wrapping bundle has just to be filled with the static meta-info of the particular plugin.

[lucianoiam]

• accessing the plugin type, for display purpose in the editor

+1 on this. I am using a cheap hack in a project to workaround the lack of this information. UI only is enough.

[falkTX]

Some news on this. Initial working VST3 support is on the develop branch, in a way I consider alpha at the moment. Everything that is crucial is implemented, from audio, midi, time position, parameters, programs, state, latency and gui. Not recommended to release anything based on this, there are memory leaks and the GUI only works on Linux at the moment (and known to break REAPER due to not plugging into the host runloop yet)

As previously mentioned this uses custom C-compatibly API headers instead of the official sdk, so that we can have commercial plugins not tied to steinberg. So there is a lot of boilerplate to implement some things the sdk already does, but the separation is as clean as it can be. The C++ important bits are defined first, and roughly after the middle of the cpp file you find the interface boilerplate. That boilerplate is still pretty unclean, but works for now for testing.

Worth noting that there is a clear DSP / UI separation for this VST3-compatible DPF implementation. Instead of the UI having direct access to the DSP side and just calling functions, everything is passed through a VST3 "connection point" as messages. There is something in place to support hosts that do not provide the "connection point" interfaces, so everything still works there too.

Also, even though the VST3 code is now >= C++11 eventually the final one should be C++98 compatible (as one of my targets for DPF, I am still hesitant on this...). But while testing for now, stuff like lambdas and auto is fine. Once we have the base component refounter working well plus the linux run loop, we can begin the cleanup of the boilerplate code.

I have a few things pending now that I need to dedicate some attention to, so will leave the VST3 stuff aside for a few days. There are TODO items on both the VST3 Plugin and UI code files, so if you want to contribute have a look at those. Not all interfaces are in the C headers yet, but there is no real point on adding them all if we are not going to use them. But a few like IMidiMapping will need to be added still. Specially useful to do right now would be adding win/mac support (integrating into the native run loop) plus finishing the MIDI <-> VST3 event conversion.

[lucianoiam]

Thanks for all the hard work on VST3, this is awesome!!. Already integrated it in my project and it is working good so far. Added VST3 to all project's examples targets so the feature will be regularly tested.

Would you consider adding a function in the framework that returns a path to the plugin Resources path? it could be useful for plugins that need to load built-in files during runtime. Some formats do not define a standard resources path but that could be addressed by a default argument, something like:

getPluginResourcesPath(String fallback)

• For VST3 (all platforms) and VST2 (Mac bundle), it would return $BUNDLE_PATH/Contents/Resources
• For LV2 return dirname(so_path) + /fallback
• For VST2 on Linux and Windows return dirname(so_path) + /fallback
• For standalone return dirname(exe_path) + /fallback
• For other embeddable formats dirname(so_path) + /fallback

Notes:

• The fallback argument avoids forcing a convention for plugin formats that do not define a standard resources dir. In case of my plugins I use NAME-lib
• Not sure this should be named "resources" or "library" ... assets and binaries could be mixed into a single place ... actually my function is called getLibraryPath(), convention somewhat inspired by macOS. Minor thing though.
• fallback could be absolute or relative depending there is a starting / ... useful if the plugin comes with a installer that copies resources to a different directory other than the so/dll
• Not sure this function "does too much" but you get the idea

Currently I use a complicated runtime approach that determines if plugin code belongs to the main executable or dynamic library (for determining plugin vs standalone) and then looks up symbols in dylib for determining plugin format in the plugin case and hence the correct relative resources path. See Linux, Mac and Windows

It works but with a function like proposed above that relies on preprocessor macros all this runtime black magic would be unnecessary.

[lucianoiam]

Not sure why I wrote "preprocessor" but certainly this is easier to address at a framework level

[falkTX]

Would you consider adding a function in the framework that returns a path to the plugin Resources path? it could be useful for plugins that need to load built-in files during runtime. Some formats do not define a standard resources path but that could be addressed by a default argument

Considering I have needed this 2 times already, sure thing! Please open a new ticket so we move the discussion there. The latest code I did for this is at https://github.com/DISTRHO/ProM/blob/master/plugins/ProM/DistrhoUIProM.cpp#L43 which works for both win32 and posix. (for win32 the DllMain function is required)

I cant place this as a generic function though, because the place where such files are depends on the plugin format. For standalones it should return the current dir (where it resides in), for LV2 it should be the actual lv2 bundle regardless of OS, for VST2/3 mac it should be ../Resources relative to binary, for VST3 non-mac a similar thing while VST2 non-mac needs to be current dir too.... this whole thing is messy!

I am against providing a fallback though, you can easily just wrap around whatever DPF function provides to have a fallback in case DPF returns null/empty.

[lucianoiam]

Done. That would be very helpful; agree on skipping the fallback and keeping the function more generic. Continuing on #332

[falkTX]

I am back on taking a look at VST3 and DPF again. The first thing to handle is full midi input and output. There is no other way to do this but to expose all possible CCs as parameters... I find it very wasteful, but it is the general approach, juce has gone this way too.

[falkTX]

There is progress, the biggest hurdles have been overcome now. Things are generally working, including UI with the proper X11 host run loop or regular idle on macos and windows. I would consider this now as beta and ready for testing, with some caveats:

• MIDI CC is not being handled properly yet
• audio buses still need to be setup properly (do not try to load plugins with CV/sidechain ports, they will just crash)
• Regular notes + MIDI events (CC, pitchbend, aftertouch) is not sorted
• UI support is barebones, still need to add in details for host-side resize, size constraints, key and wheel handler

See the TODO items on the VST3 Plugin and UI code files for a more complete list of WIP stuff.

General feedback/testing is very much appreciated now. Still not good enough to release plugins with this officially, there are way too many debug prints, but a great start IMO. I also only tested on a couple of hosts (carla, renoise and bitwig).

[SeleDreams]

I've been reading this discussion and it's actually an interesting read when i've seen posts about licence, i didn't know DPF actually relied on its own implementation of VST2 and VST3, since DPF is under ISC licence, does it mean that if a VST plugin is made with DPF will it be bound by the terms of the original vst sdk (gpl or proprietary) or will it be bound only by ISC ?

[falkTX]

I was hoping that would be clear by the LICENSING.md file... but basically:

• for vst2 it is either GPLv2+ or steinberg proprietary deal
• for vst3 it is 100% ISC yes

[SeleDreams]

I was hoping that would be clear by the LICENSING.md file... but basically:

• for vst2 it is either GPLv2+ or steinberg proprietary deal
• for vst3 it is 100% ISC yes

I see thanks would be nice to have an ISC version of vst2 but tbf vst3 is future proof anyway and most mainstream daws support it, only a few like zynewave podium and LMMS (tho for lmms i think they're working on it) don't

it's already great to have a permissive way to create vsts, i think it could maybe be made clear from the readme since people often just read the ISC licence and don't see the details

[falkTX]

And to be clear, the VST2 plugins being GPL is due to the free vestige header being under that license as well. So as typical for GPL, the license propagates to DPF when we use it.

For VST2 I do not think it is worth spending too much effort into now. It is still used a lot, but more like in a legacy compatible way. VST2 has many bad things that make it difficult to work with, maintenance-wise..

[SeleDreams]

And to be clear, the VST2 plugins being GPL is due to the free vestige header being under that license as well. So as typical for GPL, the license propagates to DPF when we use it.

For VST2 I do not think it is worth spending too much effort into now. It is still used a lot, but more like in a legacy compatible way. VST2 has many bad things that make it difficult to work with, maintenance-wise..

yeah so I think for my plugin I'll just use vst3 and lv2 (on another note I just opened an issue since seems like there's an undefined reference issue on windows)

[mxmilkiib]

Where might things stand today? Also, in relation to https://github.com/ryukau/LV2Plugins/blob/master/docs/dev_note/code_walkthrough.md#difference-to-vst-3-repository?

[falkTX]

80% done I would say. Under certain conditions the plugins already work well.

So far I know of only 2 breaking limitations:

• using sidechain or CV ports, where they are treated as optional buses. this is not yet fully implemented, hosts will either refuse to load such plugins or crash doing so
• dsp/ui separation breaks a few hosts (ableton and steinberg stuff)

[falkTX]

We go up to 90% done now, we can consider it to be release candidate status. the audio buses stuff is now done, and dsp/ui separation was fixed.

there are a few things that I need to check, but it is not only for vst3. later on I will create a few plugin examples so we can verify and test all of DPF API.

[falkTX]

parameter handling is improved now, those should be more reliable now.

2 things I see still to fix:

• audio bus with non-usual setups (multi out, cv etc)
• time information in FLStudio (values jump a lot, but now that parameters are fixed we can use d_info example plugin for debug)

[falkTX]

both issues have been resolved now. CV is still incomplete, as it does not scale and offset values. But I have not seen a single DAW/Host that supports VST3 CV ports yet, so leaving it at that until there is at least 1 place we can test the implementation on.

And with this I consider the VST3 format ready for use, say release candidate status. Any leftover things should now go into individual tickets.