ScriptNode Compilation Workflow and What to Do About It

[d.healey]

@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:

Ah yes I can see that. I'm probably doing it differently than anyone else here,

What about a checkbox in the exporter?

[Christoph Hart]

@d-healey nah, that pollutes the exporter interface with an option that nobody ever uses. I'd rather remove this from the entire workflow and make it a separate command tucked away in some menu if the general consensus is that it's trash.

[d.healey]

@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:

general consensus

I don't use it enough to have an opinion.

[Christoph Hart]

Let's also please not forget that Networks with Clones can't compile.

Just checked, works here, however the compilation with clones is a bit more delicate than usual as it performs a few additional sanity checks and the results of those were not being displayed as error message when they fail (which I've fixed now).

In my test case there was a mismatch between the parameter range of the clone_cable's NumVoices and the clone container's NumVoices parameter and apparently this makes HISE go boom.

After fixing the error manually in the network the compilation goes through and I can load in the cloned network in a master FX.

[clevername27]

@aaronventure Thank you, by the way, for putting so much thought into this stuff, and helping make HISE better.

[aaronventure]

@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:

Why not? This step is necessary for making the procedure as painless as possible to the point where you don't need to care about replacing the modules manually.

That it doesn't work in the current state is not an argument against this :)

I'm not sure if we're not understanding each other on this; I don't care how the sausage gets made, but I wouldn't want it to swap out all of my ScriptFX to hardcoded when I press compile, only for me to have to restart HISE to get them all back to ScriptFX state where I can open them and edit them. As long as they're put back into editable state after the compilation finishes, it's fine.

I'll compile a plugin, head to a DAW for testing, and come back to HISE to make changes as necessary. I have a setup where I route all MIDI from a DAW to HISE and then audio from HISE back to the DAW for single instance testing which makes it actually bearable to work like this, but as soon as I need to test multiple instances in a real-life project, I have to export the plugin.

In my journey so far I haven't found a reason why I'd want a hardcoded FX in a project, unless it was a performance issue during development. Luckily I have beefy CPUs on macOS and Windows, but not everyone has, so sure, when working on big projects some devs will have to swap it out. But even so it creates issues when working with multiple systems: I'd put all my ScriptFX into hardcoded here on macOS, then on Windows, I can't even check if they're working immediately, I have to compile first, and if it doesn't work I have to swap them out one by one until I find the culprit? What about committing to version control?

@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:

Ah yes I can see that. I'm probably doing it differently than anyone else here, but I never ever "work" on my scriptnode patches in the real project - when I want to do changes, I'll make a new HISE patch, load in just that network and hack away, then recompile and load the actual project.

That sounds kind of masochistic, haha. I guess it depends on the type of a network you're creating. For me, one network is most likely contextualized by another. In this current project everything is ScriptNode so I'm not making use of modulators (there's no Sampler, for example).

On the latest commits that attempt to address the compilation issues:

• Compiling an instrument plugin with a Waveform Generator with ScriptFX network which has a Faust node with osc.dsp works as expected
• Compiling an instrument plugin with a ScriptNode Synthesiser with a network which has a Faust node with osc.dsp crashes HISE on compile start

If Allow Compilation was not enabled, the plugin with a Faust node will compile fine but won't work: I suggest either a warning in the initial Compile plugin... window if there's a network without a flag that happens to be sporting a non-hardcoded Faust node, or just always using it if there's a raw Faust node. I haven't checked whether this would be an issue for SNEX nodes as well. Probably?

Also, another one that's boggling my mind: I'm running into an issue where if I run a compilation on my primary project, it it compiles fine but in the background, in the console (not the compilation log) there's an instantly visible error about the first call in an init part of a MIDI processor in a container that calls setAttribute for the big network, so line 20 or so, having argument 0 as undefined, meaning it's not resolving the name of the network parameter, and the resulting VST just plays a click on MIDI input, while the continuous signal is inaudible but it's this

I cannot reproduce it in a new project Even if I remove everything from the DSPNetwork except that single parameter, it still throws undefined in the old project, but compiles fine in the new one. Project is FUBAR? I've had this happen once with an xmlpreset where it just failed to ever show SuspendOnSilence for any new network created.

I'll keep testing but if you have any ideas, I'd love to know.

[d.healey]

@aaronventure said in ScriptNode Compilation Workflow and What to Do About It:

why I'd want a hardcoded FX in a project,

Compiling a complex network is almost certainly going to make it more CPU efficient.

[Christoph Hart]

Alright, then I'll just remove the entire "Replace ScriptFX with hardcoded modules" option from both the DLL compiler and the plugin export. If you want this function, it will be under Tools -> DSP tools (or whatever).

Compiling an instrument plugin with a ScriptNode Synthesiser with a network which has a Faust node

There is currently no hardcoded version of the Scriptnode Synthesiser - for a polyphonic synthesiser you can use the Silent Synth in combination with a polyphonic hardcoded FX module that loads your faust patch - this should work:

HiseSnippet 1595.3oc6X80SiaDDecfM.4350S8jtp9jEOEpno1I4.hNU0CBvUTKbQWnn6Mzh8FxJb100dCPZUeuer5Gg9QoeCZmwqShcHGjKkd8kZDgryL6NyNyu4OF9MZtzm6eVrTDFx0Dh0BshTd73XUDwpzICB4DqUosGH0ca1kIjjC2iX8IziXwZdjsgztCBYwwbehk0BuFIXsxhjjm+7a2kEvjd7wjHjSUBO9OH5Izio15UeuHH3.lO+DQuLRW+UG5ojMUAp9f8r.0gDx7tjcA+XFJVAJ46XwcIVeIsZmy8p1YqZa61vswV0a359hsOutSUO+WznVsMq42o51rM2F1Tw88EZUTaMSyigCcWk+f1cUWKMJ3TQr37.NtvkzFzrgLoYWQf+HmSL3pnYbUKXbUOidjvWLh9XW1mlvvd7Nx5zrJbWlj6GfIYkwjVzXROk11KRDpGyAsmGQOTBQvNLH1j0TLxRr9cZSEHfTWoG6R9AQvhQan7lNNaXCer9K6zW5oEJosRdrRyeir75k9kRqT5WKYOIqNclJOTMQpf.dzTYivgn6Zikk86cNOZC6qXA84iDDt948oEmMepm4VmQPk7PoP+lPd55CTA9nuB+9si.jT2F7se7v8XZFFTRoAxExizBzbr1ieEjFXBQqP2iGeoVEBIB2J9AHGke+.lNObBSzRY.9ibwPLPIiE5AYSD+.vXN2IFaVMwmRaIzdcmtMVXJ1H3o92vFSyLeLc+Nc3d5wF3hzCd27lFN6pe4gpusH.AVXkzD0+jTJ1Ijbuipn+wrVEMblqhZsvCUEmE+OnH3CC.8txgJ7uaNTt5zEM13ySqSKU97jfKFK4lp0eQFd1ILsMbyCaNRIUgcURgWVjxa45HwEW.GUFh+Suet+eMhGPHPpOpTZXFzIp7USWZev6bmZS5eiNtgXXDOjEwOQ0JfMnbLqWX.+sfMtg84AJuKaK9Y9s6hFZLgcQIJ60kIk7f34oYawGJfyaU80B4EGw.L6MvHVG2uWanpkGuYp0AzrJf8YMqcv0HtnMLHaxh+BdRY5hqsRY5NjYlVzGy0WqhtLIbj9ch0Rnu+4zPUv.SxzYwI96y5biKYmf.00MU8BEo.1jqTB0Vi1P5klGEmHwRTmJvODy1FdS1ompOXDoWGXL1SXh.D12teLLrg+ajI8Gvp9Hr6XH0G7yGv7.+7fVLnKBj9fiq.XUdTEuQX12moOFAg9dy.zuOYQsMregw+BFeOzogybas.xG8ZKjZVndWh1g0OVSxYhqBlXDuhgyzrfg659zXlgm.JoqfJCEPUuBsY.bxG5SNEAlvIPUwdIo3YE6IHbpEKBTLLJa7PgSfhYHi4lCWA2siDxTAKRqhwwiX2jRXEf.7.zZq4gXNF18yohqi4wsdCGW2McShKEoch3+zPktDsZxgsGGt+A5InRZeMVX7DVzEbMlWjwO+HZr.ytOiEk2W+LJWdEO.txUFKwz74YOg6wuSy42slMGpARO4c.P1YHjNWrjmThIdBwuE2rKIlrAHZCFvUX2vy5wjLrC2HaAYtJEaRZ5Wlbsfq7MCmIeOQbHTob29PEeSLOGE7BBuY7MXKfuxkrOT1yGF6OY2niIOdYwL3kkFiWnz7vkkotyDZo8k7qMQVi.0bbcpABznw10arkiANsLcGsFdY3gN8Oit41UpmbNNtMpVqQ8ZS.tJBpuRVn9GOicE5a4AbVLmj2VtWCr362.oT2bVmYsIS60PeHRt8kWSFZYUD89TDdvON0m2rezUyx4OdvlolIOI5MW17mONaNuTSKidxS5dxpKLKU6lc+ctDsIcDnP6zWq5Agjjw5HYKojKOhbmEaVkdX7oHWOVvPeObZ6pTW1ikzDe9dk6OFib7wPG8XdQpy7LSpgNvkSn.vDYBFYE5Q3ZaWxUocuFMTcO30xNyyK+QcqMVcd2Xs4ci0m2M9h4ciaNuabq4ciae+aDeq4zTHr8GTWo09lNQV6KYvf0IuU.gm1jx75AX9vHJR9MG.SSljV0QfShW.+iLs3QxHXeMLxTE+3vg+OvHVRJLlfJRWdsXsehLUBDmu15urTIbTF6uwtabfvmGUdMb8ZaXCSu.ej7qC9OID5W.Rm9ZFf7p3JfVJiRu9F4V8xRDxeCHTXu3C

If Allow Compilation was not enabled, the plugin with a Faust node will compile fine but won't work

Yeah, that should cause an error / warning or hint - same with SNEX as you imagined. I'm not 100% sure what the best UX would be - the most friction-less option would be to just set the flag automatically as soon as you add a SNEX or faust node to a network, but then people will complain about this just as they do with the automatic FX replacement function.

[d.healey]

@d-healey said in ScriptNode Compilation Workflow and What to Do About It:

Compiling a complex network is almost certainly going to make it more CPU efficient.

@Christoph-Hart Am I correct here?

[Christoph Hart]

@d-healey In general, yes it's good advice and recommended - if you don't need the scriptnodes to be dynamic / interpreted for reasons, then there's absolutely nothing that should hold you back from compiling them to C++.

The performance benefits range from completely neglible (eg. if you just load a convolution reverb node into a network) to complete and utter game changer (frame-based modulation).

I thought about adding some more data points to the new profiling toolkit that allows you to analyse the actual overhead that the scriptnode interpreter introduces, this way you can quantify how much performance you'll use.

[Christoph Hart]

Yeah, that should cause an error / warning or hint - same with SNEX as you imagined.

Alright, this is implemented. I went for a check at initialisation and a autofix button that automatically sets the compilation flag and removes the error, this should be the best of both worlds.

[aaronventure]

@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:

There is currently no hardcoded version of the Scriptnode Synthesiser - for a polyphonic synthesiser you can use the Silent Synth in combination with a polyphonic hardcoded FX module that loads your faust patch - this should work:

Alright. You might wanna consider removing the Faust node from that environment's browser and if someone loads a network in there that has one, it should spell out a warning. Otherwise it's just wasting people's time.

@Christoph-Hart said in ScriptNode Compilation Workflow and What to Do About It:

Alright, this is implemented. I went for a check at initialisation and a autofix button that automatically sets the compilation flag and removes the error, this should be the best of both worlds.

Cool, cool.

Some more regressions now, though:

I have three networks. Network #2 has Faust stuff in it and produces clicks until I tick AllowCompilation (otherwise the node is red and probably uninitialized). When I press Export > Compile plugin, that network gets swapped for a hardcoded one in the background immediately and the order gets messed up, it shoots up right to #1. That's how it compiles and once it finishes, the plugin output is the same as I get in the HISE IDE post-export with the now swapped network, i.e. it's broken. This doesn't work.

Regarding hardcoded performance, just so we can clear it out once and for all, can you please fill this table out?

	Performance - HISE IDE	Performance - Exported Plugin/Standalone
Raw ScriptNode
Hardcoded Scriptnode

If there is a difference between exported plugin raw scriptnode and hardcoded scriptnode, you definitely should do that to each network (unless something is preventing it... global cables?). There shouldn't be a performance penalty for devs that choose to keep their projects accessible for easier tweaking, iteration and version control.

I just think that once it gets swapped out during compilation, it shouldn't stay that way. Is it an architectural issue? If so, can you leverage the virtualization system used for the snippet browser and load another instance of the xml, run the compile on that and close it on finish?

[d.healey]

@aaronventure said in ScriptNode Compilation Workflow and What to Do About It:

can you please fill this table out?

It depends on what your network does, there is no single value for either of those columns.

[aaronventure]

@Christoph-Hart I see some more work being done on the compiler so I'll bump this in case you missed it: starting compilation shoots AllowCompilation projects to the top and swaps the hardcoded version in.

We discussed the reasoning behind swapping in the hardcoded versions and leaving them in once the compilation completes; imagine you're producing a piece of music and upon pressing "Render", your DAW takes some tracks and freezes them before rendering, then leaves it like that once the render is done.

All the details are in my last post. To summarize the setup:

Network1: ScriptFX
Network2: ScriptFX with a Faust node and AllowCompilation=true

I'm also not seeing the networks at all in some instances in the hardcoded module... Their name appears once they open the first time after compilation finishes, but there's a warning that the DSP network is missing and if I click the dropdown, it can't find any network to select.

Once you tackle the hardcoded bug, I have another idea for Faust, inspired by your prompt on the Direct Access thread: do you think Faust nodes should be compiled individually as the first step, and then replaced in the ScriptNode networks? This way the networks remain dynamic/accessible even with Faust i.e. using Faust doesn't deprive you of other functionality.

If they're then set to AllowCompilation, then they get hardcoded and swapped in (but only for the export, not permanently - see the previous post or the one before that for the virtualization idea or whatever you do to make it work).

[Christoph Hart]

@aaronventure So is this all we need?

- remove script FX replacer · christophhart/HISE@fc2e654

The open source framework for sample based instruments - - remove script FX replacer · christophhart/HISE@fc2e654

GitHub (github.com)

[aaronventure]

@Christoph-Hart

It's not - Faust does work with the automatic compiler.

1. Empty project
2. Script FX wherever
3. Faust node
4. Obey the red warning and turn on AllowCompilation
   5 A dsp file that says process = os.osc(440), os.osc(440);
5. Hear the sine
6. Export - Compile plugin -> Instrument, VST3 (right, turn it in in the projects, why is this still a thing)
7. Load the plugin, no sine. Play a note, the saw plays, as if the ScriptFX isn't there.

Instead of forcing AllowCompilation on Faust and SNEX node, what do you think about these nodes being compiled individually as a first step, then replaced for the export process? This should also allow networks without AllowCompilation to use them (though the whole thing doesn't seem to work with Faust right now). This will allow Direct Access via the hidden Parameter API to be used with these nodes as well.

FaustTest.zip

[Christoph Hart]

Instead of forcing AllowCompilation on Faust and SNEX node, what do you think about these nodes being compiled individually as a first step, then replaced for the export process?

Isn't that the exact same idea that made me #if NOPE that stuff out of HISE but on a deeper level?

[aaronventure]

@Christoph-Hart is it?

That if NOPE was just replacing the hardcoded effects in the project, no?

I just think that:

• If it plays in HISE, hitting Export should mean that it will play in the plugin; there should not be any hidden steps
• using Faust or SNEX in a network shouldn't deprive us of functionality that doesn't play with AllowCompilation

AllowCompilation is a performance boost for "lots-of-scriptnode-stuff" networks, right? For faust I measured little to no gain, but right now faust seems to need compilation because of the way it's implemented.

So if that could be done for the raw faust nodes when hitting export, then they get replaced with compiled in the process which should, if I got it right, have it work when exported and leave the networks available for global cables, direct access etc.