Latest MacOS/Windows installers not working (v0.0.1)

[rosshoyt]

I downloaded the latest installers from the Pamplejuce releases page and ran the Windows and Mac installers. Neither installer is working, for different reasons. Here are more details (I tested this using Ableton Live 11 on both OS):

Windows 10 Pro (VST3)

Ran the installer and used the default location (C:\Program Files\Common Files\VST3\). Inside that folder, it only added 2 files: unins000.dat, and unins000.exe. No Pamplejuce.vst3 file can be found.

After rescanning for new plugins, Ableton does not show any Pamplejuce plugin in the Plug-Ins list (other VST3 plugins in the folder are showing up). This is expected as the installer did not seem to install any VST3 files, just the 2 files mentioned above.

macOS 10.13.6 (VST3/AU)

VST3

Ran the installer and Pamplejuce.vst3 was installed to folder Library/Audio/Plug-ins/VST3/. However, after scanning the folder for new plugins with Ableton 11, it does not show up in the list of available Plugins. I repeated this with the JUCE AudioPluginHost application, and it does not recognize Pamplejuce.vst3 when scanning the folder containing it.

AU

Pamplejuce.component was installed to Library/Audio/Plug-ins/Components/. Ableton does recognize it, so it shows up in AU Plugins list. However, when adding it to an audio track, this error message is displayed:

"Failed to create the Audio Unit "Pamplejuce." This Audio Unit plug-in could not be opened."

Hope this helps. Any thoughts appreciated!

[sudara]

Hi @rosshoyt,

I'm away from my windows machine, but last I checked it placed the vst3 on install (on Windows 11). I'm currently on vacation, so won't be able to troubleshoot this for a bit...

What version of macOS and Ableton are you on? I'm on Ableton 11.1.6 and confirmed it just worked ok. I think I was on 11.0 at some point and saw that it didn't like the universal binary, not 100% sure what their status is with Audio Units

Re: ableton & vst3, can you confirm the plugin is located at /Library/Audio/Plug-ins/VST3/ and this setting is on?

It's showing up for me:

Thanks!

[SvensonDev]

Hi, I have same problem described by @rosshoyt .

Have anyone find a solution?

[sudara]

@SvensonDev Hey there — are you able to replicate both the windows/mac issues, or just the windows issue?

What version of Windows do you have? 10? 11?

I've gotten one other report re: the windows installer, so I'll take a look again over the break... must be something with the innosetup script that's unhappy...

[SvensonDev]

@sudara Yes, I replicate the behaviour on my local machine: Windows 10.

Looking the installation exe dimension I guess that source file are not included. Seems (watching my inno console) that removing 'external' flag the files source will be included in the installation pack. But are not copied in dest folder.

I hope that information could help you.

[Edit] If I remove the Is64BitInstallMode now works on my machine. But I think there is an other problem in Source file path cause when I use it on gitHub (with actions) it can't find my file.

[patheros]

So I had the same issue in my fork and I was able to fix it in my file.

Note my plugin name is "TestPlugin" rather than "Pamplejuce"

The changes and explanations:

1. Removed {src} . The inno docs state this is relative to the installer, so idk what effect that would have.
2. \*.\* doesn't drill into folders, and the normal syntax for that didn't seem to work, so my fix was to explicitly name the folders Contents\x86_64-win
3. I also removed Is64BitInstallModeas @SvensonDev suggested. Note I didn't test if this was needed.
4. I removed the externalflag so the source path could be relative.
5. I removed the hidden attributes. Hiding the installed files seems more confusing than helpful?
6. I removed the system attribute because I assumed it wasn't needed.

Finally I made a few other changes not directly related to solving this.

1. DefaultDirName now includes {PluginName}.vst3. This makes the uninstal.exe and .dat are placed inside the plugin folder, which seems more organized to me, esp if multiple plugins from this template were to be installed on the same computer.
2. I made the DestDir relative to {app}, so if the user chooses a different folder to install the plugin to, it goes to that location.

Hopefully this helps!

[sudara]

@patheros — Wow! Thanks for all the detail, that's quite useful. Do you have a handle on what changes might have made the difference with it not being installed at all?

@JoseDiazRohena might be interested in all this, think he's chewing on it now. I hope to look into it soon as well.

This makes the uninstal.exe and .dat placed inside the plugin folder

Yeah, I'm sort of confused about where these should go! I guess stuffing them inside the vst3 bundle is ok, but i feel like there must be a convention of sorts. Or maybe it's simply not needed and can be disabled somehow?!

[patheros]

I'm not sure. If you want you could fork my repo and try undoing the changes to figure out. If I had to guess I would say:

1. Removed {src} . The inno docs state this is relative to the installer, so idk what effect that would have.
2. *.* doesn't drill into folders, and the normal syntax for that didn't seem to work, so my fix was to explicitly name the folders Contents\x86_64-win
3. I also removed Is64BitInstallMode as @SvensonDev suggested. Note I didn't test if this was needed.
4. I removed the external flag so the source path could be relative.

[JoseDiazRohena]

The weird thing, for me, is that passing recursesubdirs should allow for the wildcard to work. See: https://github.com/iPlug2/iPlug2OOS/blob/master/TemplateProject/installer/TemplateProject.iss with an important caveat: you have to set a bunch of exclusions so you don't include things you don't want.

That being said, pathing with a wildcard as shown in the above link isn't working for me. What @patheros shows generally does (had to tweak destination dir and it seems to include a file that shouldn't be there.

[JoseDiazRohena]

Here's what I'm currently cooking with. This correctly gets the VST3 recursively and creates a data folder for the plugin that can hold presets and the like—but just an uninstaller for now. Thanks to Surge. PR...soon?

#define AppUrl "https://github.com/Tote-Bag-Labs/valentine"
#define MyAppName "Valentine"
#define MyAppPublisher "Tote Bag Labs"
#define Version Trim(FileRead(FileOpen("..\VERSION")))

[Setup]
AppName={#MyAppName}
AppPublisher={#MyAppPublisher}
AppPublisherURL={#AppUrl}
AppSupportURL={#AppUrl}
AppUpdatesURL={#AppUrl}
AppVersion={#Version}
DefaultDirName="{commoncf64}\VST3\{#MyAppPublisher}\Valentine.vst3\"
DisableDirPage=yes
LicenseFile="../LICENSE"
OutputBaseFilename=valentine-{#Version}-windows
UninstallDisplayIcon={uninstallexe}
UninstallFilesDir={commonappdata}\{#MyAppName}\uninstall

; MSVC adds a .ilk when building the plugin. Let's not include that.
[Files]
Source: "..\Builds\Valentine_artefacts\Release\VST3\Valentine.vst3\*"; DestDir: "{commoncf64}\VST3\{#MyAppPublisher}\Valentine.vst3\"; Excludes: *.ilk; Flags: ignoreversion recursesubdirs;

[Run]
Filename: "{cmd}"; \
    WorkingDir: "{commoncf64}\VST3"; \
    Parameters: "/C mklink /D /J  ""{commoncf64}\VST3\{#MyAppPublisher}\{#MyAppName}Data"" ""{commonappdata}\{#MyAppName}"""; \
    Flags: runascurrentuser;