No internet connection
  1. Home
  2. Support

Hi, I just had to upgrade to Big Sur. Everything is working but there are some comands that move the mouse when they run. For example, when using the "System: Set track color" command, once it runs in

By Adam David Smith @AdamDavidSmith
    2021-03-31 18:33:51.542Z

    Hi, I just had to upgrade to Big Sur. Everything is working but there are some comands that move the mouse when they run. For example, when using the "System: Set track color" command, once it runs in moves the mouse to wherever the color palatte is. Before updating the mouse would just stay where it is. This is also happening with some other commands like Tiezzos plugin loader.

    System Information

    SoundFlow 4.2.0

    OS: darwin 20.3.0

    ProductName: macOS
    ProductVersion: 11.2.3
    BuildVersion: 20D91

    Steps to Reproduce

    1. Run the "Set track color" command

    Expected Result

    The mouse should stay at its original position.

    Actual Result

    The mouse jumps to a new position

    Workaround

    no workaround

    Other Notes


    Links

    User UID: sw9r3sd7zWOInFbiTPdiHx4L1AK2

    Feedback Key: sffeedback:sw9r3sd7zWOInFbiTPdiHx4L1AK2:-MX8Z1uoxaTv5RofgliW

    Feedback ZIP

    • 24 replies

    There are 24 replies. Estimated reading time: 11 minutes

    1. Hi Adam,

      Thanks for reporting this. Can you show us a screen recording of this happening?
      Preferably, I'd combine that with reading your log file for that same time to try to understand why this doesn't work for you.

      You may also want to manually update to 4.2.4, although I haven't heard of anybody else seeing this bug, so it's not likely to have been addressed yet.

      https://soundflow.org/cp/downloads

      1. I should also note that we have many users working on Big Sur who haven't seen this issue, so we'll need to understand specifically what makes it work differently in your case.

        Have you installed any 3rd party mouse software / drivers or other keyboard automation software by any chance?

      2. In reply toAdamDavidSmith:
        Adam David Smith @AdamDavidSmith
          2021-04-01 20:45:34.985Z

          Hi Christian, Attached is a video of me running the set track color command and also a Tiezo plugin loader command that both move the mouse. After recording this video I installed 4.2.4 but the issue persists. I was testing out a trackball a few weeks ago while I was still on high Sierra and I installed the Kensington TrackballWorks software but uninstalled that. I just did some searching to see if I could find any remnants of the Kensington software but did not see anything.

          Thanks!
          Adam

          1. Christian Scheuer @chrscheuer2021-04-01 21:33:37.152Z2021-04-01 22:27:50.809Z

            Hi Adam,

            Thanks for the video.

            I think the best bet is probably that Kensington software - but it may also be another software or hardware component interfering. It would appear that SoundFlow's fast mouse messages get blocked from going to macOS the way they're intended. Given that this is not a widely reported issue, the most likely case is something interfering specifically on your system. The best way to find that is probably going to be to try to narrow it down by ruling out potential causes one by one.

            One place you might want to check is /System/Library/Extensions and look for any kext files installed by the Kensington software that may have not been removed again.

            Note that uninstalling kext files can cause your system to stop working, so do anything with caution and make sure to make a full backup of your system before attempting to remove files there.

            1. Note, some kext files get instead installed into /Library/Extensions (not /System/Library/Extensions).

          2. In reply toAdamDavidSmith:
            Adam David Smith @AdamDavidSmith
              2021-04-01 23:23:35.124Z

              I couldn't find any remnant .kext files. I tried reinstalling Kensington works but the issue persisted. I uninstalled again and looked again for any leftover files but did not find anything.

              1. Hmm..

                I think the next troubleshooting step I'd recommend would be to open up your SF account on a different computer to see if it could in any way be related to something in your account. If it works fine on another computer, at least we know it's only on that one installation.

                Beyond these things, if you're certain no other keyboard/mouse controlling software is installed, then I don't have a lot of other ideas.

              2. In reply toAdamDavidSmith:
                Adam David Smith @AdamDavidSmith
                  2021-04-01 23:37:24.686Z

                  Good call, I was planning on upgrading my laptop to Big Sur in the next few day. I don't think that the issue is happening on high Sierra but I will double check before updating then try again once updated.

                  1. MMatty Harris @Matty_Harris
                      2021-07-01 16:29:03.547Z

                      I'm having the same issues. Did you find a solution?

                      1. Hm this is really odd - I'm on Big Sur here and have never seen it happen. Matty, do you have any special mouse-related kexts installed or other mouse/keyboard automation related software besides SF?

                        1. Ah, actually I do see that here as well. I'll investigate this further here

                          1. MMatty Harris @Matty_Harris
                              2021-07-02 16:15:31.380Z

                              Ohh. Good to hear. So it's not just me. I do have the logitech mouse. But I tried turning it off and using just the apple trackpad, and it still happened.

                              1. For the tech nerds and/or myself in the future: I have a feeling this happens because CGEvent processing apparently can end up out-of-order or miss/drop events if they are sent from a non-main thread on Big Sur+. We might just need to sequence CGEvent sending onto the main thread to fix this.

                                1. Another note to self: It can also be related to reusing the CGEvent object for the down and up click and/or be a simple timing issue (if Big Sur doesn't guarantee order of CGEventPost items).

                                  1. Ah, or it can be because we post click (up/down) events to SessionTap, but the move event to HIDEventTap. This should be pretty easy for me to troubleshoot :)

                                    1. Dustin Harris @Dustin_Harris
                                        2021-07-10 15:25:30.400Z

                                        if this is helpful, I figured out some more about this:

                                        below is a script that exhibits this cursor jump on my system. (in this context, I'm running the script with soundminer NOT open, so the script throws 0). If I run it once and wait a few seconds, the cursor stays where it was. If I run it twice in quick succession, the cursor jumps on the second run.

                                        sf.ui.proTools.appActivateMainWindow();
                                        
                                        try {
                                            sf.ui.soundminer.soundminerSpotToDaw();
                                        
                                        } catch (err) {
                                            throw (!sf.ui.soundminer.exists) ? 0 : `could not spot to daw: ${err}`;
                                        };
                                        

                                        video of it happening below. The first time I trigger it I wait a bit, the 2nd and 3rd times I do in quick succession, the 3rd time the cursor jumps.

                                        1. In reply tochrscheuer:
                                          Dustin Harris @Dustin_Harris
                                            2021-07-18 18:04:43.174Z

                                            What are the chances this is also the cause of my issue below? (as it also only started occurring since moving to Big Sur)?

                                            Original thread here:

                                            https://forum.soundflow.org/-4851/sfuiprotoolsappactivatemainwindow-intermittently-returns-error

                                            1. In reply tochrscheuer:
                                              Dustin Harris @Dustin_Harris
                                                2022-01-05 16:47:33.863Z

                                                adding onto this since it is driving me crazy. The only way I've been able to get the mouse to return to it's original position is to simulate a drag. setting the position isn't enough:

                                                const mousePosition = sf.mouse.getPosition().position;
                                                
                                                
                                                //... the rest of your code
                                                
                                                
                                                //...move mouse back
                                                sf.mouse.setPosition({ position: mousePosition });
                                                sf.mouse.simulateDrag({
                                                    startPosition: mousePosition,
                                                    endPosition: {
                                                        x: mousePosition.x + 1, y: mousePosition.y + 1
                                                    }
                                                })
                                                
                                                1. Dustin Harris @Dustin_Harris
                                                    2022-01-05 17:05:09.051Z

                                                    actually two back-to-back setPosition() calls with originalPosition and originalPosition.x/y+1 seems to be enough... the single setPosition() doesn't.

                                                    1. @Dustin_Harris - please note this is a public issue, not a beta thread. We're tracking this in SF-139

                                                      1. Dustin Harris @Dustin_Harris
                                                          2022-01-05 21:44:08.775Z

                                                          Oh, sorry about that!

                                    2. In reply toAdamDavidSmith:
                                      Dustin Harris @Dustin_Harris
                                        2021-07-02 13:56:00.344Z

                                        I haven’t thought much about it but this has also been happening for me as well. I’ve tried adding sf.mouse.getPosition and sf.mouse.setPosition at the beginning and end of some scripts but the cursor does seem to sometimes go somewhere else, often 0,0 in absolute coordinates?

                                        I’m using a Magic Trackpad 2 on a hackintosh, wired directly.

                                        1. S
                                          In reply toAdamDavidSmith:
                                          SoundFlow Bot @soundflowbot
                                            2022-01-12 20:29:50.416Z

                                            This issue has been marked as Done

                                            1. This marks that the upcoming version of SF should have a fix for this issue.