@ulrik It seemed complicated to me at first but it's not too bad. Here's one thread on the subject - https://forum.hise.audio/topic/52/variable-persistence. There's another one somewhere but this should get you started.

I wanted the same thing there is a really long thread about this somewhere. You can create a hidden panel and store an object with all the settings as the panel's value. or you can do what I ended up doing which is to create a separate file that contains an object with all of the settings. Whichever method you choose to store your data you then need a function (or several) that takes the data and sets your various modules when a preset is loaded.

They sound good - although I'm not familiar with the real instruments. Now tell me how you did it

Ok I worked it out. There is a bug but it only happens when using multi-mic samples. With a really low offset it causes some nasty distortion and noises, with an offset greater than 1 millisecond it causes an instant crash on my system.

Hmm, seems the issue isn't with the function, I need to debug more.

Am I right in assuming that the value passed as the offset should be in samples?

I'm getting instant crashe/close when using any offset greater than 0, I even tried setting the s.mod to the full length of the sample.

For my current project I've settled on the following design (which is kind of a modular view-model controller approach).

I have the "main" file which is a thin controller that brings the other files together and handles the callbacks. It also has a project wide namespace that all of the other files can access.

Then I have a bunch of smaller files each with its own namespace. I have a manifest file which is basically a large JSON object that holds various info for all of the different presets (in my case each preset is a different orchestral instrument with its own set of articulations, keyswitches, key ranges, etc.).

The next file is the theme file which holds all of the styling information for the UI. Having this in one file allows me to apply a different look to the whole UI by editing a single file.

Then I have a paintRoutines file which holds all of the various panel paint routines and SVG data - There are no images on my interface, it's all vectors.

The next file is the preset handler. The functions in here take the current preset name, look up the data for the preset in the Manifest file and applies the correct settings, loads sample maps etc.

Then I have the bulk of the scripts which is spread over six files. I have a header with all of its controls at the top of the UI, and a footer with all of its controls at the bottom of the UI. The next 3 files are for the main parts of the UI, an articulation handler, a mixer, and a CC handler. The last file is for a settings window. Each of these six files sets up its own view (GUI) and assigns callbacks for the controls, this is why I call them view-models. Some of them also have functions that can be called in the controller's onNote and onController callbacks.

Now although this seems like a lot of code the majority of those files have less than 100 lines and there is probably less than 1000 lines in total. I've chosen this approach because having a lot of specific files with a small amount of code in each allows me to very easily track down bugs, maintain my code, and reuse the code in other projects.

@ulrik Sounds like it's being a little buggy. I suggest just trying to map all your samples in one go rather than adding samples to an existing map.

Looking at the latest commits on github I see that Christoph is doing some tinkering in the sample map handling so maybe this will be resolved soon if it is a bug.

@zaxo-herbert The embed audio files setting is for impulses responses in the audio files folder, in your hise project folder, it's not for the samples which should be in the samples folder.

@remarkablex Aha perhaps it's only on Linux then...