@Christoph-Hart could you tell me more about the skew factor applied to the gain of the group xfades?

@Christoph-Hart ha you know what I meant.

thanks 🍻

@aaronventure I've added the gin stack blur at some point (it's already using this algorithm in the Graphics functions), however it's still ridiculously slow because it has to do graphics operations on a CPU and this is 1970 style hardware usage.

https://forum.juce.com/t/faster-blur-glassmorphism-ui/43086/7

I've went through the thread a few months ago and was close to port it over into HISE (I also sometimes get the urge of making blurry stuff), but I wasn't too convinced that the overhead justifies the performance gain (it's still being calculated on the CPU and this makes it easily a factor 100 slowdown compared to GPU based blur algorithms).

EDIT: this is the module I was talking about:

Link Preview Image GitHub - sudara/melatonin_blur: Fast cross-platform CPU blurs and shadows for JUCE

Fast cross-platform CPU blurs and shadows for JUCE - sudara/melatonin_blur

favicon

GitHub (github.com)

From revisiting the page, it might be actually worth it trying out how it performs...

@d-healey just what i needed thanks

@Lumi283 that double semi colon at the end probably isnt helping much either...

@Christoph-Hart I think I found the reason it didn't update.
I had 6 slider packs in a separate ScriptProcessor, all of them registered with

SLP1.registerAtParent(0); SLP2.registerAtParent(1); etc...

In the main script I have 6 slider packs connected to the separate script processors slider packs using this connection:

const Data1= Engine.createAndRegisterSliderPackData(0); const Data2 = Engine.createAndRegisterSliderPackData(1); etc... slp1.referToData(Data1); slp2.referToData(Data2); etc...

I chosed that type of connection because I needed a DisplayCallback for each one of those slider packs, I couldn't find any other way to get that type of callback, is there?

Any way, in the external script processor I changed the

SLP1.registerAtParent(0); to use the SLP1.referToData(Data1); method instead, and that fixed my problem.

What kind of connection is preferred if you can't connect them via the Property Editor?

@d-healey ahh Thanks!

@trillbilly Write it out as a list, in English.

Do this,
Then do this,
If this, do this,
Otherwise do this
etc.
etc.

It might make it easier to figure out the flow of the program.

Yup a container is a sound generator.

yes, at some point the overhead of implementing a "don't show again" system might be worth it, in the meantime, I've "solved" the problem in the most laziest way possible:

ac8c9a1c-d65a-44b6-a360-695c3354c46f-image.png

However I also realized that the Undo button can fix most of the errors that you can do with the JSON editor so it's not as bad as I thought the entire time...

@d-healey Using the txt property seems like a nice idea.
The video was also helpful. Thx!

@d-healey yup, that was it! Thanks so much!

@d-healey said in MIDI Routing - Floating Tile Keyboard Retrigering (strategy help):

Message.ignoreEvent(true);

This works perfectly! Thank you @d-healey

@d-healey Thanks!

@Casmat Thank you, I'll try that and post the result.

@paper_lung said in Animate panel via MIDI?:

Hi all, does anyone know how to animate a paint routine via MIDI? I want to display an animated panel which shows when notes are triggered in the MIDI processor for one of my modules in the module tree. I've got a few working with LFO's using getCurrentLevel, but unsure if this is possible with MIDI?

set up your panel to repaint based on some variable, set the variable in the note on...

@iamlamprey I think with release triggers it will just work like a one shot sample.

@Christoph-Hart After doing a bunch of testing, I've found that the magic number appears to be 48.
When I do the math:

auto numSamples = (double)getMainController()->getOriginalBufferSize(); auto sampleRate = (double)getMainController()->getOriginalSamplerate(); auto blockLengthSeconds = numSamples / sampleRate; auto deltaForBypassDetection = roundToInt(1000.0 * 48.0 * blockLengthSeconds); buffer = 64 sample rate = 48000 1000 * 48 * blockLengthSeconds = 64

Is it a coincidence that the magic number is equal to the buffer size of my audio card or that the value is a multiple of my sample rate?

Now the part that is driving me crazy....
Even with the increased sampling time, I can get the transport handler to trigger false positives when I move an item on my screen. Check out the console:

false positive.gif

It appears to not only be affected by the buffer, but also the way getApproximateMillisecondCounter is being calculated.