Export tool

[d.healey]

@gorangrooves

I can't specify the VST3 category of my plugins, which Projucer allows.

I've just been looking into this. When I export a VST3 instrument from HISE and open the .jucer file it creates the VST3 category is set to instrument and when I export an FX plugin from HISE it sets the category to FX. So it seems like it's already there.

Interestingly though when I open the .jucer file in a text editor I can't see any mention of the VST category, even if I resave the file in projucer first.

[d.healey]

It's starting to look a little nicer now.

[gorangrooves]

@d-healey Yes, HISE specifies it as an instrument, but that's too generic. Is it guitar, keys, drums? Using Projucer, for my plugins I always select both "drums" and "instrument". They show up under "drums" VSTi category in my DAW. It is very handy for having your plugins properly organized.

@d-healey said in Export tool:

Interestingly though when I open the .jucer file in a text editor I can't see any mention of the VST category, even if I resave the file in projucer first.

That's rather strange. Not sure what to make of it.

[lalalandsynth]

@d-healey looking good !

[Dan Korneff]

@d-healey this looks great! Well done. Will it contain Signing abilities?

[d.healey]

@dustbro That's the plan, on MacOS anyway (does anyone sign apps on Windows?).

[SampleScience]

@d-healey said in Export tool:

@dustbro That's the plan, on MacOS anyway (does anyone sign apps on Windows?).

AudioThing does it to prevent Windows 10 security message to pop-up. It just looks more professional but it's not necessary.

[Lindon]

@SampleScience said in Export tool:

@d-healey said in Export tool:

@dustbro That's the plan, on MacOS anyway (does anyone sign apps on Windows?).

AudioThing does it to prevent Windows 10 security message to pop-up. It just looks more professional but it's not necessary.

....but it would be a nice option.. .

[orange]

Congrats @d-healey! Awesome work, sooo useful. I'm looking forward to see this release :)

[d.healey]

For Windows signing I'll need input from someone who has a Microsoft ID (or whatever they call it).

[DanH]

@d-healey fantastic idea, thank you!

[Dan Korneff]

@d-healey mac and PC aax plug-ins need to be signed for use with protools. I can send you more info if needed.

[d.healey]

@dustbro thanks, I'll pm when I'm reach that stage

[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?)