CLAP_WRAPPER_WINDOWS_SINGLE_FILE

[rorywalsh]

Me again 🤣 Let me first state that I'm really enjoying building things with CLAP. It's quickly becoming my go to plugin framework.

Now that's out of the way, perhaps someone can help me with vst3s on Windows. Setting CLAP_WRAPPER_WINDOWS_SINGLE_FILE to false should result in a vst3 folder right? Once again, I'm using the modified clap_first_plugin repo as the test case. When I build, this is what I get:

[rorywalsh]

It looks like this cmake var is not being used? As a workaround I can do this:

set(V3_WINDOWS_FOLDER_VST3 TRUE CACHE BOOL "")

[edit] while this does work, it no longer places the resulting vst3 plugin into the _assets folder

[baconpaul]

Glad you are enjoying it!

You know i haven't tested that configuration. Probably we need to add and pass that down the pipe.

So what needs to happen, roughly, is

1. make_clapfirst.clap around line 40 add WINDOWS_FOLDER_VST3 as a onearg
2. same file around line 140 do something like

if (NOT DEFINED C1ST_WINDOWS_FOLDER_VST3)
   set(C1ST_WINDOWS_FOLDER_VST3 FALSE)
endif()

and then in the target_add_vst3_wrapper do a WINDOWS_FOLDER_VST3 ${C1ST_WINDOWS_FOLDER_VST3}

then (and this is the kicker)

3. wrap_vst3.cmake at line 194

       if (NOT "${V3_ASSET_OUTPUT_DIRECTORY}" STREQUAL "")
                message(WARNING "VST3 Custom Asset Output Dir and WINDOWS VST3 folder bundle not yet implemented")
            endif()

replace that message with 'the right thing' which I think amounts to having the set_target_properties above swap based on if the asset directory is set (so move those target properties into the else of that if and write the right thing in the if.

I don't have access to a windows box today to test this but that's the changes needed.

You could just do step 3 and then your hard set would also work for now.

[rorywalsh]

Thanks Paul, I'm already up and running. I had thought clap plugins on Windows were also bundles, but it seems they are single binaries. Where do you recommend keep plugin resources in this case? It's easy to dump them into the plugin folder for vst3 and on MacOS. I guess some Windows AppData folder?

[defiantnerd]

You either pack them into the resources part of the binary via .rc file or make c arrays and load them from there.

[rorywalsh]

Thanks @defiantnerd👍

[baconpaul]

yeah i've been lately using https://github.com/vector-of-bool/cmrc which is a platform neutral resource compiler.

its how I embed things like SVGs in my gui kit or the presets in six sines.

In surge we put presets into %APPDATA% or Application Support or /usr/share

[rorywalsh]

I think %APPDATA% might be more appropriate for my needs. https://github.com/vector-of-bool/cmrc looks pretty neat though 👍

[baconpaul]

The thing about embedding in bundle is, even on macOS where it is natural, you end up with copy of your assets per instance, so it's a bad sharing strategy. which is why indeed for big asset collections appdata/applicationsupport is the way to go

the mode we set ourselves with surge was "if you blow away everything except the plugin, does it start". so that sets the set of svgs, patches, etc... we embed in the binary as opposed to install via the installer into a directory and share.

with six sines it was like 100kb of patches so i just splat it into each binary.

[defiantnerd]

Thin wrappers FTW... :)

[baconpaul]

Sigh turns out I need this also! I may get it into next tomorrow. Will keep you updated.

[baconpaul]

OK I just pushed these changes to next

[rorywalsh]

Great, I'll try this tomorrow when I'm next at my windows machine 👍

[rorywalsh]

I'm just checking this out now. I'm seeing a bogus .vst3 folder inside my plugin .vst3 folder? Are you seeing this on your end? It contains a \Contents\x86_64-win folder, but it's empty.

On the up side, the Contents folder contains all the right files.

[baconpaul]

Oh let me look!

[rorywalsh]

Also, and again, this is no big deal, but these are some inconsistencies in the two plugin folders:

The CLAP folder leads straight to a Debug folder, and then the plugin binaries, whereas the VST3 folder takes you directly to the .vst3 bundle. Regardless of all this, it's great to have the .vst3 bundle feature working now :)

[baconpaul]

OK I have a PR in for the double .vst3 dir thing

The Debug/Release thing is irritating. I never use multi-mode generators so I'm sure I have it wrong. My thinking was if you specify an asset output dir you would build the debug or release into that name, but seems i have it wrong.

What do we want the output paths to be in the clap first asset dir in both multi-mode and single-mode cases?

[rorywalsh]

What do we want the output paths to be in the clap first asset dir in both multi-mode and single-mode cases?

I think having a Debug and Release folder within the assets dir is a good idea, and perhaps something people would expect. On the other hand, perhaps you created needless work for yourself by allowing this option in the first place.

[baconpaul]

What do we want the output paths to be in the clap first asset dir in both multi-mode and single-mode cases?

I think having a Debug and Release folder within the assets dir is a good idea, and perhaps something people would expect. On the other hand, perhaps you created needless work for yourself by allowing this option in the first place.

The problem is

People using ninja or unix makefiles don’t expect it People using Msvc generator do

I should just make it an option which if unspecified for lows the generator flavor. Won’t get to that this week and travel next so I’ll leave this open

[baconpaul]

So basically in GENERATOR_IS_MULTI_CONFIG

[baconpaul]

OK so I opened #373 to remind me to do the multi-generator location thing. I'm going to close this since the single file stuff now works for vst3 on windows with clap first in next.

[baconpaul]

Actually sorry let me reopen it and leave it tagged 'solved in next' until we do next->main next for a 12.1 or some such

[rorywalsh]

Hi @baconpaul, has something changed here? I@m no longer able to produce a vst3 folder on Windows. My workaround no longer works with the main branch, and using next doesn't seem to work either. Once again, I'm testing with this repo. I've simply added:

set(CLAP_WRAPPER_WINDOWS_SINGLE_FILE OFF)

and I've also updated the Dependencies.cmake to use the next branch for the clap-wrapper:

FetchContent_Declare(
    clap-wrapper
    GIT_REPOSITORY https://github.com/free-audio/clap-wrapper
    GIT_TAG next
    FIND_PACKAGE_ARGS NAMES clap-wrapper
)

btw, I don't know when this stopped working - I just got notified of the issue today.

[baconpaul]

I don't think anything has changed, but i'm traveling today and tomorrow so it will take me a few days to look.