Ship resource files in the plugin bundle

[jpcima]

Can Dplug support having custom files in the plugin bundle?

For reference, VST3. The organization is identical to the macOS bundle. https://developer.steinberg.help/pages/viewpage.action?pageId=9798275

eg. plugin.json "resourceDirs": ["resources"]

[p0nce]

No Dplug doesn't support it. The problem is that different files should go in different locations. If your preset folder is in the VST3 bundle, then you won't have write access to it in Windows, so it must be in %appdata% or something. It is also tricky with increasing macOS restrictions, and only one place is allowed on macOS for preset for example. Moreover, some files are large and needs another place to not be duplicated across formats. Also not all formats are in bundle form. Also in macOS, it's not even sure you are allowed to know your absolute path position, and current directory won't be the one of the plugin. It is really MUCH more complicated than you think.

[jpcima]

Are resources not supposed to be always read-only? Appdata is a distinct matter, and it's up to the plugin implementation.

It's a valid point that it's desired to separate between bundle resources and shared resources. Then dplug may accept a pair of search folders for resources? one based on the bundle structure, and one based on Program Files(Win) Library(Mac) /usr/share(Linux).

Also not all formats are in bundle form.

Given that this format is dying, perhaps it shouldn't be that big a concern.

Also in macOS, it's not even sure you are allowed to know your absolute path position, and current directory won't be the one of the plugin.

Yes, this is feasible cf. CFBundle, CFBundleGetBundleWithIdentifier

[p0nce]

Preliminary design:

    "resourceDirs": ["resources"] // in plugin.json
    "resourceFiles": ["individual-file.bin"] // in plugin.json

looks good as an API.

dplug-build would be able to take file there, and put it into the Mac and Windows installers. Now, so that it works in naked dub calls and with visual studio generated projects, opening a resource should search relatively from plugin.json while in development.

Are resources not supposed to be always read-only?

OK, point taken. I checked and lots of products do not write presets themselves, this is an Host concern.

Appdata is a distinct matter, and it's up to the plugin implementation.

OK, point taken.

It's a valid point that it's desired to separate between bundle resources and shared resources. Then dplug may accept a pair of search folders for resources? one based on the bundle structure, and one based on Program Files(Win) Library(Mac) /usr/share(Linux).

Yes I think it would be a good idea to get a resource file like: ubyte[] getBinaryFile(path) looking into those different paths depending on platforms.

I'm not sure it would be good to allow in-bundle resource files, since it doesn't always beat import() (aka "string import" in D):

• shared resource file beats import in case of Universal Binary (only one copy, so, good for image files)
• shared resource file beats import in case of partial access to large file.

Also not all formats are in bundle form.

Given that this format is dying, perhaps it shouldn't be that big a concern.

I think I will disagree there. That all formats work the same is really fundamental in Dplug. The only two exceptions are: MIDI out missing in AUv2, and notarization missing for LV2. When I accept PR that are partial to a format it gives the rest of the work for me :) and this is problematic since half of my time is for my own products. Also Surge CLAP is just one file when I checked (.clap), it has no bundle format defined. So I think VST2 must be supported in this, and of course it is easier if the be-a-bundle requirement doesn't exist. I believe being local to the bundle can come later and still solve your issue.

Also in macOS, it's not even sure you are allowed to know your absolute path position, and current directory won't be the one of the plugin.

Yes, this is feasible

When I ported to Big Sur initially any call to getcwd would fail with permissions. I think it was considered a security hazard. Not sure today, but I'm anxious for the sandboxed AU case.

[jpcima]

In any case, thanks for considering this feature. I wouldn't mind contributing.

I'm not sure it would be good to allow in-bundle resource files, since it doesn't always beat import() (aka "string import" in D):

String imports of some moderately large data files increase dub build time, and it's a problem that I hope external files are able to solve. (as bonus, this data is discardable after processing)

That all formats wrk the same is really fundamental in Dplug.

Can a developer be offered one of 2 choices? bundle resources allowed, or no VST2.

any call to getcwd would fail with permissions.

Vstgui has an example of NSBundle for resource access. By their method, the CFBundleRef is externally provided. One should be able to access it still, if the bundle identifier is known. (which I believe it is)

[p0nce]

In any case, thanks for considering this feature. I wouldn't mind contributing.

Very good! This would be a very valuable feature indeed. It's just that I'm grumpy because deep in development of a new product, and Dplug changes are a bit slow half of the year (january to july in general).

Can a developer be offered one of 2 choices? bundle resources allowed, or no VST2.

Well no. That's not really advisable as DPlug would be really messy if features were format-dependent (eg: resizing, latency reporting, MIDI input...). Now, we could workaround that by having a "resources/" folder near the VST2 (not needed in macOS where VST2 is a bundle), and inside that folder a path that contains the plugin unique IDs and vendor unique IDs, to avoid clashes. We would need to change our Windows VST3 to be the proper bundle format.

The only remaining question for me is: Option A - "Should we allow resource files in bundle (or nearby directory)" Option B - "Should we allow a shared folder store in standard directories."

Both options can be implemented, or one. (the end game is maybe to have both and we should plan ahead so that it's possible)

As I see it, advantages of option A are:

• easier to move the plugin around in development
• easier to uninstall plugins
• lack of a global "state" outside the bundle, with outdated resources

Advantages of option B are:

• uses less disk space in case of multiple format installation
• faster notarization, as resources doesn't need upload to Apple
• probably harder to keep Visual Studio generated projects working; in development need special place.

Both options would need installer and dplug-build tweaks.