Compiling C++ nodes and Scriptnode Networks
-
As a side note, is it possible to add a toggle on the compiler menu for selecting which nodes to compile? I think this could really speed up development time if we want to just compile and focus on one node, or skip a bunch of Scriptnode Networks we don't intend to use. Basically just a checkmark box to "AllowCompilation" before compiling.
I don't see a real use case to be honest. Either stuff compiles or it doesn't and if it doesn't then you can throw out the node by moving it into another folder or delete it. On the other hand I would have to keep another list around that contains basically the same information as the AllowCompilation flag.
-
@Christoph-Hart The problem is if you have a lot of networks you don't always know which one(s) is causing the issue, so you have to remove all the xmls from the project and add them back one at a time between each compile until you figure it out - or maybe there's a better way I don't know about.
-
@Christoph-Hart in which commit? I'm one behind current.
I've just gone through the motions of compiling the network list one by one and it's finally built them all. Let me see if I can recreate the error, but in Xcode there were 'too many'. In general there was a lot of
pma node needs extra arguments
style errors -
The problem is if you have a lot of networks you don't always know which one(s) is causing the issue,
That's what the compiler error messages are there for. If they don't show up in the export dialog (which happens on macOS under some circumstances), you can always open the Xcode project and compile it there, then it should give you the error message.
Let me see if I can recreate the error
Yes let me know if you can pinpoint this, I'll rather add another safe check that will popup during the compilation process.
-
@Christoph-Hart said in Compiling C++ nodes and Scriptnode Networks:
That's what the compiler error messages are there for. If they don't show up in the export dialog (which happens on macOS under some circumstances), you can always open the Xcode project and compile it there, then it should give you the error message.
Ok, that is what happens to me, I have not tried the Xcode way, thank you for the tip
-
@Christoph-Hart ok so the new commit brought the errors back! yay
This has been consistently the errors that I've been having for months now when compiling. The fix has always been to remove networks from compiling and do the nodes, followed by networks one by one. Even that hasn't been fully reliable and I've had to clear the networks agin...
-
@DanH can you send over the
DspNetworks
folder (without the Binaries subfolder, don't need that trash) then I'll take a look. -
@Christoph-Hart thanks, check DMs
-
@DanH alright, there were two corrupted networks, Filter_H3 and MULTIBAND_DISTORTION (they threw an error at the code generation stage so you can easily identify them and move them out of the compilation folder or try to fix the error).
All your C++ nodes are templated like this:
template <int NV> struct SomeClass {};
so they need the
IsPolyphonic
flag to be set. Note that whenever you see a compile error like this:Use of class template 'project::Griffin_Chorus_C' requires template arguments
it's always because the compiler expects a voice count as argument but the C++ code generator didn't treat the node as polyphonic class because the flag wasn't set correctly.
If I enable the IsPolyphonic flag for all C++ nodes, the compilation then fails with some weird error message but that's on me (probably the same issue that @Orvillain ran against in the other post.
So to recap:
- fix / remove FILTER_H3 / MULTIBAND_DISTORTION
- toggle the
IsPolyphonic
flag for all nodes - wait for me to fix the most recent codegen issue - that's unfortunately not too trivial so I need to take a proper look into how to solve that.
-
@Christoph-Hart ok thanks! Are there any clues to the errors in the filter and distortion networks? I rebuilt the distortion one to get through a previous compilation issue. They're both pretty complex networks... But they do compile (after I go through that tedious process), and happily compile on their own.
Edit - Oh I see the errors in the new commit....
-
@Christoph-Hart update:
Those networks may have thrown errors due to faust? At least that was the issue here.
-
@Christoph-Hart I get a DLL compilation fail caused by a colon added after
Gain:
<--namespace MainDSP_network_impl { // ==============================| Node & Parameter type declarations |============================== using MACRO1_global_mod1_t_index = runtime_target::indexers::fix_hash<1>; using MACRO1_global_mod1_t_config = modulation::config::constant<false, modulation::TargetMode::Gain:>; // <--
So when I remove it I can compile in XCode
I'm on the last commit -
@ustk ah yes, that was indeed a typo in the code generator, I guess I haven't tested all the configurations...
Should be fixed now.
-
@Christoph-Hart Nice thanks!