@dark-boubou It doesn't load anything

Yes, that is correct. Be aware that the value starts with 1 (so in order to set it to the first item, call setValue(1);). Zero is reserved for no entry.

If you use the combobox for a control that's supposed to be stored in a preset (aka saveInPreset = true), you don't need to explicitely call this, just make sure you save the patch with the right value.

@christoph-hart if you have a chance play with equator, as on some presets with lots of release you will be able to hear it. (Alternatively just fire up your favourite midi monitor utility).

Would be good to confirm this behaviour, as your unit may be newer than mine. (Assuming it's hardware related- silent refresh etc)

@christoph-hart Ok, I think I understand a little bit, I will try to follow your suggestions. Thanks a lot!

@christoph-hart This works beautiful, I even made a compliment to this using 5 leds that lights up for each button, however I than had to make the ledStates with 5 columns instead of 4, and use:
"for(i = 0; i <5; i++)
{
Lamps[i].setValue(!value == 1 - lampStates[index][i]);
}
and it works fine.

Now to another question, I have 3 different states of the keyboard as well, and I want to set them with the same buttons as the samplers (I have key switches on some keys with coloured keys, and I want to show them and also the key range for that instrument, only in one of the buttons states.
Is there some tutorial or document around that I can study for this matter?

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.

Of course you can use it in the function itself, just be cautious that you don't create cyclic references by doing something stupid :)

This parameter gets incredibly handy when you use one callback function for multiple controls:

const var buttons = []; for(i = 0; i < 128; i++) { buttons.push(Content.getComponent("button" + i); } inline function printMyIndex(component, value) { local index = buttons.indexOf(component); Console.print("You clicked button " + index); }; for(b in buttons) b.setControlCallback(printMyIndex);

I've been using this paradigm in literally every project I am working on since it heavily reduces boilerplate code. Although it comes with a slight performance overhead because it needs to look up the index in the array, so if it's a time critical function, better code it manually...

@christoph-hart It's like magic!! yay~!!

@christoph-hart said in 2 questions, multiple preset browsers and more...:

and then use SliderPack.setAllValues() in the control callback of the Knob:

What about controlling only one of the sliders, now I use "setAllValues" what if I only would like to control the third or the fourth sliders, how would I accomplish that, and is it even possible?

@christoph-hart OK. I already knew I was in over my head but it's good to know that I'm WAY in over my head.

I started out just wanting to build a simple sampler I could throw my custom samples in that wouldn't require too much scripting and could be DAW agnostic.

But now I'm only going to be satisfied by trying to rebuild an emulation of EXS24 with some added features. Guess I better get a lot better at scripting. :(

@christoph-hart Haha, no I caught a trick from d.healey how to find out what id the different parameters had, like a trial and error...
Thank you for fixing this, it's so fun to use Hise and you're doing a fantastic job with expanding the possibilities with it!! :)

In this case you might want to try using an unconnected table on the interface as setting the Velocity using Message.setVelocity() (I've fixed the bug that the value isn't shown), however this works only if you don't defer the main script.

I've tried to make tables interconnectable between scripts, but this is rather difficult because of the order of creation (the first script is compiled before the second one can build it's components).

@christoph-hart thanks a lot

Thank you. For anyone else who comes across this, here is what I've done.

const var pnlStats = Content.getComponent("pnlStats"); const var lblStats = Content.getComponent("lblStats"); pnlStats.startTimer(250); pnlStats.setTimerCallback(function() { lblStats.set("text", "CPU: " + Math.round(Engine.getCpuUsage()) + "%" + ", " + "RAM: " + Math.round(Engine.getMemoryUsage()) + "MB" + ", " + "Voices: " + Engine.getNumVoices()); });

Is Engine.doubleToString() faster than Math.round()?

We were looking at the issue from the wrong angle. ie trying to control too much from the main container rather then on Sampler level. I think that we now have a better way of handling it with CherryAnt. It is down to working out the Architecture of HISE rather then anything else ;) Thanks for your help guys.

@christoph-hart This didn't seem to work for this situation.
I was setting RackSel.setValue(1) on one of my callbacks...

if(value) { RackSel.setValue(1); showPage(3); showTom(0); } else if(1-value) { showPage(0); showTom(3); }

so adding RackSel.setValue(0); to my else if statement fix it!

if(value) { RackSel.setValue(1); showPage(3); showTom(0); } else if(1-value) { showPage(0); showTom(3); RackSel.setValue(0); }

@christoph-hart said in Button animations:

This is not entirely true, I added six state button support a few months ago using this scheme:

Oh sneaky update that I missed :)