Export tool

Dalart

This is amazing work, following !

d.healey

I have it working completely now on GNU/Linux. It can run a batch of build jobs sequentially, including producing an installer. I need to do some tidying of the code and some general housekeeping, then I'll move on to MacOSX, after that I'll tackle Windows. Once I have all three working for VST/AU we can talk about AAX and Windows signing.

I had to make a couple of tweaks to the HISE source code, I've made a pull request to the scriptnode branch @Christoph-Hart.

gorangrooves

@d-healey I just want to add one more important bit of feedback/ suggestion.

After giving it a lot of consideration, I plan on supplying my products as single installers that contain both the plugin and samples. I want my installers to take care of the whole process in one go, including extracting the samples to the correct location. I also want to avoid requiring users to have to "hook" up the samples to the plugins on the initial loading, then having to reload the plugin. Those are unnecessary duplicate steps that can easily be avoided with a good installation procedure.

So, my suggestion is to include a simple feature in the installer that accommodates this. Once a user specifies the sample directory and they are copied there, have the installer create the text file automatically and place it in the plugin folder. So, when a user loads the plugin for the very first time, it will already be hooked up and ready to go. No additional, unnecessary "locate samples" dialog.

Just imagine how annoying it would be for someone who purchases a bundle of, say 15 products, to have to locate samples for each plugin, one by one, after they had already installed them all.

I would rather do 15 extra steps on my end to cut 3 steps for the customer on their end. To me personally, this is a must prerequisite functionality for picking an installer software.

d.healey

@gorangrooves said in Export tool:

Those are unnecessary duplicate steps that can easily be avoided with a good installation procedure.

You could have your plugin download/install the samples from a remote server.

So, my suggestion is to include a simple feature in the installer that accommodates this.

I'm not making a custom installer. I'm using Makeself on GNU/Linux, innosetup on Windows, and Packages on MacOS.

yall

@d-healey I did like you finally inno setup and packages. it works pretty well. small problem with packages, text files such as license or background images for example are not saved. I have to look better. besides i will publish my first plugin under the gpu license as advised here, i must do a github or i send the hise project if asked?

Christoph Hart

The problem with installers is that they are quite hard to customize. Innosetup is fine, but especially packages on macOS is unflexible as it can get, and unless you embedd a custom shell script there‘s no way to add an extra dialog for the sample location let alone query this and write the link file to the app data directory.

I also think that downloading the content directly from the plugin is the way to go - we‘re doing it with PercX and I‘ve recently added some features that make this available in HiseScript too (it‘s not 100% there yet).

Lindon

@Christoph-Hart said in Export tool:

I also think that downloading the content directly from the plugin is the way to go - we‘re doing it with PercX and I‘ve recently added some features that make this available in HiseScript too (it‘s not 100% there yet).

--sound of drumming fingers on table..waiting, waiting,waiting...(What me? Impatient?)

d.healey

@yall said in Export tool:

small problem with packages, text files such as license or background images for example are not saved.

License file should be presented to the user when they open the installer. I haven't tried putting background images in so I don't know about that.

yall

@d-healey This is what I did there is even the option, accept the license, I copied the text of the license in question and put a link to download the hise project as well as juce. I think I am in the rules

gorangrooves

@Christoph-Hart Can you please clarify a bit on how the sample library download would be implemented? What would a user do, where, what would happen...?

BTW that PercX is amazing!

Christoph Hart

@gorangrooves said in Export tool:

Can you please clarify a bit on how the sample library download would be implemented? What would a user do, where, what would happen...?

The most minimal solution are two API calls (it's pseudo code, the final API calls might have more parameters):

function downloadComplete(targetFile)
{
    File.extractHrArchive(targetFile);
}

Server.downloadFile("https://myurl.com/archive.hr1", downloadComplete);

which fires the downloadComplete callback as soon as the download is finished, but there are tons of more options to customize it, resume downloads, show the progress etc. You can then fire call this method on initialisation, when the user clicks a download button, etc...

d.healey

@Christoph-Hart :D hurry and finish your studio, we need this :D

Lindon

@d-healey -along with a looong list of other stuff...

d.healey

What file extensions do AAX plugins have on Window and Mac?
Do VST3 plugins have a different extension to VST2 plugins?

gorangrooves

@d-healey Yes, with regards to VST's.
VST 2 have file extension .dll, while VST3 are .vst3.

orange

@d-healey said in Export tool:

What file extensions do AAX plugins have on Window and Mac?
Do VST3 plugins have a different extension to VST2 plugins?

AAX

On Windows: It's a folder that has .aaxplugin extension and also it has sub folders. The signed file is (if it is a 64bit plugin): PluginName.aaxplugin\Contents\x64\PluginName.aaxplugin

On macOS: .aaxplugin extension. The signed file is directly itself: PluginName.aaxplugin

VST2

On Windows: It's .dll extension. For example: PluginName.dll

On macOS: It's .vst extension. For example: PluginName.vst

VST3

On both Windows & macOS: It's .vst3 extension. For example: PluginName.vst3

d.healey

@orange said in Export tool:

AAX

On Windows: It's a folder that has .aaxplugin extension and also it has sub folders. The signed file is (if it is a 64bit plugin): PluginName.aaxplugin\Contents\x64\PluginName.aaxplugin

Thanks, what needs to be included in the installer, is it just the file or the whole folder?

orange

@d-healey said in Export tool:

@orange said in Export tool:

AAX

On Windows: It's a folder that has .aaxplugin extension and also it has sub folders. The signed file is (if it is a 64bit plugin): PluginName.aaxplugin\Contents\x64\PluginName.aaxplugin

Thanks, what needs to be included in the installer, is it just the file or the whole folder?

Whole folder, just as like Hise creates. Without deleting or renaming any sub folders.

But in order to use it on Pro Tools, the core file (in the sub folders that I've mentioned above) needs to be signed.

If you use "Pro Tools Developer Build" you can directly open the plugin without signing. But since The end User have normal Pro Tools, the file needs to be signed.

d.healey

@Christoph-Hart When using the CLI exporter what option should be used for plugin type in order to output a VST3 plugin? Should I just use VST and enable the VST3 option in the project_settings xml?

I've tried this on GNU/Linux but it results in both VST and VST3 flags in the jucer file being set to 0, but I figure this could be an OS dependent thing.

Casey Kolb

@gorangrooves I totally agree regarding the installer. This should absolutely be default behavior and anything less is a serious nuisance to the customer.

Export tool

19

1.8k

10.4k

90.8k