Export tool

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.

d.healey

@Lunacy-Audio How do you handle this currently?

gorangrooves

@Christoph-Hart The issue I am seeing with downloading the samples from within a plugin is that you have no control over how many times it is downloaded or who is downloading it. When you sell digital products using WooCommerce, you have an option to specify the maximum number of downloads.
While this is not a big deal for small files, it can become more crucial for 1GB archives if they are downloaded multiple times and you are paying for the download data. It becomes even more crucial if your plugin gets illegitimately shared. Then, not only are you not getting paid for it, but you will be forking the charges for large file downloads from non-customers.

In WooCommerce you can cap the maximum number of downloads per product, per customer. You are able to add additional legitimate downloads on a case-per-case basis if needed.

Where and when would this download dialog of yours appear? What if a user needs to re-download?

I am interested in hearing more about your overall concept for downloads from within plugins.

d.healey

@gorangrooves

The issue I am seeing with downloading the samples from within a plugin is that you have no control over how many times it is downloaded or who is downloading it.

Sure you do, there are a number of methods that you could use (these are all server side).

You can track the number of downloads from a particular IP.

You can limit downloads to only the IP that the customer purchased from (probably not a good idea).

You can limit the number of downloads in a set time period.

If you want to get fancy with some PHP (and this is what I intend to do). You can have your user enter login details in your plugin which connects to their account on your server to access the files they have purchased, at the same time you can check on your server how many times they have downloaded the files.

If you don't want the whole login details thing you can use a simple serial key instead.

There are other techniques and you can of course combine multiple methods.

Where and when would this download dialog of yours appear? What if a user needs to re-download?

The implementation if up to you. Christoph will (I assume) just be providing an API.

Casey Kolb

@d-healey I'm planning on using a shell script in the installer so the user can determine where to install the samples in the same installer as the plugin. Almost got it working, but need to play around a bit more. You just need the basic script to create the LinkOS file using the input from the user. Packages is not particularly inviting but it's definitely doable with some effort. Overall, I'm aiming for the most frictionless experience for the user

Export tool

18

1.8k

10.4k

90.8k