FR: Script API for includes

[elanhickler]

Really important for any project big project is the ability to include variables, functions, etc.

-There should be a way to include ONCE (in one script processor) so all script processors have access to the include (so you don't have to write the include in every single script processor)
-Including things in individual processors would be nice.

[Christoph Hart]

Adding some kind of include functionality will get on my TODO list, but I am afraid a global include for all script processors would mess up the encapsulation principle I am trying to enforce with this design.

Adding one line like

include("toolbox.js");

for every script does not seem to be too much effort.

And how would you handle the external script files in a finished instrument - still as external (e.g. in the same folder as the image files) or included in the preset?

On the other hand if you need functions multiple times in every script processor, chances are big they are a useful API addition so you can save you the trouble of including for this use case

[elanhickler]

So in toolbox.js you have

include("myfunctions.js");
include("myotherfunctions.js");
include("someSWEET A** FUNCTIONS UP IN HERE.js");

And in each processor:

include("toolbox.js");

For a finished instrument, the code should be written directly to the instrument file/package. After that, changing the include files will not affect the finished instrument. The end user does not need access to include code.

Oh, I think we need a global "compile" button to recompile all script processors so that when the developer updates an include file, it is easy to "refresh" the code in HISE.

[gregjazz]

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.

[Christoph Hart]

@2ms219on:

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.

Same as in the other post, I would rather write additional modules on the C++ side - it is not that much harder as soon as you figured out how to set up a compiler (JUCE is really awesome in making C++ easy). Actually the ScriptProcessor and the underlying Javascript engine was designed for rather small tasks and interface design (and the ability to add them in different places removes the need for all boilerplate code like in KONTAKT so none of my scripts I wrote for any of my instruments have more than 100 lines of code).

[Christoph Hart]

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…