@griffinboy This was it! For some reason I never even noticed the drop down on the wet/dry gain! Thanks as always :)

@obolig usually there is not too much overhead of running inside HISE, except for the debugging tools that might cause some UI lags - the audio rendering path is almost identical between HISE and the compiled plugin - unless you do something weird.

@Christoph-Hart Haha that's not at all what that requirement says.

The requirement says that if I input MIDI or audio into HISE and it spits something out, then pressing export should result in that same plugin.

Faust nodes need the compilation step before they can work? Alright ,throw a warning and tell me to enable Allow Compilation. If I didn't ask again on export. But then it should compile to a plugin that works. Because it works in the HISE IDE.

I can, in HISE, have a single .dsp file that I use in 10 different networks at 30 different places in Fasut nodes and it'll work in the IDE. I can make changes and it'll work. But just pressing export wont.

So what, I should now first compile that faust dsp file in a lone network that exists just for compiling lone faust files, replace all existing faust nodes that are used for development because I cannot just branch, as the nodes cannot be in there when exporting, connect all the cables for 30 instances across 10 networks and then compile? And then when I have to make a change, what then? Git discard all the changes to the networks, make changes, and then replace and reconnect 30 nodes again just to run pluginval?

Come on, man 😄

@xander my guess is your faust code works with a fix expected samplerate so that when you‘re oversampling it shifts the normalised frequency ratio.

@Christoph-Hart said in Scriptnode Synth Crackling with Chords:

What might be possible at some point is to use the routing.send / routing.receive nodes WITHIN a polyphonic network to implement polyphonic feedback delay lines (for stuff like resonators etc).

yes, exactly.

At least for me this was the expected behavior. I kept flipping on and off the polyphonic setting for the chain, expecting that to be a fix, or the number of channels, but nothing solved it.

For the time being I will try out using Faust for my comb filter / physical modeling elements and see what I can do.

@dane-zone click the little dropdown in the node title to expose the parameter of the dynamic blocksize so you can change it.

The CPU meter in HISE is not the final thing. Depending on the complexity of the network, it may go down, sometimes a lot, when you export it. So export it and check against other plugins in your DAW. That's your reference.

If there are no audible artifacts at lower modulation values, you could leverage the dynamic blocksize node to go for frame processing only past certain modulation thresholds, optimizing the plugin when low modulation values are used.

There's gonna be a "hiccup" when you switch blocksizes, so keep it in mind if you want to offer parameter automation of the modulation frequency. You may wanna leave an option for this in the settings but before you go trough the engineering trouble to offer this feature, export the plugin and check whether using frame processing for this is actually even expensive by comparing it to the performance of similar plugins on the market.

@Orvillain Right no... I get it. Use two cables. Dohhh.

@HISEnberg It's really nice of you.

@jeffd
ok i figured it out, for some reason my send effect wasnt connected to my send container.
no idea how that happened.

but works again

@d-healey

Interesting.
Okay I've never done this before I didn't know set attribute could be used that way.
I'll have a go

@ustk

yes! its in the project xml

<Processor Type="SynthChain" ID="Griffin_WT" Bypassed="0" Gain="1.0" Balance="0.0" VoiceLimit="16.0" KillFadeTime="20.0" IconColour="0" packageName="" BuildVersion="650">

I'm back after ripping apart my project and putting it back together. The "Mother-Network" that was originally structured in the exported scriptnode has now been recreated in the Module Tree.

20bd4638-8a11-4e64-8deb-c5449c9db2cb-image.png

The minimal module tree from before will be missed. RIP

I have a few important notes. You need to use Synth.getSlotFX() not Synth.getEffect() when making a reference to the HMFX processor when using the setEffect command. This allows you to load in the exported scriptnode to the module.

Other notable functions are exportState() and restoreState(). These can be used to copy/paste control states of the processors after they move. Use the Synth.getEffect() for this one. The exported string even stores the loaded effect. This means you can simply use this command instead of having to load the effect and then the parameter settings. Both processes are accomplished by this single command.

I still need to set up a system for all the UI controls to adapt their connections depending the updated locations for each module. That should be fun.

@deadlycopter actually thinking about it a bit, if all you are looking to get out of the compressor code is some current "compressed" value based upon some input signal then the Faust compressors offer you dB values as output, e.g.

Link Preview Image compressors - Faust Libraries

favicon

(faustlibraries.grame.fr)

now normally we just apply this dB value to the signal level to get a classic compressor - but there's nothing stopping you using it in some saturation component in Faust... you just need to convert the dB output values to something you can use in your saturation code

@Chazrox

No worries, the question wasn't asked in a clear way.

@hyperphonias
This is actually quite a complex thing you are asking. A compressors parts don't really exist in isolation. You can't really create one part of the design without thinking about the rest of the design. For example some attack release algorithms support variable width knees, others do not (or in the least will give you a much harder time). So if you don't pick the right algorithm off the bat, you may end up ruining your design. So you must consider the whole compressor at once when making a design.

I don't think I'll be able to help you with this one, I'm short on time these days. Maybe someone here can point you in the right direction if they have already made a scriptnode compressor!

Else, take a read of this:

https://www.eecs.qmul.ac.uk/~josh/documents/2012/GiannoulisMassbergReiss-dynamicrangecompression-JAES2012.pdf

After reading this a few times you will understand digital compressors. And that's not a bad thing, if you're wanting to build one...