Export tool

Lindon

@d-healey why not build 2 different packages - one including stand alone one missing it and use(search and replace) either depending on the user selection..

d.healey

@Lindon I'm not sure how that would solve the problem, could you provide more info about your idea? Here is an example of the template project Christoph and I mentioned.

While we're discussing Apple stuff, do you let XCode handle the code-signing as it's compiling your project or do you do it through the commandline manually after compiling is complete?

Lindon

@d-healey ok so the thing you are pointing at is an xml file generated by whitebox packages yes?

So its for a package that includes VST3, AU and standalone yes?

Simply create another whitebox package - this time with only the VST and AU elements and export(save) its XML

Now you have two templates - one for VST,AU and Stand-alone, and one for VST and AU. Offer your user a choice:

Include stand-alone? Y/N and depending on their choice use the relevant template.

So on to Apple Stuff:
I manually codesign all my plugins... and stand alones.
Then I manually notarise my stand-alones.

--I wait for apples success email then...

I use Whitebox packages for packaging - but its set up to use my developer certificate so its codesigned as soon as it builds.
When its built I notarize it.

-- I wait for apples success email then...

I staple the package, and zip it up - done!

To be honest Im not sure how you'd get all of that done with an automated process...I can see how you'd do it up to building the package ...but waiting for the success emails?

d.healey

@Lindon Oh I get it, I'll need more than two templates to cover all combinations but yeah that seems like a workable solution.

I didn't think you needed to notarize the standalone if it was included in a notarized package? - At least that's what I saw in the KVR post.

Yeah the stapling part with the success email would still have to be done manually, unless Apple provides some sort of API that gives a notification (I'll check).

Hmm which of these do we need (I assume just the bottom one, do we need to codesign the installer before notarization?):

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.

Export tool

14

1.7k

11.8k

102.4k