Best way to handle assets ?

Hi, I am working on a vst3 and LV2 plugin using DPF and it is working as intended however I would like to start working on making a user interface for it.
I use cmake to handle the build of my project using dpf_add_plugin and I am not sure about how I would indicate the directory holding the assets of the plugin so that it always gets bundled with it

that seems more of a general question on using cmake, no?

that seems more of a general question on using cmake, no?

not really because while in cmake i'd just set the cmake archive output and cmake binary output variables but dpf seems to output to specific directories depending on whether it's lv2, vst3 etc so i'd need to rely on these dpf specific variables to output to the right directory

for that the develop branch has a dedicated function to let you know where the resources would be at runtime.
see https://github.com/DISTRHO/DPF/blob/develop/distrho/DistrhoPluginUtils.hpp#L50
(that together with the Plugin::getBundlePath should do it)

from what i can see for each target it sets a target property specifying the library output directory directly

for instance for LV2

set_target_properties("${NAME}-lv2-ui" PROPERTIES
        LIBRARY_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/bin/${NAME}.lv2/$<0:>"
        ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/obj/lv2/$<0:>"
        OUTPUT_NAME "${NAME}_ui"
        PREFIX "")
    endif()

the issue I see is that because of it we'd need to manually read the properties of the generated target names
i feel like the dpf_add_plugin function should have an argument to specify an asset folder so that it automatically will copy it to each build (lv2/vst etc)

I'm referring to copy the asset folder to the folder of the vst, lv2 etc at build time, not locating the folder at runtime

@falkTX

Nice, I didn't notice DPF supported the resource bundles yet.
We sure can have a cmake helper to copy them.

@falkTX, unrelated: about the fixed resource directories
if we're going to ever support vstgui, it's worth knowing that this library has its own resource-finding that can't be overriden. We found the best hierarchy is the macOS-style one for all platforms, it can be made to work everywhere. (and having moved the lv2.so from the root to a subdirectory)

I am not super keen on changing the binary location and bundle structure at this point tbh..
Supporting multiple architectures (different binaries) in a single bundle would be a reason to go and change things, but outside of VST3 no other plugin format supports this at the moment.

also I tried getBundlePath but it returns null for vst3

I guess i'll rely on res2c instead atm to convert the resources to cpp and directly bundle them in the executable

also I tried getBundlePath but it returns null for vst3

there should be some assertion fail if that is the case. vst3 and lv2 are required by design to have a bundle

also I tried getBundlePath but it returns null for vst3

there should be some assertion fail if that is the case. vst3 and lv2 are required by design to have a bundle

that's kinda what i find weird since i just build it normally using cmake with dpf_add_plugin

Navigation Menu

Repository navigation

Best way to handle assets ? #352

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Best way to handle assets ? #352

Description

Activity

falkTX commented on Dec 28, 2021

SeleDreams commented on Dec 28, 2021

falkTX commented on Dec 28, 2021

SeleDreams commented on Dec 28, 2021

SeleDreams commented on Dec 28, 2021

jpcima commented on Dec 28, 2021

falkTX commented on Dec 28, 2021

SeleDreams commented on Dec 28, 2021

SeleDreams commented on Dec 28, 2021

falkTX commented on Dec 28, 2021

SeleDreams commented on Dec 29, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions