The internal JSON list will indeed be accessible only via the UI elements. However when you save them / load them it will be stored directly in the XML element (I've played around and this is much more versatile as it allows sharing of modules without having to rely on another JSON file like David suggested).
This is an example script with one Knob that has it's max property set to 40:
Now there's just another child element called ContentProperties which contains all non-default values. No more weird JSON comments / autogenerated boilerplate stuff in the script.
The only breaking change so far is that if your interface was creating only by using the autogenerated JSON data from the property list, it will become some sort of "read-only", which means that it still loads the correct properties, but the property lists (and the UI dragger) will not change the JSON code anymore, because their property changes get overwritten by the already existing JSON data.
Custom filters using scripting is a bit difficult, because the overhead of the scripting engine starts to play a role for polyphonic materials, but I am thinking about a different way of adding additional filter algorithms to the current HISE filter.
Ah yes, this is a bit misleading. I mean monophonic in contrary to polyphonic (FLAC and all other codecs have to work with fully mixed and mastered songs, which isn't the case when just using samples).
Actually I fixed this drive-by-style while I was rewriting the parser to support namespaces, so this code will work now:
works(); // "yep"
inline function works()
If you're interested in the gory details, I added a "preparsing" level, which analyses the script and stores the IDs of const vars, reg and inline functions so that the actual parser knows if a variable name is one of the mentioned types.
Looks like your connection to Topics created by Christoph Hart was lost, please wait while we try to reconnect.