ScriptNode Compilation Workflow and What to Do About It

[aaronventure]

@Christoph-Hart

Here's the big test of the new compilation workflow that involves Faust. Sorry I couldn't get to it sooner, I had to refactor a lot of the networks to not rely on nested networks, and then got caught up in other stuff.

TL:DR: it's buggy as fuck. Faust is now Schrodinger's Cat of HISE for anyone who hasn't gone through the trials or reads the forum religiously: the only thing that works is manually replacing Faust nodes with their hardcoded versions and everything else has it either producing clicks, no sound at all or being completely bypassed in the final exported plugin, all the while working in HISE and compiling successfully.

---

Here's a snippet. It's just a Scriptnode Synth with a Faust node that has Osc.dsp loaded, and it's just a sine oscillator.

I'm on macOS 14.5.

HiseSnippet 1257.3oc4W0sSibCE1SBF1jR61sZun8tQq5EPEaHSR3utpp.gjtQcAhHTTuC4LiCwhYrGY6.jV02s9HzGk9Fzd73LISfHZHpc2V0fDI97i827c9YNldmlxCnAWp3r3XpFgbx2VJ7oJkPhbJd9vXJxYUbmgbc+58ILNp0QHmOAeLQooRWqnCGFSTJZ.xwI+2YD3TXITxme+aOjDR39zIhPnKDLe56XQL8Dos2+6YggMIAzyYQYrt19s7E75hPw..O4wkQwD+qIWQOgXLKGF8VhpOx4qvU500uRucptq2dd6sSs8771Z2t0JWwOXq8pVc6pA8prKY6cAmVtQ.SKjczDMUAa5ghfgc5KtkaOfKXJV2PpYgGpCbxVwn58YgAiIGEPU3LTUdKU8R7wr.1X4SnrOMQg6DOxRZN4dLH48DfjSFHsjERu.2wWxh0SzXvyGgawgHXOBDaxBEqsHmeEWW.Fv0khHWSaJgEicXssKWdCW3eq+ldC39Zlf6J3mHzzS4qsdwetXgh+RQ26qpWuYpybLRQXHUNS0lzA4i43Z7AQcoxMbugDNfN1P3weZNc44iS8sO0YLTvawY5SioiV2TDFX3JyueXD.Mh1fe8CsNhnIlfxHYfcwTolYfiyQzafx.aHp.9Hp5ZsHFJDdP7CxbDACBI5oSmLEZiT.7wTwPSfhqX5gYKDeB4Xkezbr4Ehu.2lo86OaLlaFXDXp+Iv3nJyOF2nWOpudB.WB27GWzxv4+3Kjd71JqjNoIG+WLRBWDPcSDSULEU58H8S+s4seZ7b2OMsfeC7So35d8PWZ9JtlNmMi8ynS1xe.Zt92Sh+GvZyo5+WHEicXQwgzF7angPCnDL9YPGmdjAg5ToSm0crfKh6K3L+rIZmQ0R1UWQkYw9LefNPqgWSOQxK2+LZHknxjI9k6+NFmRj.OQWPt3o+tvYFu9brEttlRE2+61SM++a5o9XTzyvMtSKId+KL5MBZUdeBsyDCzL9UGSfR26fQVOYPTGn2uOEfEmSCgMG6jyL2hccYyZCH5.WLHYwe.eFozyr1YjRuTkYF44Dp9Vg75jpuQ+F4rh4YeU74Tk9PIk.u96fvPws0EQwrQYw.OjHqsHbXZeGmbVKRQ5AQhAvgLBtvX+mSXgFy5LPACmEbJuCXbx6FcxeAUpR13UvkKA+AkAmjznY4lDefXG11fCndxLuGDenxR9iiSSg0rwJ6kNlRsYWSecpk3.TGYXCykSRtMU5Le1NRlUPrNm8fZotvn0mDhtv7JVyySxdZoPKjMltBFZWqznof+p.7kzRVMODno97jvXt6gwB35gv91JHEfX7oJ+jb9rl8bSlUahDNX3VBpwF6Xud2DEPxysldXmSjWQ0p6q7Pg35HRRJzhM.86iD9HhuTboucFICo8rDI.UxSH9Bv8ig0tdnarzvj1wQvfJW56O8V8.GqrnNVcQcr1h53VKpiaunNtyh53t+0NZli7fAZQjsuDBcb6FIIgNNM3DnkaR4EhBSEG.2BzN7rIWcrDN8tlPenj52dLSO5blurH441JxMgJnRAp3zaahb9I7la51zny0ls5Z1ju1ELrHnotoYCMvEpb5691VcZ.in6Vobksdc4pu1qRQX.OgTu1qT5fjCnTHq6qV+MEisuJv8abUrRciIx0prgqPURn7WqVsxqClfP+IfedQuD

• The Faust node in the Scriptnode Synth works in HISE
• It doesn't work when the plugin is exported using the new Compile Project exporter
• If I compile the dynamic library first and replace the Faust node with the compiled osc node, it makes no sound in the Scriptnode Synth, or in the compiled plugin
• The compiled osc node works in ScriptFX in HISE, and if the plugin is compiled that way, it works, too
• The RAW Faust node with osc.dsp works in HISE, but doesn't work when the project is exported that way using the new exporter - it's as if i doesn't exist, e.g. if it's put into ScriptFX in a Waveform generator, in HISE you'll just hear the sine (because it overrides the waveform generator output), but the exported plugin will play the sound of the waveform generator on midi input
• if using the raw Faust node with osc.dsp in a ScriptFX and setting the network to AllowCompilation, the ScriptFX goes grey once the plugin export starts, remains bricked afterwards and in the exported plugin it's as if it's not there, e.g. waveform synth output still comes through
• if instead of exporting the plugin we start the DLL compilation and set the flag to replace ScriptFX with hardcoded, it fails to do so and the network is not visible at all in the hardcoded FX dropdown, either in the wavetable synth FX section or in the master fx section, no matter if polyphonic or master fx

Can anyone else confirm this? If I got this right, this means that:

• You cannot use Faust in a Scriptnode Synth, yet that particular Scriptnode environment still lets you load in a Faust node
• You still need to run the DLL compilation, then manually replace your nodes in your network if you're not flagging networks as to be compiled (due to usage of global cables, for example)
• there's no way to just enable AllowCompilation for a network and expect it to work

The Culprit?

So it looks like the issue is with hardcoded FX replacement is not working properly, as it invalidates the network from being able to be located in the hardcoded FX dropdown, Faust or no Faust

Takeaways

There should be no need for developers to have to manually swap Faust nodes all over the place with compiled versions. Faust nodes should compile anyway even if no AllowCompilation flag is set, and then be replaced with their hardcoded counterparts in the network (would this mean the new exporter runs the DLL compilation twice?).

Additionally, as mentioned earlier, editing a .dsp file and hitting F5 should refresh it all across the project(not just the current network) and regenerate the parameters. If that's somehow problematic, it should at least be doable with Shift+F5.

[aaronventure]

@aaronventure @Christoph-Hart the recent commit seems to have made some changes, so here's an update

HiseSnippet 1466.3oc6X0sTaaDEdElkDbnMMcRmzK0joWX5PLVleBzLcBfAm3oAvCxkz6XVKsFuCx6pQ6ZHNc588wpOB8QnOB8Mn8bjjskHNDpaKIYZMy.dO+n8aO64mOA+UFtzm6ehVJBC4FBwpPyHkGWqUQDqhsFDxIVKPcGHMcq0kIjjF6RrliZ3ZCYmAgLsl6SrrJ7LTm07yRh+76OcGV.S5wGKhPNVI73uPzSXFKs4VemHHnNym2RzKi0qtUCOkrlJP0GvQAZERHy6L1o7CXnYyPIOmo6Rr9ZZ0Ns8p14wqrgylNa93U2zwYsMZuZkpd9qs4Jqr9J9cptAa8M.mlaOegQE4ZX.5IVytixefaW0ExjM3XgVzNfiKbHtvNmHttJvGOhnTRsth.+QAHMDtnYBWERBW2mtuvWLR93v1mEqvdrGYCfVyjGdExAOmrvqRF3MAHYkARyl.o6Qc8hDglwZP7bGZCogG0gA2SYgRhsDqegVSAFHMk6wNiWOBVLxgRqWoxR1vuV7Ic5K8LBkzVIOPY3GJKsXwer37E+oh1WVUmNSTGtMQpf.dzDUioFQWkikj860lGsj84rf97QFBG+7wT5aOll8J2K4TmwPkrgTXNLjKeaIBjzPE7suuwtLCCuHRkA1ExiLBDBV6xOGJCRtVlmtKWelQEBEBuwcFjsn76GvL4SgvBsTEPLH28Fd4H0ByfrEh+ikWccg38nMEFutSFiyLALBQp+MvXZ03mP2qSGtmYL.mkV+Gt4J8JlV5A6YRM2vkNSrl6moiyuCi3grHdKUy.1fRZVuv.9Q.DWxtcfx6LWwq4uYQQXBB1AsnjWWlTxCzSSsybW6fhyUembjpuQHOcelIR7JnH7f98bg15d7ZonCjYMCVBkrtBtFSKbgYSwK9C3SpRGbsUpRmgJyT8c.2bgJ5r3aizuSrtEF5+Tp.6dIYAm3qCIGyizX1o0snUJC+P1NHPcQMUuPQZdKbsDKqoJXPXWkT3ghRrXH32tmpOruom.XnTKlH.Szc6qg1E9GJcAiimDBIZVGn7wIQ0YdPncPSloKVvfMbfrSdTYuQYoWBsiyUvnbxTvKYB9rGNwLI.BPsGFUv4kVEP8w0HrHvcvwzBlg8lRRewUPw4LHFVf1PeLp0iEPNFyOvS1e6FbOHQ4cnujcNOlZQ7I9KhW2QE0y9YbHXfsUbtBRF+50kjQ30ljwgdF.BshXRcnRycx9jc48DsTRtNmzK4Q0I5QNo6xM8k4ezIhxYEFJpCghL1c6sFJrZVgMYxbOLXctmz9XQ2vk+1S2SxfxVWNbx8OT6AAFLNmchQy9AZ9KE9ltNYcbr3pYE+bVjObG5kqedgqhpkyTR0ZtO3nZ8QvT6bijleHFcE3rj8jmyCfJ2XL94PoZGV+.yPo4K81WIUC6AN9h9HNzS+zS44xel3AZaiAHvOVx825Hd.moyTN9Ua8BnGHKZ+3djSUrv4u734Ide8kzD3Zi8Kr+3ksUg+qy1Zgzk1+Ocqab5VKPaw0lch3HImqAYK7f89itUNzNIxV4L3ZR0ZD.vc3VTn8p1PxAlE.vDwKmnYRa6PudW6XNdbybIdbySqE.O4F9CIwQovn+Qj+FZ1cwbkLrCSMNNOKGoQ2KvdNsXQmxMePvn7pG9BLf9vtI9Cvqip1wcxse+zJ+lnqwMwdzi4EoNwKoYKlAd6XIv4VFWOMOcebssC47jruwAyd.iwS77x+ndCGqNsNtxz53pSqiqMsNt9z53imVG23c6HRne69FUujZC3EaZtWbWCKqj2oItLgvgwq9vqQjLgGSsGIQxeUcX5PbeoNBrrXF7OIH4tIMZWFpDKiuMc5+DPh0qoKurccTmcR1pM9P9FavvhflZ3DAtuMzRrq8ya3tGLq2tZkpq8nJq7HmMJBLsUQlROTa7i2fxAh1ObwmTLk3f82ZqEkaCDOJUcIaktrR6UZ0UqrHXBg7mDbE1sE

This is a snippet that:

• Has a waveform generator with a single ScriptFX
• The ScriptFX has a single node, which is a Faust node, with a osc.dsp file which is just si.bpar(2, os.osc(440);
• The network has Allow Compilation enabled

Export > Compile project results in a VST3 plugin that either pretends the node or the network doesn't exist, i.e. the saw synth plays on MIDI input

Export > Compile bricks the script FX inside the HISE project, which makes it go gray and the 440 hz sine changes to 200hz (???). If you click on the scriptFX and see that the network has been selected and instead select the compiled Faust file ("osc"), the sine will be at 440Hz correctly.

Exporting with Export > Compile project if the network was selected in the hardcoded dropdown results in it being bypassed and a saw synth plays on MIDI. If the Faust dsp file, in this case "osc" was selected, then it doesn't work either.

Faust nodes being in the networks that don't have Allow Compilation enabled still don't work when compiled with Export > Compile project

Triggering project compilation should not automatically replace ScriptFX instances with the hardcoded versions.

[aaronventure]

@aaronventure

Some further testing: I created a new project with the same setup

FaustTest.zip

Commit is 6bc83f40afce511cc97efe5390ead05538eb3bb6 from 9 hours ago.

Setting the network to Allow Compilation and attempting to Compile Networks as DLL results in

• BUILD FAILED **

  CompileC /Users/testuser/HISE/Projects/FaustTest/DspNetworks/Binaries/Builds/MacOSX/build/FaustTest.build/Release/FaustTest\ -\ Dynamic\ Library.build/Objects-normal/x86_64/include_hi_tools_02.o /Users/testuser/HISE/Projects/FaustTest/DspNetworks/Binaries/JuceLibraryCode/include_hi_tools_02.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'FaustTest - Dynamic Library' from project 'FaustTest')
  (1 failure)

[ustk]

@Christoph-Hart Same error as @aaronventure, even when removing the Faust node

Compiling DSP in general is painful as hell at the moment, as @aaronventure really well described the thing.

I'm spending about 80% of the time disabling AllowCompilation, deleting Faust node, recompile, load compiled Faust, re-enable AllowCompilation, recompile networks, close/restart, load/unload Hardcoded/Script FX, clean the scriptFX that is constantly and undesirably appearing, then finally compile the project... And that's when things are going smoothly...

[clevername27]

@ustk @aaronventure @Christoph-Hart Let's also please not forget that Networks with Clones can't compile.

[Christoph Hart]

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

Triggering project compilation should not automatically replace ScriptFX instances with the hardcoded versions.

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 :)

Export > Compile bricks the script FX inside the HISE project, which makes it go gray and the 440 hz sine changes to

Yes I can recreate that, will investigate as this seems to be the root of most problems described here.

[d.healey]

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

Why not?

I can see an argument why you wouldn't want this.

If you are working on a network and want to compile it to test certain things, then you want to go back to working on it. Now you have to remove the hardcoded effect and re-add your script effect.

Is there any world in which these can be combined so that you can seamless edit an already compiled network in the backend and when you recompile it will update on the frontend and you don't need to swap out modules for either?

[Christoph Hart]

Is there any world in which these can be combined so that you can seamless edit an already compiled network in the backend and when you recompile it will update on the frontend and you don't need to swap out modules for either?

We had that with the "freeze node" functionality and it was complete hell and Bugfest 2000 with a separate node instance lurking in the dark and overwriting complex data connections that lead to doubled filter coefficients and other stuff down the road.

If you are working on a network and want to compile it to test certain things, then you want to go back to working on 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.

[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?