ScriptNode Compilation Workflow and What to Do About It
-
@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.
