User hardcoded scripts

[Christoph Hart]

Hmm, that would be pretty complicated to implement (and to be honest, for this particular use case you could also copy all functions manually from your external scripts or automate it another way).

Also the architecture of HISE implicates that every module is savable in an human readable XML file (all the encryption starts at the last stage before compiling the plugin). Adding some kind of encryption layer within this scheme would be too intrusive.

But I have another idea: What if you could compile a script processor into a plugin (a .dll or .dylib) and load it just like the hardcoded processors? You could then distribute the plugin to users who want to use your scripts. I am already doing something similar for custom audio effects so the basics are there.

[d.healey]

Yeah that would be perfect!

[d.healey]

Here is an example of a script I would like to be able to share with other users, it can be dropped into a sampler or container and is used to set the playable range of an instrument, it can ignore notes that are out of the set range, change the colour of the keys on the virtual keyboard, and skip black or white keys. I can't share this with just a code snippet because it has includes from some of my other scripts.

[Christoph Hart]

It should be fixed in the latest commits:

- added support for multiple inclusion of script files · christophhart/HISE@7600b30

The open source framework for sample based instruments - - added support for multiple inclusion of script files · christophhart/HISE@7600b30

GitHub (github.com)

[link text](link url)

[d.healey]

The multi-inclusion seems to be working well, I like that it gives a notice in the console, but that isn't really the issue with my post in this thread :)

[Christoph Hart]

That's embarrassing, I was only reading your last post and thought it was the other thread :)

I have another proposition: How about a "CompressedScriptProcessor", that includes every external dependency but GZIPs the script into a binary file (or base64 encoded string just like the web snippet string)? You can then just distribute this file and it should contain everything to run.

It won't be any sort of copy protection if that's what you're after though...

[d.healey]

That sounds like a good solution. Copy protection isn't an issue as I think they should be open source so developers can adapt them to their own projects. Would it include everything in the external files or just the functions that are used by the "main" script? Would it be able to resolve absolute file paths or will that end user have to sort that out?

[Christoph Hart]

It would include everything (also absolute files). I don't know if its necessary to strip unneeded stuff, normally GZIP can reduce the size of text files pretty good (i could make some tinyfing operations like removing comments and whitespace before that).

[d.healey]

I think comments and formatting should be left in, or their removal should be optional.

[Christoph Hart]

Making it optional it is :)

[Christoph Hart]

Alright I implemented a minimal solution:

1. You can export and compress a script using the context menu of the editor (Export as compressed script). It replaces all include statements with the actual file content (and skips multiple inclusions), then compresses it with GZIP and saves it to a custom file with the ending .cjs ( = compressed javascript ) in the project's script folder. This file should contain everything that the script needs.
2. You can import a compressed script, also using the editor's context menu (Import compressed script). Select a file and it will load it like a uncompressed script.

From this point on it will behave like a normal script - however everything that was included before is now written into the onInit callback, so it will bloat the preset size if you have a big include file for everything that will be duplicated for every script (in this case I'd recommend increasing the modularity of your file layout to reduce the amount of unnecessarily included code). Also the script is just as visible to the user as the uncompressed version - it just makes sharing easier.

This is highly expermental - I only tested it with some minimal examples, so let me know if there are issues.

[Christoph Hart]

Update: I added removal of unneeded namespaces before compressing. If a namespace isn't mentioned anywhere outside its definition, it will be removed. This also handles referencing within namespaces, so this code:

namespace firstUnusedSpace
{
    reg a = 5;
}

namespace secondUnusedSpace
{
   reg b = firstUnusedSpace.a;
}

Console.print("Empty");

will be truncated to the last line even if the first namespace gets referenced.

[d.healey]

This looks awesome, I shall try it out soon. Thanks :) you work very quickly!