The tree hierarchy is the most important difference between HISE and KONTAKT and I chose this data structure because it allows encapsulation of logic that can be never done with a flat list like the group structure of KONTAKT.

Sample Libraries consist of many different types of samples - the most popular being sustain samples, release samples and legato samples. Throwing them all into one big bucket and then trying to adress these types within the big melting pot of groups screams for needless boilerplate scripting code:

disallow_group($ALL_GROUPS) allow_group(1,3,6) // do some random stuff here allow_group($ALL_GROUPS)

I remember writing this type of script code all over the place - before I decided to roll my own sampler
This is because when KONTAKT and their core design was developed, sample libraries weren't that big (legato transitions were the absolute exception and most libraries didn't even had release trigger samples). But thanks to KONTAKT (got to give them that - the sample library technology emerged pretty quickly and I think KONTAKT got overrun by its users.

So now we have the chance to look at today's requirements for sample libraries (and with Elan's phaselocking stuff maybe also about tomorrows requirements) and build a system which has these principles as core organization logic.

@167ixo55:

This confuses me even more. So three separate scripts for three separate types of samples? Again, the samples can be triggered in totally different contexts, and all in a single note-on event. Very often how each sample type is triggered and processed depends on shared data related to note and release events. Splitting that up into three separate scripts sounds like an absolute nightmare and I would never do it.

For me this is the opposite of an absolute nightmare. The ability to write small, highly specified scripts (which sometime consist of only a few lines of code) allows developer-friendly workflows like encapsulation and can be far easier debugged and maintained than the muliple thousand line monster scripts in KSP.

We are not talking about having to duplicate logic into three scripts. Consider this tree

Root container Release Samples Legato Samples Sustain Samples

You would then add one script with release trigger functionality on the first child (this is one line of code), legato logic on the second (again 2 - 5 lines of code to get basic legato transitions working) and a script on the sustain sample that does whatever you like (can't think of a useful script in this simple context

But now you want to change the velocity curve for the instrument. This should affect all samples so you add one ScriptProcessor on the root container with a script that allows this functionality.

@167ixo55:

For example, in one hypothetical case, slide samples could be used as part of a complex legato script in a note-on event, or triggered on release (sliding down from the released note).

This can be achieved by adding some code in the onNoteOff callback of the legato script. Something like that should be enough:

function onNoteOff() { if(legatoReleaseWanted()) // whatever condition you need { Synth.enableRoundRobin(Message.getNoteNumber()); // set the group to the note number (in legato samplers I advice using the groups as start note numbers) Synth.playNote(Message.getNoteNumber() - 12, whateverVelocity); // play the octave down slide } }

Another way would be to reuse the same samples in another sampler called "Release Trigger Downslide" (samples will not be loaded twice if they are referenced in two "zones" or samplers). This approach would be better if you want eg. different envelope times for the two types.

I also encourage you for more examples and use cases - I can understand this different data structure concept needs a different approach in the instrument design but I am confident this is the way to go.

Ok, so this is also implemented.

Basically you call

include("test.js");

And it loads and executes the file "test.js" from the "Scripts" subfolder of the SynthPresets folder.

Nested including is supported and I wrote a simple protection system to prevent recursive includes (if you include two files in each other).

The code in the external file gets treated the same way as the code in the editor (live variable watch, autocomplete).

If there is an error in the external file it will get printed in the console (but the rest will compile fine). But actually you can expect that a external script file is tested and compiles correctly…

Ah yeah, that's a good approach.

@3a2r9y2p:

ctrl + a to select all zones

Done

@3a2r9y2p:

mouse modifier to move zone up and down only (currently alt+drag is left/right only)
mouse modifier to move zone up/down/left/right all at once?

Done. This is a bit tricky because I am running out of modifier combinations (Ctrl+Drag is reserved for copying the samples).

@3a2r9y2p:

vertical zoom (so we can see individual velocities better)

Done. There is a mushroom button (inspired by Super Mario ) that doubles the vertical size. If you want even more size, you could use:

@3a2r9y2p:

pop out map editor window so we can get a large viewing area / dedicated window, this is good for solving small mapping problems (mapping debugging)

Done. It is handled as internal popup (a overlay within the interface) - plugin host behave very funky when it comes to additional windows, so this is a pretty stable way to do it.
This feature is still a little bit buggy (there are many edge cases) - so let me know if you catch a bug with this one.

The current version is uploaded and can be found here:

viewtopic.php?f=3&t=6

I will check out the other requests now...

I think we should look at use case scenarios to figure out if there's actually a better way to approach the concept of having libraries with addons, all possible from a single master patch that senses which samples are present. For example, imagine creating a drum library that could be expanded with additional addon packs without needing to download a patch that addresses very specific ownership conditions (e.g. you own these two addons, but not this one…)

Having a missing samples indication is very important, though. If there are samples that are corrupt or in the wrong location, it's important for the user to know upon loading the library. That way they don't start playing and wonder why certain notes aren't playing.

Speaking of which, here's a semi-related request: the ability to purge single samples. Kontakt can only purge samples on an entire group basis. Maybe it isn't necessary with the whole containers thing, but just having more control over things like that would be a big improvement. It wasn't until Kontakt 5 until we could check the purge state of groups, even though you could purge groups via scripting back in Kontakt 4. So the lack of complete "getters" and "setters" for everything is one of those nuisances in Kontakt.