Cabbage Logo
Back to Cabbage Site

Distributing plugins on Windows

#1

Distributing plugins on Windows is not as clean as MacOS. The best installer for Windows is probably NSIS. A quick tutorial on how to create a Windows plugin installer can be found here.

The tricky part with Windows is decided what to include, and how to include it. You have several options. The handiest things to do is to use a folder called C:/ProgramData/CabbageAudio/PluginName to hold all your resources, .csd files, images, samples, etc. When your Cabbage plugin loads, if it doesn’t find a matching .csd in the same directoy as the dll it will search there.

How to include Csound

  1. Distribute csound64.dll with your plugin. If you are not using any plugin opcodes this is clean. You should place it into the C:/ProgramData/CabbageAudio/ folder. You then need to add this folder to your system path. This NSIS script does this. It can be easily hacked to suit your needs

  2. Optionally distribute all of Csound with your plugin. This is what I do with the Cabbage installer. You can see on this line I add the entire contents my Csound_x64 folder to the installer:
    https://github.com/rorywalsh/cabbage/blob/develop/Builds/VisualStudio2017/CabbageCannonicalInstaller.iss#L65
    I then have to update the system variables so that Csound is properly installed:
    https://github.com/rorywalsh/cabbage/blob/develop/Builds/VisualStudio2017/CabbageCannonicalInstaller.iss#L75-L76

Both of this approaches have their problems. Method one works fine so long as users don’t have Csound installed. If they do you had better hope it’s the same version used by your plugin, Otherwise things will break. Either your plugin will not work, or their Csound install will not work.

Method two is a little safer because you can offer the option of installing Csound alongside the plugin. If users have Csound installed your plugin will work without having to include any Csound dlls and then can opt out of the Csound installation. If not, they go ahead and install Csound. If they update Csound at a later date it won’t break your plugin.

For the more experience programmers, there is another option. Build a custom version of Csound yourself. Then then build Cabbage with this custom version. Then use step 1 above, but include your custom Csound dll. This will prevent any issues with system wide installs of Csound. This is how Cabbage Pro works on Windows.

#2

Hi Rory,

First of all, this is my first post here and I want to say thanks for all your work on Cabbage!

I think I understand your reasoning for wanting to keep the .csd file separate, but I’m wondering if it would be possible to build the plugin and cSound into a single .dll file for Windows. I assume the license for cSound would need to be included but aside from that, what (if any) technical limitations are preventing this?

#3

Hi @mathieu_dombrock. You can do this but your project will also have to be licensed under the same terms as Cabbage, i.e., the GNU GPL. That means you will need to publish your modifications and changes. You will probably also have to share your Csound code as embedding it will involve adding the Csound string to your GPL source code. But yeah, if everything is GPL-ed then there is nothing to stop you, apart from the giant pain in the ass in getting all this set up on Windows :laughing:

1 Like
#4

Btw, when distributing on Windows, only the plugins DLL need go into the plugins folder. All other resources and libs can be placed into the ProgramData folder. In this way the end user only ever sees the actual plugin dll.

#5

I’m fully planning on releasing anything I build with Cabbage as GPL code through and through so no problems with licensing there. I just want to make everything as easy as possible for the end user.

I’m a little worried about conflicting cSound distributions and changing system variables like you mentioned in the top post, which is why I was wondering about including it in the DLL but I think most users that already have cSound installed will more or less know what they’re doing.

I think when I release my plugins I will just have the csd and plugin specific resources available in a GitHub repo. Then I’ll make DLLs available as a release with instructions on manually installing cSound.

Eventually l’ll get around to writing an installer with NSIS if my plugins end up being used by anyone.

#6

The conflicting versions of Csound is the most likely problem you’ll face. If it’s all GPL you can enable the BUILD_STATIC CMake options when building Csound. Then when you’re building Cabbage link to this .lib instead of the dynamic one. On top of you that you can replace compileCsound() with compileCsdString(). After that you should be good to go.

#7

Hi Rory,

The structure of the project changed, were you making a reference to this file? https://github.com/rorywalsh/cabbage/blob/develop/Installers/Windows/Installer.iss

Thanks!

Julien

#8

Yes, that’s the one. It should help you get started at least. Let me know if you have any issues. Just remember that on windows, you’ll want to put your .csd file and any extra assets in C:/Program Files/Company Name/PluginName. That way you don’t need to clog up your vst folder.

#9

Thanks, I just need to figure out how to do it on my mac now :smile:

Btw I did a Python script that automates MacOS distribution (based on your .sh files + issues I had). I can share it with the community if you’re interested in this script :slight_smile:

#10

Oh yes please. I think Packages is fairly simple to use, but these days I mostly end up scripting installers directly with the command line tools provided by MacOS. Other options are always welcome.

1 Like
#11

By automating I meant embedding Csound + signing/notarizing plugins, I did not create installers with Packages yet (but I will automate it as well in the future, I release way too much alpha versions I want to share haha)

1 Like