administrators

Most macs have an onboard graphics chip from intel (at least all of my 6 mac systems do). But it‘s possible that there is something going on with ATI cards.

@d-healey said in Licence Example:

Yeah, I just wrote Dan, don't bother about the samples not being GPL - I think we can just assume fair use and as soon as the samples are available somehow to people who want to build the software, it's fine for me.

The skew factor of the chain parameter is still 1.0

I'm afraid this won't help too much because I don't use the JUCE FFT wrapper

However there is a preprocessor macro that directly targets the FFT algorhitm used by the convolution. Try defining AUDIOFFT_FFTW3=1 and check whether it improves the performance. AFAIK the library picks the best available routine, so it should pick FFTW over Ooura or KISS FFT as soon as you compile it with this flag enabled.

EDIT: Just read your last post properly, the AUDIOFFT_FFTW3 flag should do the trick...

@Zorpley said in Changing filmstrip via script:

though I'm getting slight flashbacks to similar control-layering jankyness in Kontakt.

Just wait until I implement a red pixel dot in order to parse fonts...

Ah ok, in that casey you might want to increase the HP frequency (in your patch it's 20Hz which doesn't do anything noticeable).

Then there are other things to watch out:

1. 16x oversampling is way way way overkill for this algorithm. Just because it's there it doesn't mean you should use it. You're not introducing much harmonics with this DSP algorithm.
2. More importantly is the same advice I gave in the other thread: you need to split down the signal into smaller chunks to increase the update rate (and in this case you might even need to use the frame processing block because you want the compressor to be snappy). This will have a real impact on the sound - unlike the 16x oversampling which will just increase the CPU usage by 16. Right now your calling the gain factor update every 512 samples (or whatever your buffer size is). Considering the 16x oversampling, you even update the gain every 8192 samples!
3. Again, connect the compressor directly to the gain, the indirection through the mod chain is unnecessary.
4. Don't use the gain node here. You don't need the smoothing and you don't need the decibel conversion, which are the exact two things that make it different from the plain math.mul node, so please use that one instead as target node for the compressor's side chain signal. Also the gain2 node at the end of your analysis chain should be a math.clear node - all it needs to do is to clear the signal.
5. Now to your original problem: you will need to change the range of the modulation to be inverted (and there's no need for a core.pma module here). Just right click on the compressor and swap the minimum and maximum values at the modulation connection properties. The modulation signal from the compressor module is the ducking amount, so you want this to be subtracted from a fixed value.
6. If you're end up with a frame-processing, it's highly recommended to compile this node network to a C++ node, otherwise the performance will not be comparable to other effects with similar processing. The export is broken in the current version but the good news is that this patch should be 100% compatible with the new version.

Hmm, not sure about this one, the problem is that you are supposed to compile such a graph to a C++ node but then the filter is not accessible anymore because it's part of a opaque algorithm.

What you could do in that case is to setup a dummy filter or EQ as HISE module, bypass it so that it doesn't eat up CPU, and then set the parameters from your script node patch to match the curve. Then connect the filtergtaph to this module.

I'm not sure what you are trying to achieve here. The weird curve might come from the fact that the scale of the gain knob is logarithmically, but I don't understand the intention of this patch.

Also the entire mod_chain node is unnecessary, just drag the compressor directly to the gain.

And the next thing to do is to wrap the split container into another container that splits up the buffers so that the update rate of the compressor is faster. Try a fix32 or fix64 container (the 100% correct solution would be a frame container but the performance overhead does not justify the sound improvement for this use case)

https://docs.hise.audio/scriptnode/list/container/fix8_block.html

You need to wrap the compressor into a chain and a math.clear node after it so that you can't hear the compressor but just the dynamic EQ.