Export tool

[Lindon]

@d-healey yep the bottom one - I think- hang on checking my white box.....

it tells me this; Developer ID Installer: Lindon Mulcahy-Parker (XXXXXXXXXXX).

so I think thats the second to bottom one...??

My reading and re-reading of the KVR threads is that -

if it runs on its own it needs to be notarised, so stand-alone apps and packages.

[d.healey]

@Lindon Can you use the Developer ID Installer for codesigning apps as well as installers?

This is what I saw on KVR:

discoDSP wrote: ↑Sun Oct 20, 2019 10:04 am
Does notarization apply to a .app contained on a .pkg?
Yep. From my previous post:
The notary service generates a ticket for the top-level file that you specify, as well as each nested file. For example, if you submit a disk image that contains a signed installer package with an app bundle inside, the notarization service generates tickets for the disk image, installer package, and app bundle.

[d.healey]

I'm having second thoughts about whitebox packages. Seems there are other tools available that have a commandline interface which would be much more reliable. One problem with the template method is it limits the combination of files to the templates I create. Suppose someone wants to create a set of plugins and standalone app that has IPP and another that doesn't, then I need to double my available templates. Then they might also want debug builds for sending out to testers, there's another set of templates. They might also want to include multiple versions in the same installer for some crazy reason. If the commandline tools turn out not to be viable then I'll resort to the template method, so either way we will have installer creation on MacOS.

[Christoph Hart]

Let me know if you find something better than Packages, it‘s my least favorite thing in the distribution pipeline too...

[d.healey]

I'm thinking of pkgbuild and productbuild. I read this article which also provides a useful generic script that I can borrow from.

[d.healey]

Codesigning on Mac is done, was pretty straightforward. Notarization is also done (but I've only tested with a zip file, still need to confirm with a pkg). Stapling I think is also done but I can't test this with a .zip file. The app just waits until Apple provides a response UUID after notarizing and then runs the staple command.

I have a little bit of code cleanup to do then I'll try again to automate PKG generation.

[gorangrooves]

Packages looks promising. It has a pretty clean user interface with settings for many things. But, I understand how it may not be ideal for Dave's use.

Thinking of a post-install script to create the samples folder link file, I understand that this could be a shell or JS script. What would be the best way to approach this? How do we get the location of the samples installation folder that a user chooses during the install process? You can add a pre-build and post-build script.

@Christoph-Hart Do you know what approach can be used here?

[d.healey]

pkgbuild works! I can programmatically generate unique packages on MacOS now! woohoo!

[ulrik]

@d-healey Nice work David!

[orange]

@d-healey said in Export tool:

pkgbuild works! I can programmatically generate unique packages on MacOS now! woohoo!

It will be a huge in the box solution. Looking forward to hear about the release of it...

[Dan Korneff]

@d-healey

[d.healey]

@orange What are the default install locations for vst3 and aax on MacOS and Windows?

[orange]

@d-healey said in Export tool:

@orange What are the default install locations for vst3 and aax on MacOS and Windows?

macOS

AU: /library/audio/plug-ins/components
VST: /library/audio/plug-ins/vst
VST3: /library/audio/plug-ins/vst3
AAX: /library/application support/avid/plug-ins

---

Windows

VST (64 bit): C:\Program Files\VSTPlugIns
VST (32 bit): C:\Program Files (x86)\VSTPlugIns

VST3 (64 bit): C:\Program Files\Common Files\VST3
VST3 (32 bit): C:\Program Files (x86)\Common Files\VST3

AAX (64 bit): C:\Program Files\Common Files\Avid\Audio\Plug-Ins
AAX (32 bit): C:\Program Files (x86)\Common Files\Avid\Audio\Plug-Ins

If you want, I can also send you the "WhiteBox Packages" installer project file for deep inspection.

[d.healey]

@orange Thank you. I have a whitebox packages installer project already :) I've got the installers building now on Mac, just wanted to double check I had the correct location for all formats.

[gorangrooves]

@d-healey On Windows I have the following.

For 64bit VST3:
C:\Program Files\Common Files\VST3

For 64bit VST:
C:\Program Files\VSTPlugIns

For 32bit VST3:
C:\Program Files (x86)\Common Files\VST3

For 32bit VST:
C:\Program Files (x86)\VSTPlugIns

Can another Windows user verify these on their system?

[Casey Kolb]

@d-healey Not sure if this is useful for you, but I think I just figured out a way to write the LinkOSX file based on the user selected destination in the installer. Whitebox Packages gives you some variables to work with in the shell script, so it's just a really simple two-liner:

#!/bin/sh
# Write sample location selected by user to LinkOSX for HISE
destfile=/Users/${USER}/Library/Application\ Support/YourCompany/YourProduct/LinkOSX
echo $DSTROOT > "$destfile"

If you add this to the post-installation scripts, it'll run at the end of the installer. The only drawback is that needs to be a raw package in order for the samples to be relocatable.

Note: Still need to test this on more than just my machine.

[d.healey]

@Lunacy-Audio I'll try it out. I've added a file selector so you can add any post install script you like to the installer, I haven't tested it yet though.

[ustk]

@d-healey Hey Dave! I'm back on track... I just wanted to say that the Export Tool is an amazing idea! I will definitely have a closer look at it as it is very promising!

[d.healey]

What can you tell me about codesigning on Windows?

[Lindon]

@d-healey said in Export tool:

What can you tell me about codesigning on Windows?

-- that mostly no one does it.

If you are going to add additional code signing I STRONGLY recommend you look at the Pace/AAX signing next.