Export tool

[d.healey]

Thanks, I'll try to put a check for the xcode version number in my app and only show the 32bit option if XCode 8 is installed.

[ustk]

@orange But why would you export 32bit? Is there demand from mac users for that?

[d.healey]

@ustk Part two of my question :p

And is there any point in doing it?

I guess for crazy people running a 32bit host maybe...

[orange]

@ustk said in Export tool:

@orange But why would you export 32bit? Is there demand from mac users for that?

@d-healey said in Export tool:

@ustk Part two of my question :p

And is there any point in doing it?

I guess for crazy people running a 32bit host maybe...

Like @d-healey said, some crazy users want that :) But very rarely :)

Maybe compiling and distributing 32bit versions separately could be more useful and safe way, also there is no need to notarize that versions too.

[d.healey]

After talking with a some people at PACE and at Avid it seems that I won't be able to include any PACE signing stuff in my app due to NDA/licensing restrictions.

Do AAX plugins on Mac need to be Apple codesigned before or after being put through the PACE signing process?

[ustk]

@d-healey I have my idea for the processing order in the case you want to notarize the plugin but I am not sure... However, you generally want to notarize the installer, not the plugin. While the code signature is for the plugin itself. From what I've read there's no need to notarize the plugins...

[d.healey]

@ustk I didn't mention notarizing :)

[Christoph Hart]

Yeah I haven't ever codesigned a AAX plugin and nobody complained... I can imagine that the wraptool also codesigns it.

[ustk]

@d-healey Sorry but to me, Apple codesign and notarization sounds the same... There's clearly something I still don't catch in there!

[Lindon]

@ustk codesign = "works in a DAW", Notarize = "works as a standalone"

[andioak]

@d-healey

Is this export tool also for exporting towards Linux distributions? Or if not now, will it be later?

Btw, what is the proper Paths for Linux ?? (application, user files, presets etc)

Answer on StackExchange I found on how to deliver for linux, depending on what kind of app you make (a bit complicated, ie. if the app is delivered via a package manager or external installer, has dependencies or is self-contained).

[d.healey]

@andioak Of course, GNU/Linux was the first platform I had it working on last month, since that's my primary operating system.

[andioak]

@d-healey Perfect! Just didn´t see any replies here for it in any earlier messages.

[d.healey]

I'm finishing up the Windows installer and it's thrown up a question I'd like to get your opinion on.

Do you think the installer should allow for both standard and legacy CPU support (see image below)? Or should there be two separate installers, one for modern systems and one for legacy? Or something else?

I think one installer is nice because it means users don't get confused about which installer to download, but it's not so nice because there is now a confusing selection of options within the installer.

[gorangrooves]

I think that what you have in your screenshot is good enough. One installer (to rule them all!) :)

[A Former User]

Maybe just the modern CPU Version for each, then have a single switch somewhere that adds Legacy?

I don't see a reason why anyone would want, say, the 32-bit standalone for Legacy CPU, and the 64-bit plugin without it.

[orange]

I think it could be better to make separate the installers because nowadays almost nobody uses a very very old pc to run these plugins.

• 32-bit / 64-bit Standalone
• 32-bit / 64-bit VST2
• 32-bit / 64-bit VST3
• 32-bit / 64-bit AAX

structure would be straight forward for it.

[ustk]

What @orange said...

[d.healey]

I think I'll go with the separate installer option. I'll get the exporter to automatically build two installers if it finds legacy plugins have been compiled. Do any of you bundle documentation in your installers?

[Lindon]

@d-healey yep - usually the manual...and on windows an uninstaller for the stand-alone...