Thanks, I've just built it (first time I've tried) and it seems to be working .

Here is an example of the kind of thing I'm hoping to do with such functions:

In this example I had to specify each modulator in the script but it will be great when this script can just inserted in the container and it will add the modulators itself.

Yes, this is reasonable. The method will be Synth.isTimerRunning() (the JUCE Timer class has a similar method so it's pretty easy to add this). I'll also add Synth.getTimerInterval() if I am at it.

This is excellent :)

Well, there is only you and me until now :)

I might still take advantage of your system and script a midi mixer vst to use in Max, since their JS doesn't run in the high-priority thread.....

Yes, 256 or even 128 should also be no problem (things get a little bit tight at 64 samples).

Ah that's good to know. Having all the callbacks in one main file will be good and then other functions can go into external files.

Yea I don't think that would be a problem, if RAM usage becomes an issue I'll tackle it with the other method.

Alright, I'll see what I can do.

There is already a automatic update check for HISE itself (I think since Build 620), which does exactly this.

Done :)

Yes clearly you are well along with a set of FX. Well done (again).

Having a dynamically changeable path of effects is quite useful, if nothing else to allow users to select which filter they want to use, and to set the order. Clearly Reverb ->Compressor has a very different sound to Compressor ->Reverb

The ROMpler I'm currently working on has 4 insert FX slots (where the user can choose from over 15 different FX) and 4 Send FX slots(where the user can choose from half a dozen different FX). The DrumROMpler is even more complex, with 4 channel(Bus) effects, 4 insert(Instrument wide) Fx and 4 send FX, so it can all get a bit fraught with complexity….but users seem to like it a lot...

I really really would not worry about "transfer their Kontakt Libraries" - all of us who build pro libraries would gladly trade a little rework on an existing product for more usable space in the interface. Of course there has to be some limit to how big a VST interface should be, and setting the width to some silly big number seems, well, silly. But in the end if you just set the vertical limit to (say) 650 and allow that to be the dimension that can be programatically changed then setting the width to the kontkat 633 should be fine…

OK, good I guess I'm just trying to confirm that when you say "multiple presets you designed" this is samples and fx routing.

..and MULTI functionality…meeeh, never used them myself, but I know lots of people do...

Incomplete documentation? Clearly complete documentation EVENTUALLY would be nice, but not during this phase, no one should expect that.

Thanks. I wanted to add this feature for a long time because the onTimer callback is not perfectly accurate (it gets executed at the start of the buffer, so you don't have sample accurate timing).

You can write them anywhere (outside of the other callbacks of course), but I would suggest adding them in the onInit page - the script processor checks if the other callback pages are empty and skips the callback to save overhead and if you add the onClock callback on the onNoteOn page, an empty callback will be executed for every incoming note on event.

For the record, the API calls are merged into one method.

Engine.browseForFile(bool browseForFileToSave);

Yes, this is a problem and I am currently trying to wrap my head around a solution for this. It will probably use multiple (stereo or mono) audio files with the different mic positions for one zone, so in the sampler they will be treated as one sample but can be individually purged (and changed in the volume).

What I haven't decided yet is where in the signal path I should blend the mic positions. There are multiple options with different advantages:

1. Mix them together while reading from disk.

Pros:

very efficient and the multithreaded disk preload threads can be used for this. the voice amount will stay as low as with one stereo channel.

Cons:

different effects on different mics is not possible (only volume and perhaps balance but no effect chain).

2. Keep the mic positions seperated until the FX processing

Pros:

You can use all effects with multichannel mics, and the routing can be freely configured

Cons:

basically you have the same calculation effort as using different samplers, but with less workflow annoyances (because it is only one sampler).

Currently I am implementing the first option, but I would like to hear from you guys what you would prefer.

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.

:o :D