Removing Vult Modules from the distribution

[modlfo]

Hi,

sorry if this sounds bad but as author of the Vult modules I would like you to remove them from the distribution. Here are the reasons behind my request:

• The published source code is quite old and does not sound as good as my newer releases. That can be detrimental for me because people using these version may think that that’s how my actual modules sound.

• Vult is my trademark, and in the license I specify that it’s not possible to release any other software than the one I support with that name. Same reasoning as before, I cannot provide support for users of these versions.

I hope you understand my reasons and comply to my terms.

[bsp2]

I guess some users won't be too happy about this but I've seen that you've removed all your source codes from GitHub a while ago (I found a copy of your sources in a forked repo on GitHub in case you're wondering).

Your modules also required some non-open source graphics assets so I've now removed all your source and graphics files from this repo and the new binary plugin release does not contain any VultModules binaries anymore.

[modlfo]

Thank you!

have you devised any way of using the binaries of any other closed source modules? Is it technically possible?

[bsp2]

Unfortunately that is currently impossible w/o some (relatively minor) changes the plugin interface and a recompilation of the closed source add-ons.

The problem is that Rack exposes several global variables to the plugins.

In order to create a multithreadable and multi-instantiable plugin, I had to replace these global variables and all the references to them by thread local storage pointers to structs (see global_pre.hpp, global.hpp and global_ui.hpp).

At least on Windows, these TLS pointers cannot be exported to dynamically loaded modules.

While only few of the add-on modules reference these global vars directly, they all link with the Rack library, which contains many references to them.

In case of the plugin version of Rack, there are basically two threads:

• the UI thread (created when a plugin is instantiated, see vst2_main.cpp (startUIThread()))
• the audio rendering thread (created by the DAW)

Both threads need to see the correct TLS pointers for each plugin instance (each instance has its own TLS dataset that is allocated when the VST effect is created, see vst2_main.cpp and look for setGlobals()).

In order to support dynamically loaded plugins, the Rack interface would need to be changed so that a pointer to the TLS/instance dataset is passed to a plugin when it is being initialized. The plugin would then (immediately) set its TLS pointers (before calling "add model"), similar to how setGlobals() works.

When audio needs to be rendered, the TLS pointers need to be set again (for the audio thread). In order to avoid having to do this each sample frame, the plugin could pass a callback function to the Rack engine which would be called before a new chunk of samples is rendered.

The good news is that when I waded through the hundreds of (open source) add-ons, I already modified them in a way that would allow this feature to be added without going through all the modules all over again.

Take a look at the Template project for example. As you can see, the updated version now uses macros (RACKPLUGIN*, defined in plugin.hpp), i.e. it is now possible to change the macro implementation and hereby update all modules (by simply recompiling them).

The RACK_PLUGIN_INIT and RACK_PLUGIN_INIT_ID macros would need to be extended in a way that passes the TLS dataset pointer to the plugin, which then updates its TLS pointer (for the module init / UI thread).

RACK_PLUGIN_INIT would also need to define a function that updates the DLL's TLS pointer for the audio thread. RACK_PLUGIN_INIT_ID would then pass a pointer to this function back to the Rack engine (e.g. by storing it in the Plugin* that already gets passed to the init function). The engine would then call the function at the beginning of VSTPluginProcessReplacingFloat32().

I am thinking out loud here but I think it could work (from a technical point of view).

[bsp2]

It worked. The new release now supports dynamically loaded plugins.

If you want to, you can now build and distribute your modules as "VeeSeeVST" plugins however you see fit (closed source and / or for money).

[modlfo]

I'll give it a try in a few weeks because I don't have access to my windows computer.

[bsp2]

If you want to save yourself some time, you can use the precompiled plugin SDK for Visual Studio 2017 (i.e. you don't need to check out the repository, and you can use the IDE for developing your plugin(s)).