@Christoph-Hart Nice one! It seems to work but I can't fully confirm at the moment because something in my network makes a hard crash as soon it loads in a HCFX...
But it is definitely not the C++ node and compiling it with a fresh network removes the global cable not found warning

@Christoph-Hart so why not with a bool recursive if you make a new one? so it can do both until we can safely retire the old one in a few years...

@Christoph-Hart Yes exactly this, it doesn't survive. i tested with an empty network too (just my C++ node)

@Jeetender That is strange. Didn't you see the latency reported in the DAW?

Removing the module that causes latency is not a viable solution. Once you know the latency of your plugin, you should just be able to report it to the DAW with this method.

So it's not an "in plugin compensation" but telling the DAW "hey, I introduce this amount of latency, please compensate for me" (in which "this amount" is your job to determine)

@Christoph-Hart said in Global Cables Don't Work when compiled:

in the outermost network that you compile?

Sorry but I don't understand. My C++ nodes are in the middle of the graph.
Do you mean in the root container?
I tested anyway and same thing, the hardcoded FX rejects it.

@Christoph-Hart And aside of this we still have some nodes like cable_expr that are requiring the network to be compiled for the plugin to export.

I could transform it into a C++ node with another global_cable, but since it prevents the network to be compilable...

This causes quite annoying frictions

@David-Healey or perhaps adding an optional parameter bool recursive?

@Christoph-Hart said in Global Cables Don't Work when compiled:

you are correct Global Cables DONT work in compiled scriptnode

...

I think the issue that @griffinboy is having is if you load these networks into another scriptnode network (instead of loading the compiled effect into a hardcoded effect), but that's another problem and (potentially exotic edge case which you can easily work around).

I don't understand why it would be "exotic edge case" here, and how you can work around this... Seems rather a normal workflow to me...

I have a compiled node in a network, that is (I think) busy enough to justify a compilation too...
And then my global cables won't work...

What can I do?

Claude said:

Main bus   Sidechain   Host buffer  SC lands at    Internal scratch
mono         mono         2 ch        buf 1        [m0][m0][sc0][sc0]
mono         stereo       3 ch        buf 1–2      [m0][m0][scL][scR]
stereo       mono         3 ch        buf 2        [L][R][sc0][sc0]
stereo       stereo       4 ch        buf 2–3      [L][R][scL][scR]
either	     none          —           —           ch2/3 silent

So a mono-track instance sidechained from a stereo source works fine: the mono main is duplicated across ch0/1 (HISE renders internally in stereo regardless) and only channel 0 is copied back out, while the stereo sidechain keeps its L/R on ch2/3. A mono sidechain gets duplicated. The network always sees one fixed layout — no mode-dependent logic anywhere.

Stereo sidechain detection is genuine, not left-channel-only. envelope_follower::processFrame takes max(abs(s)) across all channels of the frame, so it detects the louder of L/R.

I say:
All good

@dannytaurus said in Mono plugin with side-chain:

@ustk What's your intention behind mono compatibility? Is it for a specific DAW?

Simply for mono tracks like compressing bass for instance where you might need sidechain with the kick

And are you looking for mono sidechain input, or stereo?

In the end I think I just need to "monoize" the sidechain if it's forced stereo with mono plugins. I still have to investigate this, but it's not crucial as long as a mono track goes through the first SC channel... The ideal is to have the possibility to connect either mono or stereo SC no matter if the plugin is inserted on a mono or stereo track.

@HISEnberg Nice! Claude patched Hise for me, I am testing it in the afternoon...
If yours was made a few years ago then it might not account for the existence of HISE_SIDECHAIN_CHANNEL_LAYOUT

@Oli-Ullmann Yes, that's why I've made a patch and hopefully a PR soon.

@David-Healey Well this is new to me so not very clear yet.
But the old trick was to add more channels in the the routing matrix and route them the way you want.

Now on top of this there are extra proc:
HISE_NUM_FX_PLUGIN_CHANNELS=4 which is the normal num channel + the sidechain channels
And
HISE_SIDECHAIN_CHANNEL_LAYOUT=1 which I didn't know about until tonight...

I'll try tomorrow to actually export a test plugin and see how it goes...

This seems to be exclusive, so one or the other from what Claude reports.

But I definitely need to use my plugin on mono tracks, and the whole purpose of the plugin is to have a side chain in the first place. So I can't live without the two.

So is there a solution to this before I start patching Hise?

@lalalandsynth just a thought, have you tried and confirmed those issues with bigger font size? Might be a kerning rounding error for small values or something related. Just saying this out of my mind, I have no idea how fonts are working...

@Christoph-Hart said in BLUR.:

@ustk the fillPath thing on the profiler isn't the time it takes to encode and decode the path to base64 then do all the overhead in C++ in the CSS engine (that's probably all tucked away under the paintRoutine graph, that's just the function passing on the path data to the GPU which is just a memcpy operation and should be very fast.

You're right it resides in the paint routine call so it doesn't represent the total build+paint time. Still it improved the construction time anyway compared to what I had before and we see the shadow is still the greedy boy.

but drawDropShadowFromPath isn't using melatonin yet, no?

yes it does:

void ScriptingObjects::GraphicsObject::drawDropShadowFromPath(var path, var area, var colour, int radius, var offset)
{
	auto r = getRectangleFromVar(area);
	auto o = getPointFromVar(offset).toInt();
	auto c = ScriptingApi::Content::Helpers::getCleanedObjectColour(colour);

	if (auto p = dynamic_cast<ScriptingObjects::PathObject*>(path.getObject()))
	{
		Path sp = p->getPath();
		drawActionHandler.addDrawAction(new ScriptedDrawActions::drawDropShadowFromPath<melatonin::DropShadow>(sp, r, c, radius, o));
	}
}

drawDropShadow (rectangle version) doesn't use melatonin but JUCE's own juce::DropShadow

@lalalandsynth You can see the % button everywhere in Hise allowing you to profile the UI, DSP, Module tree, etc...

There is also the main profiler tab with many option:

@Christoph-Hart And when zooming the interface or making the knob bigger, the difference becomes even more dramatic:

@Christoph-Hart In fact now I improve this part by pre-computing the path and use it like a filmstrip (better for the paint routine but still not usable for CSS).
The result as you can see is that the main perf issue is still by far the dropShadow (which becomes a real deal for 20+ knobs):

@Christoph-Hart Funny, I've been working on this greedy blur since yesterday too.

Claude says the main performance cost comes from allocating a new Melatonin object on every call. That means there's effectively no caching, making it quite expensive when repainting continuously at the frame rate. Is that something that could be improved?

In my case, the path needs to be reconstructed depending on the knob angle, so I can't keep a permanent path, which means I can't use CSS. Or is there a way around that?

@dannytaurus Thanks, yes it might be... But what makes you think it's going to be worse?