[announce] VeeSeeVST Rack VST2 plugin

[subtlearts]

Thanks for your reply!

I guess I've misunderstood something then... I was under the impression that installing 3d party plugins to VSVR required changes the actual plugin dll - as above, where you've provided the new Submarine Utility modules by way of a folder plus updated veeseevstrack_effect and veeseevstrack_inst dll files in order to incorporate the modules. Is this not correct?

I have just tried to install another set of modules - from Alright Devices, not because I particularly need them but because it was the first thing I found in the VCVR store that wasn't already in your preinstalled set. Perhaps I'm missing something - that's quite likely, in fact - but copying that folder from the VCVR plugin folder into the plugins folder of the VSVR installation does not seem to get VSVR to load those modules. Same result with the Nysthi set, which are actually pretty cool. So it would seem something else is required.

If there is in fact a way for me to get VSVR to load new modules not in your statically linked list - free ones, for now - I'd be happy to know how to do it, but I haven't found that information in your documentation or in this thread. Again, apologies if I'm just too dumb to see it, and I also don't expect you to walk me through it. And to be clear, I definitely don't expect you to develop an entire alternative module store for VSVR, nor (obviously) to contravene anyone's license by incorporating protected IP into your distribution! But if there's a way to do it, and you feel like pointing me in the general direction of where to figure it out, I'd be grateful!

Thanks again...

[subtlearts]

modules could one day be added by the user? Possibly even paid, licensed ones

VCV Rack will be available as a VST2 and possibly VST3/AU/AAX plugin for around $99 shortly after Rack v2 releases later this year. It will be able to load normal VCV Rack plugins.

This is good news! Something to look forward to (and save some money up for!)

[bsp804]

I guess I've misunderstood something then... I was under the impression that installing 3d party plugins to VSVR required changes the actual plugin dll - as above, where you've provided the new Submarine Utility modules by way of a folder plus updated veeseevstrack_effect and veeseevstrack_inst dll files in order to incorporate the modules. Is this not correct?

The assumption is indeed wrong. VSVR also supports plugin DLLs. The reason why most of the modules are linked with the VST plugin is because the binary files are much smaller this way (so everything fits in an ~100mb archive).

However, the VSVR plugin DLLs simply are not compatible with the VCV Rack plugin DLLs due to technical reasons.

If you are mainly after closed source modules just buy vortico's VCV Rack VST once it's available.

The plugin feature in VSVR is mainly useful for power users who want to (and can) write their own modules.


Just keep in mind that some of the Rack modules / plugins use GPL code which may not be mixed with closed source binaries ("in the same address space"), which in particular concerns the following module collections:

• Bidoo
• Edge
• EH_modules
• JE
• LindenbergResearch
• rcm
• SonusModular
• Valley

I am going to move all of these to separate DLLs in the next release.

Anyone currently using any of these alongside closed source plugins in VCV Rack is probably also wearing an eye patch, or at least has a hook for a hand.

[vortico]

some of the Rack modules / plugins use GPL code which may not be mixed with closed source binaries

This is false if the users are doing the "mixing". Users do not violate GPLv3 by simply downloading and running plugins (see GPLv3 §2 and §9). And proprietary plugin developers do not violate other GPLv3 plugins' licenses because they do not convey those plugins.

What is true is that conveying GPLv3 plugins (e.g. by statically linking them into the same application and distributing the result) requires the coveyor to offer the application and all statically linked plugins in source form, which of course isn't possible if proprietary plugins are included. If you want to play it safe with people's GPLv3 plugins, either distribute all GPLv3 plugins separately OR distribute all proprietary plugins separately (or both).

[bsp804]

The GPL (not LGPL) simply is not a license that is suitable for mixing open and closed source code within the same application address space.

The GPL FAQ clearly states that a program and its plug-ins are considered a single combined program when

the main program dynamically links plug-ins, and they make function calls to each other and share data structures

which happens to be the case with Rack.

The only way for GPL and non-GPL plugins to legally co-exist would be to start a separate process for each plugin, then use pipes or networking for communication between the plugins and the host application.

My reasoning behind moving all GPL modules to separate DLLs (like in Rack) is that it will be up to the user to decide whether they will honor the GPL to its full extent, or not.

Last but not least: As long as people are using the software in private, everything should be fine, anyway (just like you are not required to release any modifications to GPL code as long as you don't publish the binaries outside of your organization).

[vortico]

Be careful with vague statements like "legally exist". You need a licensor and licensee attached to every statement about copyright permissions. Examples:
- A user (licensee) downloads a GPL plugin (by the licensor), downloads a proprietary plugin, then runs them together. The user has "unlimited permission to run the unmodified Program". OK
- Someone (licensee) conveys/distributes a package of object code containing a GPL plugin (by the licensor) and a proprietary plugin. The Corresponding Source of the object code is "the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require", meaning the entire body of source code of Rack and all included Rack plugins. You must "convey the machine-readable Corresponding Source under the terms of this License", so in this scenario you are breaking the license. BAD
- Someone (licensee) conveys object code of a GPL plugin (by the licensor) without including object code of proprietary software. If you "convey the machine-readable Corresponding Source under the terms of this License" which is normally handled for you at the licensor's GitHub repo, then the GPL allows this. OK

Also be careful with the GPL FAQ as it is just as vague/sloppy in many places. Refer to the GPLv3 as the first source. The FAQ is meant to be easy to read but leaves out important contextual details. For example, "When is a program and its plug-ins considered a single combined program?" is a good question, but what situations would you need to know what a "combined program" is? Only when determining what the Corresponding Source of the conveyed object code of a GPL work.

[bsp804]

I'm not really sure whether it makes a difference if a GPL plugin is distributed separately, or comes from the same source (e.g. via a unified installer) as the rest of the distribution (including the host, which may be closed source).

From what I gathered, as long as the host does not depend on the GPL plugin (i.e. functions without it), and the GPL plugin does not need to statically link any closed source libraries, the GPL requirements should be fulfilled.

In this case: Rack works w/o any GPL plugins, they are just optional 3rd party extras, so all should be well.

In case the host (e.g. your Rack v2 VST) is closed source, you have to make sure that all code that a GPL plugin needs to (statically) link to (Rack.lib) is available as source code under a license that is compatible with the GPL (e.g. MIT / BSD), i.e. the plugin must not link to any closed source code or it would violate the GPL.

Regarding the GPL FAQ: You are certainly right that this is not a legally binding document. Perhaps the description of what exactly constitutes a "single combined program" needs an update.

My guess is that they wanted to make it clear that it would not be ok to for example take GPL code, wrap it in a DLL, create a simple closed source UI that simply calls the DLL and relies on it for all the "heavy lifting".
On the other hand, it would not make any sense to require an application to become GPL just because it supports plugin DLLs (and has a GPL compatible plugin interface), and someone has written a GPL plugin for it (this part is missing, I think).


By the way (something entirely different): For the Linux port we ran into some issues with the GTK+ based "osdialog" implementation (it does not work in hosts that also use GTK+).
I'm currently thinking about writing a replacement for it but I don't want to reinvent the wheel so I'd like to know if you have already solved this issue ?

[MUSICOELECTRO]

installing 3rd party plugins is as easy as copying a folder (basically the same procedure as with many VST plugins).

Excuse my ignorance but i have a question: this comment means that every free plugin avaiable for VCV can be "copied and pasted" in the VSVST folder and works?

or: What is it that I did not understand well?

[bsp804]

this comment means that every free plugin avaiable for VCV can be "copied and pasted" in the VSVST folder and works?

no, it simply means that people can extend VSVR with plugins but they'd have to write their own ones or port / recompile VCV Rack plugins.

[vortico]

Looks like we're on the same page with distribution. I just wanted to refute "Anyone currently using any of these alongside closed source plugins in VCV Rack is probably also wearing an eye patch".

I'd like to know if you have already solved this issue ?

You haven't said what the issue is so I don't know if I've solved it.
I'm really receptive to bugs on the osdialog issue tracker. I've made several updates in the past few weeks that could have changed/fixed things.
I might also be interested in a pure X or GLFW/OpenGL osdialog implementation to remove the GTK+2 dependency entirely for Rack. I don't know, post your ideas.

[subtlearts]

this comment means that every free plugin avaiable for VCV can be "copied and pasted" in the VSVST folder and works?

no, it simply means that people can extend VSVR with plugins but they'd have to write their own ones or port / recompile VCV Rack plugins.

Great, this confirms what I had gleaned from the discussion above, and I think I understand everything fully now. Thanks for the clarification! I will continue to use VSVR and explore VCVR as they are for the moment, since I'm not a coder and have enough on my plate already...

[bsp804]

Looks like we're on the same page with distribution. I just wanted to refute "Anyone currently using any of these alongside closed source plugins in VCV Rack is probably also wearing an eye patch".

The GPL FAQ certainly conveyed that impression. It can't be right, though, since that would invalidate all other existing GPL-licensed VST plugins.

You haven't said what the issue is so I don't know if I've solved it.
I'm really receptive to bugs on the osdialog issue tracker. I've made several updates in the past few weeks that could have changed/fixed things.
I might also be interested in a pure X or GLFW/OpenGL osdialog implementation to remove the GTK+2 dependency entirely for Rack. I don't know, post your ideas.

The issue is described here.
I'm currently thinking about implementing a C-library that invokes "zenity" to display the dialogs. Zenity is also based on GTK+ so from a user point of view nothing would change, i.e. the dialogs would still look the same.
I'd also add an osdialog_zenity.c implementation and the C lib would be MIT so you could use it in your VST, if you want to.

[Funkybot's Evil Twin]

bsp804, is every new install of this supposed to reset our favorites? That's been my experience. I'm assuming it's the settings.json in the distribution that does it. If so, would it be possible not to include that in future distributions so people like me don't keep overwriting our settings files with yours? I'm assuming if none exists, VCV would create a new one.

I appreciate everything you do and ask quite humbly just to make things a bit easier on me. I'll try to avoid installing that file in the future and see if that solves for it.

[scook]

I'm assuming it's the settings.json in the distribution that does it.

Yes, setting.json stores favorites under moduleBrowser.
I do not copy this file when overwriting the plug-in folder.

Also would like to the the folder name changed from vst2_bin to bsp because that is how the plug-in manufacturer is identified.

Although both are easy to live with as is.

[vortico]

The GPL FAQ certainly conveyed that impression.

That's why I think the FAQ is poorly written. The GPLv3 releases all copyright limitations for using the software in section 2: "This License explicitly affirms your unlimited permission to run the unmodified Program." And a redundant clause in section 9: "You are not required to accept this License in order to receive or run a copy of the Program."

If you release osdialog_zenity.c under osdialog's CC0 license, I'll add it to the repository. Or just fix osdialog_gtk2.c and send a PR.