Compiling C++ nodes and Scriptnode Networks

[Christoph Hart]

@HISEnberg how are you compiling the nodes? I thought I had added a safe check that complains when it can't find these properties, so we shouldn't have this conversation at all :)

[HISEnberg]

@Christoph-Hart I'm doing it from within HISE. I generally have polyphony disabled in my nodes (almost none of them require it), so I'll typically follow the safety check (untick the polyphony settings for the nodes). Sometimes I go into the nodes_properties.json and edit this manually, but my main issue was trying to compile scriptnode networks simultaneously with C++.

I'll test this on a larger project with more nodes but it sounds like if I delete the Binaries folder, and have the proper polyphony settings checked, then I won't have any issues!

[Christoph Hart]

I generally have polyphony disabled in my nodes

That is irrelevant, if your C++ nodes are defined like this:

namespace project {

template <int NV> struct Moog_Filter : public data::base
{

};
}

then the node_properties.json file must define the IsPolyphonic flag, otherwise the compilation will fail because the compiler expects a non-templated class, even if you don't care about polyphony at all.

Now if you want them to be polyphonic, you will have to define the additional flag AllowPolyphonic, then HISE will instantiate a monophonic node MoogFilter<1> and a polyphonic node MoogFilter<NUM_POLYPHONIC_VOICES> for you.

The new export dialog should include a sanity check if the node_properties.json file doesn't contain the properties for each C++ node so I'm just trying to figure out what went wrong here so that you ran into the problem.

[HISEnberg]

@Christoph-Hart I do recall these warnings popping up, but this is currently what the compilation process will look like for me (both Windows and Mac). It "compiles fine" no warnings or errors.

I.e. the compiler doesn't seem to care about the IsPolyphonic flag.

node_properties.json:

{
  "mynewnode": []
}

C++ file:

#pragma once
#include <JuceHeader.h>

namespace project
{
using namespace juce;
using namespace hise;
using namespace scriptnode;

template <int NV> struct mynewnode: public data::base
{
	SNEX_NODE(mynewnode);
	
	struct MetadataClass
	{
		SN_NODE_ID("mynewnode");
	};
	
	// set to true if you want this node to have a modulation dragger
	static constexpr bool isModNode() { return false; };
	static constexpr bool isPolyphonic() { return NV > 1; };

// etc....

[Christoph Hart]

@HISEnberg untoggling the isPolyphonic flag is shooting yourself in the foot here. Why?

[HISEnberg]

@Christoph-Hart That was just to show you that there is no warning or that the compiler doesn't fail when toggling the isPolyphonic flag! Just to be clear I don't usually do this, I just uncheck AllowPolyphonic.

Perhaps some misunderstanding on my part about what you were asking. I recall there used to be a warning that would say you need to have this flag checked if you are working from the autogenerated template.

So to be clear I believe you've solved my initial inquiry: Delete the Binaries folder, make sure the flags are set correctly!

[Christoph Hart]

@HISEnberg ah ok. But if you delete the binary folder, and compile the C++ network without the flags being set then it will fail, right?

[HISEnberg]

@Christoph-Hart Wrong this is what I am trying to show. The isPolyphonic flag, in so far as a single C++ node is concerned, doesn't trigger any warnings or build errors (Though I can certainly remember their were warnings not too long ago).

Hopefully this shows the process, I cut-out the compilation waiting time in this gif, but I think this is what you are suggesting.

I create the node, compile it with the flags. I then delete the Binaries folder, disable the flags and compile again.
This should be producing an error, but it isn't:

[Christoph Hart]

@HISEnberg are you referencing the c++ nodes in a compiled network?

[HISEnberg]

@Christoph-Hart No not in this example though I suppose that would bring us back to the original topic!

So if this C++ node is placed in a Scriptnode network and I compile both simultaneously:

Without the isPolyphonic flag: FAILS

With the isPolyphonic flag: SUCCEEDS

So you identified my issue exactly:

1. Delete the Binaries folder
2. Set isPolyphonic to enabled (if it's designed on the template).

I'll give it a go in a project I have where all the C++ nodes I made are using the template and are embedded in their own Scriptnode Networks. I'm pretty sure it is going to work this time.

[Christoph Hart]

@HISEnberg ah ok now that's as expected. I think the irritation here is that if there is already a successfully compiled version of the C++ node that is being loaded into the network when you compile the network, it supersedes the isPolyphonic flag (which makes the compilation succeed despite the flag being wrong but as soon as you clean out the Binaries folder the compilation will fail the next time.

TLDR: just set the isPolyphonic flag correctly (as it's also described in the help popup of the dialog) and then the compilation should succeed in all cases / series of events.

[HISEnberg]

@Christoph-Hart Ya I will admit that was pretty ignorant of me to overlook that, clicking the help popup immediately clarifies what its for. I suppose that the flag being named isPolyphonic made me think I just didn't need it if the effect isn't polyphonic, but I see how it relates to them template of the node (voice count) now!

Thanks for your help by the way I really appreciate that!

[HISEnberg]

@Christoph-Hart seems to work in real world projects I have with some C++ external nodes and Scriptnode Networks. The behaviour isn't consistent, on Windows it's not fully working but I'm chalking that up to something I may have done in one of the C++ nodes.

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.

If I'm being petty you can just ignore this feature request, I see a lot of value in this but I don't want to burden you with unimportant features.

[oskarsh]

@HISEnberg I can second this feature.

Checking which network to compile would be such a time saver

[d.healey]

@HISEnberg I also think it's a good idea, often when debugging issues the problem is just with a single network, but if you have lots of networks you have to keep recompiling to test them and using a check box instead of having to shuffle xml files around would be much nicer.

[ulrik]

@HISEnberg I agree

[DanH]

@Christoph-Hart ok I'm back in compile fail land.... I tried to add in a c++ sampler that compiles fine outside of this project and recompile all my (previously working!) scriptnodes etc...

Fails reliably every time with same errors. Removed c++ samper, same erros (so potentially not that).

Set all to non-polyphonic, deleted binaries folder. At this point I'd go through the networks and remove allow compilation, compile the nodes, then re-allow network compilation one by one (there are a few).

Is there anything else I should be trying?

At least I have a working dll to fall back to... (minus the new bits of course)

[Christoph Hart]

@DanH what's the error?

The old DLL will not load any longer as I've changed the API.

[Christoph Hart]

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.

[d.healey]

@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.