HISE Logo Forum
    • Categories
    • Register
    • Login

    [feature request] Stop specific broadcasters firing at on init

    Scheduled Pinned Locked Moved Feature Requests
    broadcasterautomaticinitdeclaration
    14 Posts 4 Posters 203 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • clevername27C
      clevername27 @Christoph Hart
      last edited by 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.

      1 Reply Last reply Reply Quote 0
      • d.healeyD
        d.healey @Christoph Hart
        last edited by

        @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?

        Libre Wave - Freedom respecting instruments and effects
        My Patreon - HISE tutorials
        YouTube Channel - Public HISE tutorials

        Christoph HartC 1 Reply Last reply Reply Quote 1
        • Christoph HartC
          Christoph Hart @d.healey
          last edited by

          @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.healeyD 1 Reply Last reply Reply Quote 2
          • d.healeyD
            d.healey @Christoph Hart
            last edited by d.healey

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

            Libre Wave - Freedom respecting instruments and effects
            My Patreon - HISE tutorials
            YouTube Channel - Public HISE tutorials

            Christoph HartC 1 Reply Last reply Reply Quote 1
            • Christoph HartC
              Christoph Hart @d.healey
              last edited by

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

              1 Reply Last reply Reply Quote 1
              • O
                Orvillain
                last edited by

                Why not just set a global boolean - BC_READY = False - and then have all listeners have a check for True before they're allowed to process?

                I think Christoph's solution is probably okay. Just curious why this is a big deal really ?

                d.healeyD clevername27C 2 Replies Last reply Reply Quote 1
                • d.healeyD
                  d.healey @Orvillain
                  last edited by

                  @Orvillain Yes a flag solution is the current workaround, but nobody likes flags. You end up with a list of variables whose only purpose is to be gatekeepers. The bypass feature is a much cleaner and self contained solution.

                  Libre Wave - Freedom respecting instruments and effects
                  My Patreon - HISE tutorials
                  YouTube Channel - Public HISE tutorials

                  Christoph HartC 1 Reply Last reply Reply Quote 2
                  • Christoph HartC
                    Christoph Hart @d.healey
                    last edited by

                    Alright, done. I added a new parameter to the .bypass() statement so this is the working example now:

                    const var bc = Engine.createBroadcaster({
                      "id": "bc",
                      "args": ["component", "value"],
                      "tags": []
                    });
                    
                    {
                        .bypass(bc, false); // a scoped statement that will temporarily bypass the broadcaster.
                         bc.attachToComponentValue("Button1", "");
                    
                         bc.addListener(0, "print", function(component, value){
                    	Console.print(value);
                         });
                    }
                    
                    clevername27C d.healeyD 2 Replies Last reply Reply Quote 2
                    • clevername27C
                      clevername27 @Christoph Hart
                      last edited by clevername27

                      @Christoph-Hart Have my babies.

                      1 Reply Last reply Reply Quote 0
                      • clevername27C
                        clevername27 @Orvillain
                        last edited by

                        @Orvillain 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.

                        1 Reply Last reply Reply Quote 0
                        • d.healeyD
                          d.healey @Christoph Hart
                          last edited by

                          @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?

                          Libre Wave - Freedom respecting instruments and effects
                          My Patreon - HISE tutorials
                          YouTube Channel - Public HISE tutorials

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post

                          24

                          Online

                          1.7k

                          Users

                          11.8k

                          Topics

                          102.5k

                          Posts