ScriptNode Compilation Workflow and What to Do About It
-
Unfortunately I was not able to make it to the meet, so I decided to convert my notes about Scriptnode into a post here. On a second thought that’s maybe even better, as this way it’ll stay here easily searchable and visible.
I wanted to talk about the current ScriptNode workflow with regard to compiling of networks and/or nodes.
ScriptNode evolved a lot in the short time that I’ve been here, but the compilation workflow seems to be stuck in a time where it was a smaller scale add-on to HISE.
In its current state, the compilation workflow is incompatible with large projects, and by that I mean any network with a lot of interconnect and repetitive node chains.
I’ll examine three examples:
- Math Expression node
- A node chain template
- Faust
The Expression Node
I’ll use it as the most basic example of a problem that the current compilation workflow introduces. This is a very important node that could play a very significant role in almost any network, but I find myself avoiding it at all costs because it requires network compilation in order to work in the final plugin.
This is problematic because network compilation is not just freeze-in-place like a track in a DAW. You need to enable compilation for the network, run the compilation process, restart HISE, load your project, remove your network from the chain, add in a hardcoded FX module, and add your network there. You cannot leave your ScriptFX network in the chain, even if it’s bypassed, because the exported plugin will refuse to scan in a number of DAWs, and there’s no warning in the exporter for this. Even if it didn’t, that’s a whole lot of additional clutter.
This is fine if you need a small modulator that you set up and forget. It’s not fine for big networks where you are likely to be making changes a few dozen times in the future. It’s also problematic if you’re using that network in multiple places in your entire project tree, because in order to make changes, you need to now load in the scriptFX network in all the spots, and every time you make a change, you still need to reload in order for the change to be reflected everywhere, which in this case means restarting HISE.
A good workflow in big projects requires a lot of testing, which means a lot of plugin exports. Every time some major change is made to the project, I export it to make sure it still works both as a plugin and functionality-wise. If the plugin is conceived to be used many times in a standard composition/mixing session, that needs to be tested, too, which makes the plugin version of HISE unsuitable for the task (but also because it doesn’t have a FAUST version).
The Node Chains
There are cases where you need to have a node chain repeated a number of times across the network. This is the same as a function in code. HISE has node templates, but the major problem with it is that if you make a change in one instance, it’s not reflected in another. This could be beneficial, true, but in order to have the changes reflected in all instances, you need to do that whole thing in a separate network. This clutters the network list as the only way to differentiate between these “function” networks and networks to be used as modules in the main tree is to settle on a naming scheme and name the networks accordingly.
Once you have them all over your main network (loaded from the Project tab in the Node Browser), if you make any changes to any of them, the network requires a reload (unload the network, then load it again) and if you’re using them in multiple networks, it’s easier to just restart HISE. God forbid you used an Expression/SNEX node in there which mandates that you first need to compile the function network.
Faust
When working with Faust, you cannot just leave the faust node in your network and compile it, expecting the network to work. The compiled faust node needs to be used in order to export the plugin. This is a bit problematic because in the Projects tab in the Node Browser, there’s no real indication that this is a compiled faust node, and not a compiled network. A simple naming error can take you places. If you’re going to be using a compiled faust node as part of a bigger network, you need a separate network where you’ll be compiling the faust.dsp files, then unloading that network and reloading the main network where you’re using the compiled faust node. The compiled faust node by itself currently has a lot of bugs, which I posted on the Github issue tracker.
What to do about all of this?
I’d recommend to always look to Unreal Blueprint when in doubt about UX changes. That thing has been in development for the past 12+ years and has received contributions from dozens, if not hundreds of people. It's incredibly smooth and easy to work with. Unreal Blueprint has 2 types of “node chains”: macros and functions. Macros are project-wide, and functions are local to the blueprint where they were created.
A blueprint is the same thing as a network in HISE. When creating a function, a new window pops up and you build a node chain like you do in the base blueprint window. You can define function inputs and their types, as well as function outputs and their types. The function then appears in the sidebar while editing the main blueprint, and you can either add it from the search/browser or drag it from the sidebar. Any changes you make to the function itself will be instantly reflected in all the functions in the blueprint.
This would somewhat solve the Node Chains issue.
About Faust and SNEX, if compilation itself cannot be added to the export process automatically, maybe there should be a freeze-in-place option. Right click, freeze the node, it instantly becomes available in the projects tab in the Node Browser. If you unfreeze any instance, make changes to it, then freeze it again, all other frozen instances should automatically update. For faust this can be tracked based on the .dsp file, for SNEX it could be tracked using the file as well. No idea how it would be tracked for the expression nodes. Maybe they’d be assigned another type of ID on freeze.
I wrote about expression nodes requiring more inputs (maybe dynamically like the xfader node) as their strongest trait is that the expression is visible and instantly editable.
-
@aaronventure With the repeated node chains, can't you compile it as a separate node and then it will show up in the "project" tab and I believe that will keep all instances in sync.
It's been a while since I've used scriptnode but there used to be a thing that if you were using a compiled node it would show up with a snowflake icon, and you could click it to switch between the compiled and uncompiled networks. I just checked and that doesn't seem to be a thing any more, or I'm missing a step.
-
@d-healey There's also talk in the docs about being able to export a node (like a chain) to cpp, which you can then store in a location like the script library, which all projects can then pull from. There are some options when right clicking but it does nothing. That would be cool as well - the equivalent of macros in Unreal Blueprint, or even better (because they can be shared between multiple projects.
ScriptNode also needs like a reload button that doesn't require closing HISE to pull in the new nodes or refresh the existing ones if they're an embedded network and a change was made there.
-
@aaronventure great write up, I'll definitely take this advice into account when I'm back working on scriptnode. I understand most of the issues, some are just bugs that have not caught my attention (eg. the faust things), but some are harder to implement:
- multiple inputs / outputs for expression nodes will create the question on when you want to do the recalculation - when the first parameter changes, when any of them changes, and to which outputs do you send it to?
- If I try to remove the requirement for restarting HISE after compiling, then there will be a lot of glitches from intermediate nodes being tied to the old DLL file and all the edge cases - what if the parameter amount changes or the amount of complex data slots? However I think I can revisit how difficult it is to implement - I actually wrote a few things that allow this (eg. that's why the project dlls have a counter in the filename because Windows cannot replace currently loaded DLLs), as I can see that this is a somewhat annoying roadblock in improving the workflow with scriptnode.
and you could click it to switch between the compiled and uncompiled networks. I just checked and that doesn't seem to be a thing any more, or I'm missing a step.
Yup I removed that for several reasons as it created many subtle issues (eg. both the uncompiled and compiled node referencing filter graphs and other shared resources) and in the end the only target audience for that feature was me so that I could compare the compiled and uncompiled nodes as a debugging tool (which should be completely identical in the ideal world).
I got an idea about the node chains: In the last round of scriptnode refactoring (alongside the template stuff) I've added a new "Lock container" function which collapses any container of a network into an opaque node (that looks like it was compiled) which helps a lot with modularizing and organizing big networks. Currently these locked containers are not linked if you duplicate them, but I could add this as a feature so that if you make edits inside one of the locked container, the other containers will update too. That's a complex thing to implement though so don't expect it to happen to soon.
-
@Christoph-Hart please do fix the silent_killer not being passed through multiple polyphonic scriptnodefx all the way to the synthesizer group ;)))
a simplification of the workflow would sure be nice, but I have somehow gotten used to it, there's probably a lot of smaller bugs and glitches that can be far more annoying and could use some love, before you revisit the entire scriptnode system/workflow ;)
e.g. adding a parameter in hise still messing up all the cables sometimes, even if you click "rebuild faust parameters"... often enough only loading another faust script into the node and reloading the original one helps. I would document them if I could accurately reproduce them but it seems like it happens at random. ;/yesterday I had to create a Hardcoded Polyphonic ScriptFX node 8 times before it finally decided to remember the network I had assigned to it after saving and reopening the project ;)) I'm sure if we could get this a little more rock solid more people wouldn't be "I avoid compiling networks at all cost" ;))) I feel them lol
A couple of less alert popups after compilation, at the start of hise and during the save would be great though. By know I know I have to close and reopen HISE, still don't want to initialize the defaults on startup and am really sure I want to save the XML if I hit CMD+S and am even sure I want to overwrite it, though that question is probably legit although not standard on apps ;) I do this after every line I write, just out of fear HISE will crash on me when I hit compile and my line will be lost ;)) So that's a lot of confirmations a minute and I am such a lazy bastard as it is ;)))))
-
@Christoph-Hart also please let us color all nodes and the main container aswell as having the background of them also tinted ever so slightly, it makes things so much more neat and clear :-p
-
@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:
multiple inputs / outputs for expression nodes will create the question on when you want to do the recalculation - when the first parameter changes, when any of them changes, and to which outputs do you send it to?
No need for multiple outputs, just inputs, like the xfader node, so that the expression can then reference input1, input2 etc in the calculation. I honestly can't think of a scenario where more than 4 was ever needed, but if you already have the system worked out in the xfader node, it can't hurt, right?
@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:
when I'm back working on scriptnode
Will you at least be fixing the breaking bugs like the Faust channels thing and the compare-into-soft-bypass? That (along with ScriptNode Direct Access which you'll find the Feature Requests forum) are the only real barriers to my progress, everything else I can work around until you get to it (even the soft-bypass thing can be worked around but I can't imagine that being hard to fix).
-
@aaronventure yup the bugfixes are on my immediate todo list.
-
Cotinued from the Github discussion on Faust vbargraph: https://github.com/christophhart/HISE/issues/619#issuecomment-2602609622
This means that the Faust node needs to be within the network with the sole purpose of providing a public mod for the Faust node. Also, there can only be one public mod per network, and it cannot be named. It would be cool if it took the name of the publicmod node and wrote that instead of "drag to modulation target" (perhaps it could switch to that text on mouse hover).
Also, the compilation results in two additions to the project tab
The .dsp file itself (here named "test" and the compiled network.In the project tab, there's no tag or anything to tell us which is which. There's also no way to exclude the .dsp file from appearing here, even though it's (theoretically) useless without us having access to its vbargraph output.
This again forces us to use a naming scheme where we designate faust effects like fst_ or something and networks with ntw_ or net_.
Perhaps you could add a category for Faust in the browser, and another for networks.
-
@aaronventure or add a "private" flag to the faust C++ nodes so they don't show up in the browser and only the ones you wrapped show up?
-
@Christoph-Hart that's an easy way to hide them, yes. It would still be nice to see at a glance which effects are Faust. Does making another tab for the compiled .dsp files sound so bad? I guess you could add an F icon next to them in the projects tab, but this just seems a lot cleaner. Perhaps the tab only shows up once there are compiled faust effects to show?
-
@aaronventure that sounds super useful. Where to are those faust nodes compiled anyways? are they in the DLL or can they be easily moved to e.g. another project once compiled? that would open up new ways to build a whole assortment of nodes and tools and share them with each other without the need to share the source code and compile
-
Also, there's a need for a "Clean Network Compilation Directories" option which will clear out all compilation data.
If you compile a network of Faust .dsp programs, then remove some (or all) of them, then want to compile again, the compiled Faust .dsp programs will show up in the to-be-compiled list just because they were previously compiled.
This can lead to errors where you might accidentally use them (they're still available in the Projects tab) even though the original nodes don't exist anywhere, nor is their .dsp file present. But if you then pull the project back from the remote repo (given that you're not committing the compiled dylib), you can end up with a major whoopsie.
Given how the compiler writes the .cpp files for the faust .dsp programs into DspNetworks/ThirdParty, how should that be managed in gitignore? Isn't that also the directory where you put your own third party cpp files? How to handle manual cleaning?
-
@aaronventure There's already a special tool for this: Export -> Clean DSP Network files.
