VST Installer?

I’m afraid the App Store or a simple DMG is pretty much it. I get the impression they want to encourage developers to have an App be the one do whatever is required say on first launch (not always possible for a plug-in). This way the App can ask for the correct permissions and be properly sandboxed, unlike a package which can run pretty much any arbitrary code it wants. When you think about sandboxing, system integrity protection, gatekeeper, etc. it seems to be the way they are going. However I just checked the iTunes installer and that’s still a pkg so as already said it’s probably not going to be dropped anytime soon, it may never be dropped but I certainly get the feeling that they want to move away from it.

1 Like

Packages seems to update regularly enough for me. Not had any issues in Sierra or high Sierra.

4 Likes

Hello,

It seems my installer for both Win and Mac doesn’t overwrite older plugin files sometimes.
I can’t reproduce this myself, but have received some issue reports.
I use packages for Mac, Inno setup for Win.

Has anyone run into the same problem?

Thank you.

In your Inno Setup script, you can add Flag: ignoreversion to your Source entries.

On Mac, there’s no equivalent flag that I’ve found, but I will say that the package installer framework itself is VERY sensitive to version numbers and dates. Get those right and you should be ok.

Thank you, I will check that flag in Inno setup.

On Mac, packages has pre/post script slots.
So I guess it could be possible to add script that deletes older files before installing newer one.
But I have’t figured out how to write those script yet.

A script that I use from within Packages to remove the previous version. Because the user can choose which plugin format to install, each one has his own script. Here’s an example for AAX:

#!/bin/sh
#
# Author: Samuel Gaehwiler
#         www.klangfreund.com
#
# Description:
#   This script is used by the installer package.
#   Without this, the plugin files will keep their original creation (and even
#   modification) date when updated. This can lead to strange host behaviour
#   (For example the Pro Tools AAE error -7106).

folder="/Library/Application Support/Avid/Audio/Plug-Ins/LUFSMeter.aaxplugin"

if [ -e "$folder" ]
then
    rm -R "$folder"
fi
3 Likes

Thank you!
It works.

Also, keep in mind that Packages has this setting shown in the image below, which you should probably check for all the binaries you want to install (plug-ins and apps)

3 Likes

Thanks for clarification on where to install. I was thinking you needed to install to both system and user folders after going through the Mac section of this tutorial:
https://docs.juce.com/master/tutorial_app_plugin_packaging.html

@anthony-nicholls Thanks for the tip about this - I swear it used to be fairly user friendly, but I was totally stuck working with Packages today. I could not set the Payload destination I wanted.

This tip you suggested of using New Folder works, it’s just a tedious way to set a filepath! Say I’m setting the AAX plug-in directory as my destination (/Library/Application Support/Avid/Audio/Plug-Ins). I can see Library/Application Support in the file hierarchy (since it’s a “Standard Folder”) – but then I have to use New Folder 3 times in a row, drilling down each successive level after that, and each time typing in the directory name… instead of, say, just being able to select the final destination in a standard file dialog!

Am I overlooking some other, simpler way to set a destination? Using Add Files... without first drilling down to the desired destination doesn’t work… the destination is always set as the last directory you had selected, with no way to change it later.

I would suggest learning pkgbuild and productbuild, which Packages is really more or less a glorified wrapper for. This repo is a good resource to plunder (I helped develop the installer script there).

1 Like

You could make a folder on disk called Avid with everything you want in it and add this instead (once you’ve selected the folder just click Add). However…

  1. I’m not sure if this will remove everything else in Avid when installed rather than merge it
  2. The advantage of adding each folder is you can see in the UI what permissions are going to be set for each folder - any accidental change of permissions on disk won’t impact the result.

As said above you could also use pkgbuild and productbuild maybe even use packages just to get your initial distribution xml. You can take apart any distribution package by running pkgutil --expand </path/to/pkg/to/expand> </path/to/a/new/folder/that/will/contain/the/contents>. This is really useful for seeing exactly what packages does or others have done in a distribution xml. Much easier than reading the documentation :wink:

I’ve used both methods they have there pro and cons.

One thing I would say though is that Apple have for a long time been pushing away from pkg installers and encouraging other methods. Unfortunately for plugins there’s not an immediately obvious alternative but if you’re able to make a simple dmg where users drag and drop what they want then I would probably recommend something like that nowadays. One issue will be of course what happens when the AAX Plug-Ins folder doesn’t exist.

OK, thanks for the pointers about using pkgbuild and productbuild. For future-proofing and ultimate control, that is the road I’ll need to take I guess.

And, as @crandall1 showed earlier in this thread, the AAX signing step can be handled by the same script, which is one less step to handle manually (just gotta make sure that I’ve got my iLok on hand when building installers, which isn’t always the case).

Sorry for reviving this old thread,
I wonder if anyone used CPack?

It seems to be quite useful especially with JUCE making CMake a first class citizen.

1 Like

Have you tried it? It does look promising indeed

I stumbled across CPack recently and wondered similar. When I asked my colleague about it:

its fine up to a point, but when you hit the edge it quickly becomes really complicated and annoying

remember that anecdata is anecdata of course :wink:

That said I trust his opinion and decided it’s probably not worth the effort to migrate from my current system of BASH scripting to package my plugin installers, YMMV.

2 Likes

I wonder why,
For some products where installers will be complicated… you’ll usually end up making installers from scratch.
But for a “simple” pkg/msi/exe with AU, VST3, AAX it sounds quite simple and useful.

I think that’s the take-away I got: for “simple” it’s great, but as soon as you get into anything vaguely complex (installing different bits in different places for instance was something he mentioned) then it gets annoying quickly apparently.

Hope this helps :slight_smile: