Multiple instruments, single project or multiple projects?

[Christoph Hart]

Yeah, I pretty much abandoned the possibility to have more than two front scripts (I think we discussed this a while back) and I wouldn't rely on that design approach.

[d.healey]

Oh yeah I'm sticking to the panel method for multiple tabs, works great. I was just testing the multiple front-end to come up with another way to do presets. So it seems everything that I want in a preset has to be part of the main GUI script?

[Christoph Hart]

Basically, yeah, but you can do a lot of stuff eg, store Objects as JSON data and copy them to a global variable in the onControl callback or set an attribute of another script that fires its onControl callback.

[d.healey]

Ah that sounds clever a way to do it, good suggestion!

[d.healey]

After more thinking, I think my needs are going to be too complex for the preset system to handle because for the different instruments I'm going to have a different number of samplers, and I'll need to be able to change the sampler IDs on the fly (because my UI makes use of these for the various articulations), there is some other stuff too that will make it a bit messy to handle. So I'm thinking I'll use the preset system for "like instruments" that share the same articulations, number and order of samplers etc, and use a separate VST for those instruments that require more than the preset system is intended for. But I'll stick to using a single HISE project for all of my woodwind instruments since they are closely related and rely on the same code and most of the same instrument setup and I'll just create separate .hip files for each.

[Christoph Hart]

For what do you need the Sampler IDs besides setting the label on the interface?

If its only for displaying the name on the label, it should be doable with JSON:

// onInit

reg instrumentData;

// in onControl

// This will come in from the preset recall
value = {
   "name": "Trombones",
   "releaseSamplerEnabled": false,
   // ...
};

instrumentData = value;

// Activate an additional sampler if needed
ReleaseSampler.setBypassed(!instrumentData.releaseSamplerEnabled);

// Set the label name
mainLabel.set("text", instrumentData.name);

I still think it'll be more cleaner using just one plugin and you can't underestimate the workflow benefits of just having one preset file.

If we're at it: I don't know if you knew this, but you can save the presets as .XML file instead of the binary .hip file format. While it increases loading times a bit (only in HISE, not in the compiled plugin), you'll get a ton of benefits by using a version control system like Git for the XML file and the scripts. It even extracts the scripts from the preset when saving and stores them in local .js files and reassembles them if you reload the plugin.

If you do this right, you'll end up with nice clean commit history that looks like this:

Especially if you are planning to release the library on GitHub as GPL, it would make a hell of a impression if you could actually reconstruct the building process in a nice clean way.

[d.healey]

This looks too tempting, okay, I'll dig in a bit more and see if I can get on with it :) and the GitHub stuff is an awesome idea

[d.healey]

What is the ValueTree automationData expecting in the Content.storeAllControlsAsPreset() function?

Also, I keep getting this message with the latest version when I select a User Preset (even a new one)

[Christoph Hart]

I think a filename string with (or without) an extension. it will write it in the user presets folder.

You need to use semantic versioning for your project in order to use user presets. The reason is that then you'll be able to bump the patch version number a.b.x without having this popup appear (which is annoying for small bug fixes). If you add new controls, bump the minor version number a.x.c and it will add default values of those new controls when you press OK there.

[d.healey]

I think I'm misunderstanding something

[Christoph Hart]

You need a patch version number. 1.0.0 will do :)

[Christoph Hart]

Ah and you don't need to specify the version number in the filename of the preset, it will be stored inside the XML itself (using the current Project Version Number)

[d.healey]

This is a preset I created in the preset browser not in the script that is causing this popup

[Christoph Hart]

The preset has probably still the old wrong version 1.0 baked in. You can edit the .preset file (it's just an ordinary XML file) and correct the version number manually.

But I'll add a safe check that you have a valid semantic version syntax in your Project Version before creating the first preset to avoid this in the future...

[d.healey]

Do you mean the .hip preset or the user preset? That might be where I'm getting confused

[Christoph Hart]

.preset is the file extension for user presets (=collection of front end interface values). The .hip preset (NOT a preset, poor name, bad decision :) doesn't store the version value (only the Build Version of HISE), because it doesn't need it as it can get that info easily from the Project Setting file, while the .preset files are supposed to be distributed along with the plugin and don't have that kind of privilege :)

[d.healey]

Ok that's what I thought. Then I'm still confused, thank you for your patience :)

I made a brand new project folder, inserted a script processor, put in one command Content.makeFrontInterface(600, 250); compiled it. Then I opened the plugin preview and went to the preset browser, created a preset and then when I try to load that preset by clicking on it I get the version number error. This hasn't happened to me previously. I can make a little video if it helps.

Update:
So I opened the preset file in sublime text and the version was set to 0.0. I changed this to 1.0.0. I tried opening it in the preset browser again and I got the same error (it said version 1.0.0 this time though). I click Ok to update it and it resets it back to 0.0. So I think there is a bug here.

[Christoph Hart]

have you set the Project Version at File Setting Project Setting?

[d.healey]

Aha! mystery solved. Nope I hadn't set that, never have, I will from now on :) thanks again.

[Christoph Hart]

This is important as it will also show up as version of the compiled app / plugin. I'll add a safe check that requires to set this before exporting.