preventing script from running at panel load

Home Forums General Programming preventing script from running at panel load

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #10021
    msepsis
    Participant
      • Topics: 219
      • Replies: 732
      • Total: 951
      • ★★★

      I’m not having this issue when i open the panel as a bpanelz within ctrlr but the moment I launch the resulting constricted instance (standalone app or exe) I’m prompted to load and save a program file. These dialogs should not come up unless you actually press the “save” or “load” buttons where the scripts to do the work are attached.

      here are links to my code, I really need to stop these scripts from running on launch as it’s preventing me from… well.. launching the panel. . .

      http://pastebin.com/R1MFynC5
      http://pastebin.com/YJGnFa9u

      I have the buttons these scripts are attached to ticked to “mute” and “don’t send” under Modulator does not output any MIDI and Don’t send this modulator during snapshots.. don’t see any other even somewhat related attributes that would tell these scripts only to run when the button is pressed.. very strange that these are being triggered on panel load, why aren’t any of my other button’s scripts being triggered on panel load??

      help please 🙂

      Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

      #10026
      atom
      Keymaster
        • Topics: 159
        • Replies: 2945
        • Total: 3104
        • ★★★★★

        None of those options is designed for that. The check on top of the method (bootstrap check) should do the trick, but i noticed it doesn’t.

        I might add a special explicit option for all components to be ‘silent’ on load. I’ll do that tomorrow, there is a bug in Juce i just reported and am awaiting a fix, once that’s done i’ll post a nightly build.

        I hope to address the MIDI/Lua issues you guys reported.

        #10027
        Hecticcc
        Participant
          • Topics: 25
          • Replies: 160
          • Total: 185
          • ★★

          I encountered the same kind of problem and got around it by using a variable that is created in the “called when panel has finished loading” script, and reference that in an if statement enclosing the “rogue” method’s content.
          I use a bool set to true for it, but i guess you can use anything you want since its just a variable that has to exist.

          #10028
          atom
          Keymaster
            • Topics: 159
            • Replies: 2945
            • Total: 3104
            • ★★★★★

            Yes that’s one of the ways to get around the problem. I remember that i added that special call to fix this issue.

            #10035
            msepsis
            Participant
              • Topics: 219
              • Replies: 732
              • Total: 951
              • ★★★

              !!! Thank YOU!!
              soo appreciative of the quick help. That fixed the issue. Finally the rocket panel can be released!

              Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

              #10036
              Hecticcc
              Participant
                • Topics: 25
                • Replies: 160
                • Total: 185
                • ★★

                Rock on!

                I’m gonna be glad when i can release v2 of the emu panel too, and after that imme do something simpler than a sampler – something with fixed amounts of …eeerrr… everything 🙂

                #11874
                msepsis
                Participant
                  • Topics: 219
                  • Replies: 732
                  • Total: 951
                  • ★★★

                  I’ve had some issues with this re-occuring even when implementing the suggested steps above. Atom you mention some things you’re working on to address this, is there anything new that might help me resolve the issue? I essentially want to prevent the modulator’s attached methods from running when the panel is first loaded.

                  IMO this should be a default – don’t run modulator’s methods unless the human says to! In other words i dont want modulators to trigger attached methods unless a human user twiddles the knob/slider or presses the button. I don’t want the scripts running when the panel first opens, only when the modulator’s value is changed by user interaction.

                  A similar topic: I find myself often a position where I need to somehow determine the difference between a modulator’s value being changed due to direct human interaction, or the modulator’s value being changed by a Lua script. This has been discussed for a long time here but I still think there is a great case to be made for putting in a toggle in modulator’s edit pane (window on far right when in edit mode) that disables attached methods from being run if the modulator value is changed by a script – NOT human interaction.

                  Hoping this makes sense, it would be quite nice to have this stuff handled by ctrlr instead of having to write awkward scripts with additional moving parts to have to keep track of.

                  Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

                  #11993
                  atom
                  Keymaster
                    • Topics: 159
                    • Replies: 2945
                    • Total: 3104
                    • ★★★★★

                    I can’t really disable calling the Lua script on load.

                    Any develope will tell you, that this event needs to happen to get a consistent state of the program, what needs to be added is an indicator that we are loading now. And there are now 2 indicator available in the panel: object,

                    1) getRestoreState()
                    this tells you is the panel is beeing restored, that is it has just been created in memory, it’s properties are beeing changed etc.

                    2) getProgramState()
                    this tells you that the panel is getting a new program. this is important because when Ctrlr launches a new program is always applied (the one that holds the default values). This is different from getRestoreState() because this will be called everytime a program is applied.

                    You need to know as the developer that getRestoreState() will return FALSE during start at the moment of applying the first program. Based on those 2 indicators you need to make decisions in your Lua scripts.

                    #12232
                    msepsis
                    Participant
                      • Topics: 219
                      • Replies: 732
                      • Total: 951
                      • ★★★

                      I had done something stupid and instead of following hectic’s suggested method I did a slight alteration of it which of course didn’t work in this scenario. Fixed it and the issue is resolved.

                      Thanks atom for the further insight. I guess I wasn’t clear that those two indicators were fully functional and working right. I think I had misunderstood info on these from another thread where you said something about not the fault of a bug but just the way some things were implemented. I had then dismissed those indicators you had mentioned then which you had just added apparently.

                      So if I understand correctly I would just use them like:`if panel:getRestoreState() ~= false then –the panel is NOT loading
                      –do some stuff
                      endif panel: getProgramState() ~= false then –the panel is NOT receiving a program dump
                      –do some stuff
                      end`

                      • This reply was modified 10 years, 7 months ago by msepsis.

                      Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

                    Viewing 9 posts - 1 through 9 (of 9 total)
                    • The forum ‘Programming’ is closed to new topics and replies.
                    There is currently 0 users and 71 guests online
                    No users are currently active
                    Forum Statistics
                    Threads: 2,495, Posts: 17,374, Members: 77,605
                    Most users ever online was 12 on January 22, 2019 3:47 pm
                    Ctrlr