Export tool

[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...

[d.healey]

@Lindon Is the manual a single file or a documentation folder containing multiple files?

[Lindon]

@d-healey its a single pdf...I am of course thinking of going over to this new fangled in-line documentation panelly thig that all the kids seem to be down with......

[d.healey]

@Lindon I'll include the ability to add an optional pdf to the installer.

[Lindon]

@d-healey nice...

[d.healey]

Status update:

GNU/Linux: Fully working (standalone, vst2, installer). x64 only
Windows: Fully working (standalone, vst2, vst3, installer). x86/x64
MacOS: Fully working (standalone, vst2, vst3, au, codesigning). Needs a bit of tuning but almost there (installer). x64 only.

When I say fully working, that's in my own tests, I expect many a bug report when I release it into the wild.

It's quite possible that AAX plugins will compile just fine on Windows and MacOS too, I've implemented it in the app but haven't tested it.

If all goes well I should finish up the tuning of the MacOS build tomorrow and it will be ready for my patrons to test this weekend!

@Christoph-Hart Could you merge my juce_template pull request (if all is well) as the mods there are needed for my app. The mods are also useful for regular exporting from HISE, bigobj is enabled by default and the VST3 SDK is set correctly to the one that is in the JUCE folder.

[Lindon]

@Christoph-Hart - yep those additional changes to the juce_template will be very helpful...