VST Installer?


#1

Hey guys,
just a little question, if you finished your plugin (VST, AU, VST3), do you create a installer? that copies the files later directly to the user folders?

How are u doing this?

For windows i found a lot of tools (InnoSetup or NSIS are both free), but how to do that on a mac?

Thanks

 


#2

For Mac, we use this excellent tool (which I hope keeps being mantained forever and ever):

http://s.sudre.free.fr/Software/Packages/about.html

For Windows, Innosetup.


#3

+1 for Packages (although it lacks some documentation).


#4

Same here: Packages on MacOSX and InnoSetup on Windows.


#5

same here, innosetup and packages


#6

you can find example Innosetup and Packages scripts in WDL-OL, which could easily be adapted to work with JUCE 

https://github.com/olilarkin/wdl-ol/tree/master/IPlugExamples/IPlugEffect/installer


#7

Thanks for posting the iss file Oli. As I've found out, Inno Setup is great for simple installers but custom folders and stages can get quite complicated.

One quick question I can't quite tell from the code, does the installer write custom VST directory choices back to the registry and then read them back each time it is run?

I.e. if someone installs a plugin to a non-default directory and then runs an installer for a later version, will it pick up that custom directory or will they have to remember where they put it and choose it again from the browser page?

Thanks a lot!


#8

Thanks for u answers,

one more question:

 

Packages Installer -> I have to install the VST, AU and VST3 file in the user home directory, but the AAX file must in the system library folder. How do you handle that? Two installers? Or did i miss something? On my packages Version i can say (global) install to user or install to system.

 

And if i create a installer for AAX plugin, the AAX plugin gets broken on the install.

After the install its a public folder and not a AAX Plugin?! Someone knows help?

 

Thank you and happy easter :)

 


#9

You can install to /Library/Audio/Plug-Ins you don't have to install to the user audio plug-ins directoty. This seems to be pretty standard in my experience.

Also if your AAX plugin is breaking on instalation it may mean you are breaking your signature when installing.

Things to look out for...

1.) Don't add anything to the binary after it has been signed, i.e. don't add some factory presets to the bundle during installation.

2.) Turn off anything in packages that removes or alters files such as "Remove .DS_Stroe files", "Optimize nib files" (These options are on the Project tab of a Distribution package).

3.) Be careful of metadata, for example if you commit a built AAX plugin to git pull it down on another machine and then use the other machine to build your installer the signature will normally break due to git not tracking metadata! The best way around this is either build the installer locally or at least build a raw package with the plugin locally and have the Distribution pacakage import the raw packagae, you can also zip the the AAX plugin or put it in a DMG before committing.

Hope that helps.


#10

Thanks a lot

 

[disable] Remove .DS_Store files && [disbale] Obtimize nib files fixed for me the broken AAX Plugin

and [disbale] Remove SCM metadata fixed the problem with the broken validate.

 

Thank you :)


#11

+1 for this question


#12

Can somebody explain the workflow for creating a distribution for VSTs with packages? I created a new distribution, but inside a packages payload tab I can’t find folders like /Library/Audio/. How do you select the installation folder? Also how do you select the user folder?


#13

Right click the Library directory and click New Folder not all the folders are there by default so you just have to add the ones you want.

You don’t! you either install things to the shared library OR the user library see here for details http://s.sudre.free.fr/Software/Packages/Q&A_3.html

However I recommended just not installing to the user library if it can be avoided.

EDIT: Or if you must do it in a script. However you’ll need to do checks to make sure a user is actually logged in during installation. For example your package can be installed from terminal via something like Apple Remote Desktop to machines that have no logged in user!


#14

any example of the script?


#15

I would strongly recommend learning PackageBuilder. In the last few years, Packages has failed to update with a major macOS change at least twice (most recently with High Sierra) and several months have gone by before he has released a new build. Obviously, in a production scenario, that’s not going to work. It is a labor of love (or, you know, the opposite of that most likely) for him, so it will end at some point.

I’m sharing my normal PackageBuilder script here. I’ve edited out sensitive info. The tree looks like this:

/myScriptFolder/myScriptname.command
/myScriptFolder/Distribution.xml
/myScriptFolder/Resources/background.png //1247 x 840 png
/myScriptFolder/Resources/en.lproj/license.rtf // your EULA
/myScriptFolder/Resources/en.lproj/welcome.rtf // the text that goes on the first page of the installer
/myScriptFolder/Resources/en.lproj/Localizable.strings

That’s the tree, in its entirety. Now the script itself. Make a text file named myScriptname.command, and put this in it, and edit to to fit your scheme. I’ve edited the AAX signing line because it contains sensitive info, but otherwise left everything else intact.

name="Discord4"
version="4.0.1"

mkdir aax/
cp -R "/Library/Application Support/Avid/Audio/Plug-Ins/${name}.aaxplugin" aax

mkdir au/
cp -R "/Library/Audio/Plug-Ins/Components/${name}.component" au

mkdir vst/
cp -R "/Library/Audio/Plug-Ins/VST/Audio Damage/${name}.vst" vst

mkdir vst3/
cp -R "/Library/Audio/Plug-Ins/VST3/${name}.vst3" vst3

/Applications/PACEAntiPiracy/Eden/Fusion/Versions/3/bin/wraptool sign --verbose --account XXXXX --password XXXXX --wcguid XXXX-XXX-XXX-XXXX --signid "Developer ID Application: Audio Damage, Inc. (XXXXXXX)" --in "./aax/Discord4.aaxplugin"

pkgbuild --analyze --root "./vst/" "${name}_VST.plist" \

pkgbuild --analyze --root "./vst3/" "${name}_VST3.plist" \

pkgbuild --analyze --root "./au/" "${name}_AU.plist" \

pkgbuild --analyze --root "./aax/" "${name}_AAX.plist" \

pkgbuild --root "./vst/" --component-plist "./${name}_VST.plist" --identifier "com.audiodamage.pkg.VST" --version $version --install-location "/Library/Audio/Plug-Ins/VST/Audio Damage" "${name}_VST.pkg"

pkgbuild --root "./vst3/" --component-plist "./${name}_VST3.plist" --identifier "com.audiodamage.pkg.VST3" --version $version --install-location "/Library/Audio/Plug-Ins/VST3" "${name}_VST3.pkg"

pkgbuild --root "./au/" --component-plist "./${name}_AU.plist" --identifier "com.audiodamage.pkg.AU" --version $version --install-location "/Library/Audio/Plug-Ins/Components" "${name}_AU.pkg"

pkgbuild --root "./aax/" --component-plist "./${name}_AAX.plist" --identifier "com.audiodamage.pkg.AAX" --version $version --install-location "/Library/Application Support/Avid/Audio/Plug-Ins" "${name}_AAX.pkg"

productbuild --distribution "./Distribution.xml" --package-path "./" --resources "./Resources" --sign "Developer ID Installer: Audio Damage, Inc." "OSX_${name}_${version}.pkg"

rm "${name}_VST.plist"
rm "${name}_VST3.plist"
rm "${name}_AU.plist"
rm "${name}_AAX.plist"
rm "${name}_VST.pkg"
rm "${name}_VST3.pkg"
rm "${name}_AU.pkg"
rm "${name}_AAX.pkg"
rm -r "./aax"
rm -r "./vst"
rm -r "./vst3"
rm -r "./au"

Here’s what happens, in order:

  1. Make local folders for each plugin version.
  2. Copy plugins from /Library to local folders
  3. Perform AAX signing step.
  4. Create flat installers for each plugin.
  5. Package them together to a “thick” installer.
  6. Create final product from local assets.
  7. Remove all the stuff we created in steps 1 and 2 to tidy up.

I’m sure there’s a neater way to do this, with many clever Apple scripting tricks; I figured it out through trial and error. The XML distribution file for the above script looks like this (I obviously stole it straight from a Packages save, and am very much of the “if it ain’t broke” school of thought with regards to this sort of thing. Currently accepting submissions for a prettier version.)

<?xml version="1.0" encoding="UTF-8"?>
<installer-script authoringTool="Packages" authoringToolVersion="1.1.3" authoringToolBuild="2B112" minSpecVersion="1.0">
    <options/>
    <!--+==========================+
        |       Presentation       |
        +==========================+-->
    <title>DISTRIBUTION_TITLE</title>
    <background file="background" scaling="tofit" alignment="center"/>
    <welcome file="welcome.rtf"/>
    <license file="license.rtf"/>
    <!--+==========================+
        |         Installer        |
        +==========================+-->
    <choices-outline>
        <line choice="installer_choice_1"/>
        <line choice="installer_choice_2"/>
        <line choice="installer_choice_3"/>
        <line choice="installer_choice_4"/>
    </choices-outline>
    <choice id="installer_choice_1" title="Discord4 AAX" description="">
        <pkg-ref id="com.audiodamage.pkg.AAX"/>
    </choice>
    <choice id="installer_choice_2" title="Discord4 AU" description="">
        <pkg-ref id="com.audiodamage.pkg.AU"/>
    </choice>
    <choice id="installer_choice_3" title="Discord4 VST" description="">
        <pkg-ref id="com.audiodamage.pkg.VST"/>
    </choice>
    <choice id="installer_choice_4" title="Discord4 VST3" description="">
        <pkg-ref id="com.audiodamage.pkg.VST3"/>
    </choice>
    <!--+==========================+
        |    Package References    |
        +==========================+-->
    <pkg-ref id="com.audiodamage.pkg.VST3" version="4.0.1" auth="Root" installKBytes="9320">Discord4_VST3.pkg</pkg-ref>
	<pkg-ref id="com.audiodamage.pkg.AAX" version="4.0.1" auth="Root" installKBytes="9668">Discord4_AAX.pkg</pkg-ref>
	<pkg-ref id="com.audiodamage.pkg.AU" version="4.0.1" auth="Root" installKBytes="9295">Discord4_AU.pkg</pkg-ref>
    <pkg-ref id="com.audiodamage.pkg.VST" version="4.0.1" auth="Root" installKBytes="9059">Discord4_VST.pkg</pkg-ref>
    <!--+==========================+
        |    JavaScript Scripts    |
        +==========================+-->
</installer-script>

I really wish all this info was in one spot when I had to figure it out for myself during one of Package’s forced sabbaticals. So here’s to hoping it helps someone else.

(Side note: our products don’t have DRM, because stupid waste of time and resources. If you have an installer-based CP step, can’t help you.)


#16

Thank you so much. That was extremely helpful. I’ve been using Packages, and for all the reasons you mention, I’ve always felt a little worried about the dependance on it.

Thanks again.


#17

Some helpful resources for those taking the PackageBuilder route.

https://developer.apple.com/library/content/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Introduction.html

https://developer.apple.com/documentation/installerjs

Unfortunately I think there is a real risk Apple will drop package support altogether one day. Hopefully not anytime soon!


#18

Thanks so much @crandall1 for sharing your process, and the warning about Packages. Your timing is perfect - I was mucking around with Packages earlier this week, based on the recommendations earlier in this thread. I had not realised that Packages is a front-end for native command line tools.

Would it be replaced by some other install tool? Please don’t tell me “the app store”!?


#19

My general feeling re: Macs in general and macOS in particular is that Apple mainly look at them as a tool for developing iOS applications at this point. As Mac users, our Stockholm syndrome is so complete by now that they can do pretty much whatever they want, and we’ll still line up saying “please sir, may I have another?”

In that context, any particular part of macOS is subject to either withering on the vine or complete deprecation. But there are no indications that PackageBuilder is on the block that I’m aware of. As plugin makers, however, we’re in the middleware business, and we have to be comfortable with the endpoints being in a more-or-less constant state of flux.


#20

Oh, and… one note on the above script: our factory presets are baked in the binary, so there’s no preset copy step. I’ll leave that as an exercise for the reader, but basically just do the same thing as the VST one, but make the source and target your preset folder. Note that if the folder is empty (like, if you’re just testing the installer) the script will fail. All the sources have to actually exist.