ScriptNode Compilation Workflow and What to Do About It
-
I see you already pushed a few commits regarding this. Nice.
I pulled the latest one, 0a39f3d4dfcceac85a0eb0e61051cd731b9fc2a5, and found a lot of my networks to be broken. I figured out it's due to nested networks being removed; or at least refusing to load as nodes, because if I compile an older commit, like 56023e4dff900aae469bd5c040c5a48686a52a39 from Jan 21, they load back up just fine.
There's no way to add nested networks anymore and the entire Project tab is missing from the Node Browser.
There's no mention of this in any of the commit titles so I don't know whether it's a regression or just work in progress.
-
@aaronventure yeah I might have been a bit too ambitious with the cleanup.
What is gone now is the ability to freeze / unfreeze nodes as well as to run the compiled root network from a script FX - this was a complete mess on the implementation side and probably caused the script FX to crash in a compiled plugin. I will add a tool that allows you to automatically convert a script FX into a hardcoded FX module as this is a major gap in the development UX right now but this makes everything more predictable and stable in the long run.
I also removed the ability to load uncompiled networks as a node (so nesting of uncompiled networks is not possible anymore). However I probably need to roll back this change as it was too intrusive.
-
@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:
I also removed the ability to load uncompiled networks as a node (so nesting of uncompiled networks is not possible anymore). However I probably need to roll back this change as it was too intrusive.
If you wanna introduce this back as a "function" (read again the last section of the first post where I mention Unreal) where it's available only in that network and the edit dialogue for it opens in another window and any changes are reflected in all instances of it, now is a good chance.
-
I figured out it's due to nested networks being removed; or at least refusing to load as nodes.
There's no way to add nested networks anymore and the entire Project tab is missing from the Node Browser.
Alright, that was only happening if you don't have a compiled DLL present - I've fixed that now to show dummy nodes that you can click on in order to compile the DLL - this should also work without restarting HISE now.
Feel free to check it out, I've also spent a few hours changing the UX of the entire compile process to be within the HISE window now so it won't spawn a console and block the UI.
-
I will add a tool that allows you to automatically convert a script FX into a hardcoded FX module
Alright that's also implemented:
This operation is also performed whenever you export your project through the new compilation dialog so it's guaranteed to never use a ScriptFX with a compiled network in a compiled plugin!
-
@Christoph-Hart Amazing work this will be such a time saver!
-
@Christoph-Hart awesome, thank you Christoph!
-
@Christoph-Hart Ahh that's right, now that you removed the need to restart HISE, networks marked as Allow Compilation can be compiled prior to the exporting process.
Is this what this dialog does? Are networks marked as Allow compilation now automatically compiled on export, i.e. there's no need for swapping them for hardcoded anymore just for the export and I can work on them, click export, test my plugin, then come back and the network is still editable?
-
Are networks marked as Allow compilation now automatically compiled on export,
Nope, but almost. On compilation the ScriptFX modules are replaced with their hardcoded counterpart so we're 80% there. What's missing is that if there is no DLL present at all (or the DLL was never exported manually once before), it won't create the C++ files for the networks that will be included in the plugin export.
I've added this step now too in the compilation process although I'm hitting a few issues with hardcoded FX not being initialised correctly if there is no DLL present.
I'll sort this out and then commit it, but this will make it very convenient - you actually do not have to bother at all about compiling scriptnode networks anymore and it will be all taken care of at plugin export - unless you want to compile the DLLs before to see that state during development.
-
@Christoph-Hart Awesome!
Let me run down the original post and see if I understood you correctly.
1. Individual SNEX Nodes and single-instance Faust .dsp programs
This is now solved because the networks get compiled automatically at export.
2. Function-like Node Chains and Nested Networks
You mentioned this could be behind collapsible node chains (lock thing). I mentioned functions in Unreal Blueprint. Also, if I got it right, networks cannot be nested unless they're compiled first. How does this play with a workflow where we need to compile just that network? To be clear, I'm talking about editable network chains that are used repeatedly across networks, which, when edited, update appropriately everywhere.
3. Faust Specifically
While single-instance Faust nodes need no compilation anymore, requiring a single .dsp Faust program to be used across multiple places in a network (or networks) will still pose challenges:
- when the .dsp file itself is changed, are all Faust nodes sporting that .dsp file automatically updated across all networks or do we have to manually hit the refresh button?
- why are parameters not being rebuilt on every compile? I found that there's zero downside to doing it other than the second long visual glitch, because the cable connections always get restored properly. It's just an unnecessary extra step that you always have to do when you make parameter changes, and it always does recompilation again anyway. The node craps itself anyway (all the parameters go away) if you have a code error, and the rebuilding happens then. Why not have it happen all the time and remove this manual step from the workflow altogether?
Sometimes Faust is a good alternative to making a long node chain, so this is in fact also the other side of #2 problem in this post, it's just done in Faust.
-
Hardcoded Master FX and hardcoded Polly FX Instant crashing HISE.
-
@DabDab try deleting the DLL in your project and try again.
-
@Christoph-Hart Tried. Not working. Still crashing.
-
@DabDab Im currently experiencing problems compiling dsp's also causing immediate crash upon clicking compile. I've resorted to only using script fx nodes as it allows me to still use certain features but im still not able to work at full capacity for some reason that I cant figure out. This thread seems like its right on point!
-
@Christoph-Hart Where do I get the latest version of HISE as you guys are updating? Sorry if im redundant, im still new to this. You're greatly appreciated!
-
@Chazrox said in ScriptNode Compilation Workflow and What to Do About It:
Where do I get the latest version of HISE as you guys are updating?
GitHub - christophhart/HISE: The open source framework for sample based instruments
The open source framework for sample based instruments - christophhart/HISE
GitHub (github.com)
-
@DabDab Thank you.
-
Not working. Still crashing.
Oops, forgot to push a simple typo... should be fixed now.
-
@Christoph-Hart Please add currentGitHash.txt and currentGit.h files.
-
@DabDab yup, done.
