Ah yeah, that's a good approach.

The past few years I find myself using more voice event-based scripting than anything–like rather than relying on keeping track of voices and voice-related information through arrays. That might just be due to how limited Kontakt's arrays are, though.

So with a guitar library, you might want to attach data to the voice, like which string is played, for example. Then if you need to mute all the notes on that one string, you can loop through the playing notes and selectively mute ones based on that data tied to the voice.

Having to have the includes in each script isn't such a big deal. But I'm assuming you can have includes within an included script, right? It seems like we can really quickly reproduce everything that you can do in Kontakt scripting, but I'm envisioning in the future entire frameworks could be developed for a variety of benefits, such as fast prototyping, different approaches to organizing complex instruments, making complex behaviors accessible to beginners, etc. That way you would essentially just include a single JS framework file, which in turn would include all the packages it needs, etc.

Having pre-defined control types that address most all situations is fine, but would there be any way to have a custom type that gives developers access to drag x/y, click, hover, etc.? That way if they want to make something really specific that isn't possible through the existing control types they can always use the custom one?

Doesn't Javascript already have "global" and "local" variable scopes? I guess by global, you mean in the sense that the variables are available outside the single script itself, correct?

I like the "Engine" object approach, since that looks like a pretty natural way to work. I assume the data type is conveyed when setting the global variable, too? For example:

var exampleArray = [1, 1, 2, 3, 5, 7, 13];
Engine.setGlobal("fibonacci", exampleArray);

Would you be able to have global functions as well?

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.

Cool stuff–currently handling variable RR in Kontakt is a bit of a nuisance. Right now it usually involves "blipping" a zone to see if it exists first. This can always be cached into a lookup table (that's what I did when scripting CineBrass, for example), but the problem is that the only way you can see if a zone exists in a group/velocity/pitch is by actually playing it. If the zone ID returns "-1", then you know there's no sample. It's inefficient because ideally you should be able to check mapping-related data directly through scripting.