Cabbage Logo
Back to Cabbage Site

Thoughts on bundling of plugin data?

#1

Following on from a suggestion made by @Oeyvind, I’ve added a new feature that will package all auxiliary files into the .vst bundle on OSX. This is a neat idea and will no doubt save a lot of frustration from end users who had to manually bundle this stuff in the past. For now users can include a new < CabageIncludes > section in their source code.

<CabbageIncludes>
script.py
image.png
test.inc
coolthing.udo
</CabageIncludes>

When export as plugin is selected Cabbage will copy these files to the same directory as the .csd file, or in the case of OSX, into the plugin bundle.

So, I’ve two questions.

  1. is having a new section for these things Ok? I could also have added an include() identifier, but I think there is something to be said for having a simple line-by-line list of files rather than having them all on a single line. Note that the < CabbageInclude > section can be located outside the < Cabbage > section. I imagine I’ll put it at the bottom of my .csd files to avoid clutter.

  2. Should Cabbage automatically create a new plugin folder when exporting on Windows and Linux? It might make things easier to organise and would be easy to do. So each new plugin would live in it’s own unique folder.

Any thoughts?

#2

I think this is a great idea Rory. I might start making more use of fancy backgrounds.

On point 1 I would agree with introducing a new section. Certainly preferable in the case of a massive project with many relates files which is what I imagine Oeyvind will be doing :wink:

On point 2, the only drawback with Cabbage placing the plugin in a new folder is that in most hosts I think you then have to browse into the folder to select the plugin - this might irritate people who are easily irritated. Cabbage could just copy all of the files into the root directory selected when exporting but this will clutter up the plugins folder and might annoy user. It might also cause problems with name pollution if a user already has an image.png for example. Would another option be to keep the MyNewPlugin.csd in the root directory and place the files in a sub-folder called, for example, “MyNewPlugin_data”? Linking becomes a problem then though…

#3

No doubt about it!!

I imagine that most host let you select a root VST folder, and they then scan it for all plugins. I know Live does this. But yes, it might not be consistent across hosts. [quote=“iainmccurdy, post:2, topic:307”]
Would another option be to keep the MyNewPlugin.csd in the root directory and place the files in a sub-folder called, for example, “MyNewPlugin_data”? Linking becomes a problem then though…
[/quote]

This might be a better idea. You think I could also place the actual .csd file there too? It would lead to a tidy VST folder. But I’ve have to make sure there is backward compatibility too. The current system, albeit simple, has never felt like the best approach to me somehow.

#4

Thanks for this new addition, Rory.

  1. I think a new section with tags is nice and tidy, excellent!

  2. I think automatic creation of a new subfolder may perhaps create as many problems as it solves (?). As Iain says, some DAWs will then require you to browse to the subfolder before actually opening the plugin. Also, if the user already have the plugin files in a separate folder, we would get yet another subfolder to that structure. With regards to name pollution perhaps it will not be a problem, if the csd code expects to find image.png in the same directory as the csd, then there is probably no other image.png at that location. Then again, it would not be necessary to copy those files (to the same location) on Windows and Linux. Perhaps the copying should be only for OSX?, as that’s the platform where the problem with files inside the vst bundle occurs.

Another matter of course would be if we would like to include files from other directories as well. But then it is a bigger project altogether to make that portable and reliable. If the files are moved into the plugin directory, the references to the file would have to be updated in the csd. It would be nice, but only really necessary in the case where one loads a lot of large samples/files and want to be able to not have several copies of those but keep them all in a …/…/Cabbage/samples directory or something like that.

… so in brief, 2) no

#5

What about Iain’s suggestion that the dll get copied to a particular folder along with a PluginName_Data folder that holds the .csd file and all required auxiliary files? Cabbage would basically look for a folder with the same name as the plugin but with _data appended and load files from there. This would avoid issues with files named like background.png. Note that the dll would still live in the top level VST directory, hence no need to browse to the folder first. What thinks ye?

#6

That sounds pretty good to me and of course moving the csd into the folder will solve linking problems. Perhaps the new way could be offered as an option when exporting, provided Cabbage is smart enough to check both the same folder and the _data folder for the .csd.

#7

Cabbage will be smart enough to find things the old way, but I’d like to set this new approach as the default. Users can disable it in the preferences. I just want to see what @Oeyvind has to say about it. He seems to use hosts a lot with Cabbage!

#8

hmm, perhaps there is something I’m not seeing here, why is it better to do it this way instead of the old way of just exporting the dll to the same folder and expecting them to be found in the same folder?

I’m thinking, what if I actually want to share some (large) files across different plugins?
Now I could put all those files in a folder together with the csds and dlls for several plugins, and they would all read from the same mini-library.
Also, copying the csds when exporting creates the potential for confusion about which csd is the active one. At least that’s what I’ve seen with students on OSX. They will edit the original csd, not realizing that it is the csd inside the bundle that is read by the plugin. Having the option to do it either way (same folder or separate folder) would increase the potential for confusion (?).

#9

I suppose the main benefit is tidiness. Also, having just a dll and a folder with the same name would make it easy to move the plugin to another machine without having to hunt for all the relevant files. But I can completely understand the usefulness of csds being able to share files. I think it just represents a different way of working - I tend to prefer simple modularity so that I can move/share things easily and I don’t tend to link to large files. Perhaps the solution is to support both methods and to be able to choose which, using a switch in the Cabbage preferences.

#10

I think this is probably the best way forward. I was failing to get Oeyvind’s point, but it’s clear to me now. On another slightly related note, exporting plugins in general can lead to confusion because the .csd file is copied to a new location. Any ideas on how to limit confusion here? I usually prototype my plugins in one directory and export them finished to another. But students often end up opening the pre-exported plugin csd files. It’s the same on OSX where the .csd file is packaged into the VSST bundle. Any ideas?

#11

If it’s being edited as part of a plugin could you add ‘VST’ or ‘AU’ or whatever after the plugin name on the toolbar? Otherwise it’s left as is.

#12

That’s a good idea. Some visual feedback is probably enough. Cheers.

#13

Yes, I like that too.
I tend to continue editing the csd after exporting the plugin. Some of the plugins are perpetual prototypes :slight_smile: