[feature request] Stop specific broadcasters firing at on init

[d.healey]

I'm with Bill. The more I use broadcasters the more I'm finding situations where I don't want them to fire until the user does something that triggers them.

Could we get an option to prevent specific broadcasters from firing at declaration?

[Christoph Hart]

@d-healey yeah why not. I noticed that the setBypassed() method doesn't have an impact on the initial callback firing, so that would be my preferred fix (as you would kind of expect it to do so anyway):

const var bc = Engine.createBroadcaster({
  "id": "bc",
  "args": ["component", "value"],
  "tags": []
});

// This will deactivate the actual callbacks on value change
// but leave the init call through, which is not ideal...
bc.setBypassed(true, false, SyncNotification);

bc.attachToComponentValue("Button1", "");

bc.addListener(0, "print", function(component, value){
	Console.print(value);
});

[clevername27]

This post is deleted!

[clevername27]

@Christoph-Hart @d-healey Isn't that the opposite of what we're looking for — deactivate on init, but activate on value-change? (Forgive me if I'm being dense.)

FWIW - I ended up writing my own broadcaster system for HISE, with separate messages for init, samplemap-loaded, power-off to module, power-on to module, start ui, stop ui, expose ui, hide ui, enable DSP, bypass DSP, and so on. Messages are automatically propagated to submodules (as the system is hierarchical). Modules are created in a Factory, with "public" and "private" methods (and faux- constructors) so most of the broadcaster code is only exists in one place. Modules are also independent, so you can pull any of them out, and the plugin keeps chugging along. It's finely granulated, with something like 50+ in the plugin, which means communication isn't exactly instant, but my plugins are written entirely (except for MIDI handling, and ScriptNode) in the UI thread, so given how nicely @Christoph-Hart handles scheduling priority for real-time audio and MIDI, the whole thing works. Kinda.

[d.healey]

@Christoph-Hart said in [feature request] Stop specific broadcasters firing at on init:

yeah why not. I noticed that the setBypassed() method doesn't have an impact on the initial callback firing, so that would be my preferred fix

Would I need to manually unbypass it when I want it to fire?

[Christoph Hart]

@d-healey yes but you could just reactivate it after the listener has been added. There's also a way of doing this with a scoped statement, but the current implementation will send a listener call when it goes out of scope.

The syntax then would be:

const var bc = Engine.createBroadcaster({
  "id": "bc",
  "args": ["component", "value"],
  "tags": []
});

{
    .bypass(bc); // a scoped statement that will temporarily bypass the broadcaster.
     bc.attachToComponentValue("Button1", "");

     bc.addListener(0, "print", function(component, value){
	Console.print(value);
     });
}

[d.healey]

@Christoph-Hart Aha clever - so it's just a matter of fixing the bug in the current behaviour?

[Christoph Hart]

@d-healey this and adding a parameter to the bypass statement that controls whether the messages are sent when it goes out of scope.