@Christoph-Hart Thought this was fixed, but apparently not

@Christoph-Hart Amaaaaazing! Thanks Chris

@Yinxi Test and report

@Christoph-Hart Side question. In a modulation context with that many branches (64 in total). Are all the branches modulated no matter if they are active or just the selected one is modulated behind the scene to save CPU? Because I only have one activated at a time so it would be crazy to route 64 modulations at the same time

@Christoph-Hart Ok so the issue is not the fact that they have the same name.
After renaming SubGroup from 1 to 8, XCode is still complaining from Redefinition of 'SubGroup1_p' up to SubGroup8.

Effectively, those parameters get copied twice in the header

This might only be related to how branch nodes get compiled, I don't know... I verified the ID of the branches and that the network only has one set of those parameters. Cleared the build folder, deleted the network header that contains the redundancy, etc...

Only moving my parameters externally to the branches works as expected:

@Christoph-Hart Not a big deal to be honest once you know what the problem is, but still it'd be useful have it fixed
The biggest problem is Hise not spitting enough info when failing to compile, so we always have to resort on xcode to get more details...

@DanH The problem with the bias is that it's a user parameter, not a perfect arithmetically computed offset value. But this would only be possible in a third party node context...

Compilation fails in Hise (with as often, no information on the issue) and XCode complains for Redefinition of 'SubGroup1_p', etc...
I can rename them of course... I understand the issue within the same parent, but with different nodes...

@DanH If you are sure the cause is the shaper, could it be because of an offset issue with a signal = 0.0 ?
Because if you have an offset blocker behind, the filter takes time to settle because of its group delay. In such a case it'd be better to compensate for the offset right after the shaper

a buffer can be sent via cable data or external data (and maybe received by cable data only, as I don't know if an external data is bidirectional).
This might allow offline processing

@tomekslesicki If CoreAudio has started (and seems to be the cause of a bad memory writing here), maybe it is simply possible to call this in order to disable audio entirely...

Settings.setAudioDeviceType("");

Not tested but if it works we shall all do the same in our apps!

@Christoph-Hart Bumpy bump

@HISEnberg said in Third party node modulation output slot:

@ustk nice I basically setup the same system but just using HISE’s version of get/setLatencyInSamples. I’m assuming you are using the JUCE version of this in the C++ node? I believe HISEs API is exactly the same but I could be wrong.

Well my use case is different, I just compute my inner DSP latency for dry/mix situation in a split node, not reporting the whole latency of my project to the DAW...

Regarding what @Christoph-Hart and @griffinboy are saying, could oversampling help here?
Despite the fact it'll eat up some more CPU, of course...

@HISEnberg Yeah this is exactly what I am doing, sending my node's latency to the dry signal through a SampleToMs converter connected to a delay.
My DSP throws out the latency in round samples so I don't know about the fractional delay since I just directly convert it to ms.

In your case, you might be able to deal with the fractional delay if you directly send it in ms to a Juce delay like lagrange or thiran. They are meant to deal with fractional delay unless I'm wrong...

@HISEnberg Yeah perfect that is what I did, just the mod output...
But you did well teaching me with the display buffer as well because I will soon need it!
Thanks a lot!

@Christoph-Hart Yeah I ended up trying just that end it worked at first try! Amaaaazing guys

@HISEnberg Oh mate I think this is exactly what I need! I didn't see the isModNode existence, shame on me...

So this is necessarily paired with the display buffer?
Not a huge deal but it'd less ugly if I only have the cable connector since the value I'm sending is a latency compensation of my DSP to surrounding nodes...

Yeah so I'm pretty sure this has been discussed already but I can't find the thread, so pardon me if it is the case...

Is it possible to create an output mod slot in a C++ node?
or is the only solution to use a global cable?

@ps any news on implementing this library? I'm failing with all the includes and when I finally get them working I'm hitting the C++20 incompatibility issue.
So I started modifying it to use C++17 but here I'm definitely failing. And it seems to many things to modify anyway, doesn't smell good...
So if someone has a more straight solution I'd take it!

Also, I'm into the signalsmith stretch, but I can't figure how to make that formants compensation to work... Is anybody having an idea?

@Christoph-Hart said in Why isn't this set parameter for a DSPNetwork node working?:

You can of course use a high-level interpreted network where you load in your compiled networks if you want to keep dynamic access to properties / parameters.

oh yeah, haven't though about that