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?

It seems this issue is still here.

I have a situation where a customer apparently needs to re-activate the license each time he wants to use the plugins.

I have very sparse information, but this is probably due to a changing MachineID after a restart. I have told the customer to verify if the current ID matches the one in the currently activated license to confirm the theory. Hopefully I'll get this crucial information.

In the waiting, is there anything I could do aside of just using JUCE_USE_BETTER_MACHINE_IDS?

@Oli-Ullmann Arfffff.... Don't bother... the temperature here is just melting my brain...
I used TH.InternalOnly instead of TH.ExternalOnly, my eyes reading one thing and my brain another... It's my brain that is not in sync...

What is the process for making an LFO module to retrigger with the TransportHandler transportChange callback?
And should I use the callback in the first place?

Context:
I always want the LFO synced to the DAW (phase and BPM)

Here's what I have so far, nothing fancy...

const var TH = Engine.createTransportHandler();

TH.setSyncMode(TH.InternalOnly); // <- stupid me, needed External...
TH.setLinkBpmToSyncMode(true);

//! Transport
TH.setOnTransportChange(SyncNotification, transportChanged);
inline function transportChanged(isPlaying)
{
	
}

//! Beat
TH.setOnBeatChange(SyncNotification, beatChanged);
inline function beatChanged(beat, isNew)
{
	// Sync here???
}

//! Tempo
TH.setOnTempoChange(SyncNotification, tempoChanged);
inline function tempoChanged(BPM)
{
	
}

When the time comes for @Christoph-Hart to merge/manage the current pile of PRs, we'll not see him until his beard touches the ground... Let's hope he has a strong pilosity! (and a good stock of "Hopfenkaltschale" )

@dannytaurus Nice one

@smm-panel Honesty strikes spams again...

@dannytaurus Hmmm... the question is difficult because it really depends on what you do and how you do it.

For my use case I only needed to make this PR:
https://github.com/christophhart/HISE/pull/965

But seeing @DanH's PRs, you might hit some walls before bending it to your wishes...
https://github.com/christophhart/HISE/pulls/DHPLUGS

@David-Healey You can ask Claude to analyse your previous project styles once for all so it automatically applies it next time