Distribution of plugins

[Alexander Larsson]

On Thu, Jan 10, 2019 at 1:13 PM Alexandre Bique
<bique.alexandre at gmail.com> wrote:
>
> Hi,
>
> I am wondering how the distribution of plugins works with flatpak.
>
> Let's say I have a plugin interface called MyPlug.
>
> There is one proprietary application AppA which is available in
> flathub and can use plugins providing MyPlug interface.
>
> Again an other proprietary application from a different manufacturer,
> AppB which uses those plugins.
>
> And finally a plugin PlugC which is proprietary.
>
> How can we distribute AppA, AppB and PlugC which are all coming from
> different companies and flatpaks.
>
> How can AppA find the plugins of MyPlug interface?
>
>
> The concrete case for this question is Bitwig Studio [1] a digital
> audio workstation, and a virtual synthesizer plugin, implementing both
> VST and VST3 interface, Diva [2].
>
> As of today, VST3 can be found in:
>
> 1           User               $HOME/.vst3/
> 2          Global              /usr/lib/vst3/
> 2          Global              /usr/lib32/vst3/
> 3          Global              /usr/local/lib/vst3/
> 3          Global              /usr/local/lib32/vst3/
> 4          Application         $APPFOLDER/vst3/
>
> I believe we could "symlink" all the vst3 into the app folder. But a
> set of things needs to be standardized from flatpak point of view
> right?

Hmm. This is not ideal, as most of these are in the runtime (/usr)
which is outside the control of the app, or the users homedir which we
ideally should not mess with..
What you want is an application plugin, and those will by necessity be
under /app.

So, given the above we need to use 4, i.e. $APPFOLDER.

Here is how you do this. First of all, ship with your application an
(empty) directory called say /app/lib/vst-plugins. In this location
you will declare an extension point. Flatpak extensions come in two
forms, "regular" or "subdir". Regular ones just has one implementer,
and will just be mounted at the extension point. subdir ones will
match several plugins, each getting mounted on top of a subdirectory
named by the plugin name.

In this case we want a subdir extension point, so we use with something like:

"add-extensions": {
  "net.steinberg.Plugin.VST":  {
    "version": "vst3",
    "subdirectories": true,
    "directory": "lib/vst3-plugins",
    "merge-dirs": "vst3",
     "no-autodownload": true,  // Don't automtically download all plugins
     "autodelete": false // Don't automatically uninstall with the
app, other apps could use the plugin
  }
}

This defines a subdirectory plugin called net.steinberg.Plugin.VST.
Normally an app plugin would be called something like
com.bitwig.BitwigStudio.Plugin, but since VST is a generic plugin
format we'll make the name something other applications can use too.
This sets the version of the plugin to "vst3", which means the branch
of the flatpak extention has to match this. Optionally one could
imaging encoding the vst/vst3 difference in the name of the extension
point too.

What this means, is that if you have installed a flatpak runtime with
the id net.steinberg.Plugin.VST.foobar and branch vst3, then when you
run your app, the contents of that flatpak will appear under
/app/lib/vst-plugins/foobar in the sandbox.

Now, this is not *quite* enough, because this format for the plugin is
not how vst3 plugin works. My guess is that it just looks for a
directory of .so files? This is why I added the "merge-dirs" option.
It causes flatpak to also create a subdirectory called
/app/lib/vst-plugins/vst3, and put in there symlinks to all the files
that are in /app/lib/vst-plugins/$PLUGIN/vst3 (for all plugins).

You can then add --env=APPFOLDER=/app/lib/vst-plugins/ to finish-args
to make the app find these plugins. Or, alternatively if you have
other things in $APPFOLDER, make it something else, and then have a
vst3 symlink from it to /app/lib/vst-plugins/vst3.