Export tool

[ustk]

@d-healey it is all command line in the terminal... but => PM because I don't know if it is legal to go further...

[d.healey]

Is it possible to export 32bit plugins/standalone on Mac? And is there any point in doing it?

[gorangrooves]

@d-healey said in Export tool:

Is it possible to export 32bit plugins/standalone on Mac? And is there any point in doing it?

No. XCode won't allow you to export a 32bit plugin.

[ustk]

@d-healey Apple stopped releasing 32bit macs 16 years ago, I don't think many people are still using a 16 years old machine to make music

[orange]

Yeah 32 bit macs are pretty old. But you can still export both 32 & 64 bit supporting Universal Binary plugins with XCode 8 and macOS Sierra or High Sierra. Just tick 'Support 32bit macOS' box in Hise Compiler Settings and compile the plugin in XCode 8.

XCode 10 doesn't support 32 bit.

[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!) :)