@d-healey That's the vid that got me started on broadcasters, and I'm very appreciative of it! So thanks!

@Christoph-Hart Nice, going to give this a try now.

@clevername27 said in [feature request] Stop specific broadcasters firing at on init:
It's also not always possible to tell if a broadcaster is being called at startup…which doesn't sound right, but there are edge-cases.

Can you make an example?

@Christoph-Hart said in Button default value should be used in broadcaster:

It's used for AAX plugins

Aha that's good to know

Haha, I solved the offset issue! Turned out to be a one line fix.

@Christoph-Hart Pull request has been updated, including merging latest develop branch changes.

Peek 2025-03-19 20-56.gif

@Christoph-Hart said in Any limits on the number of broadcasters?:

no limit except for your imagination

That's a dangerous assumption... Dave's imagination is unlimited... Be warned...

@aaronventure I would expect it to work in the same way as component value broadcasters and component control callbacks. - I've never tested which triggers first. I think after the callback would make the most sense.

Edit: I just did the test with the value broadcaster and it fires before the component control callback, but I think for MIDI messages it makes sense for the callback to fire first - although I haven't given it much thought.

@d-healey Great job, David. Thanks.

That Pull Requests tab looks a bit depressing, though - lots of good stuff there.

Yeah that solved it, woohoo!

@oskarsh ah yeah, that's the fourth option :)

You can add a simple low pass filter on the scripting layer to the values if you want to smooth fast changes.

Am I being silly or is the favourite button state obj.buttonState inverted? Aha! It triggers on mouse up not mouse down :)