Change the red action to activate Soundly (I don't have it).
Change the green action to move to the coordinates to drop on, relative to Soundly's front window, using the Get button.
Soundly has plenty of keyboard shortcuts – to not have a good export to local database hotkey is utterly pathetic.
I would complain bitterly to the developers – they apparently don't give a hoot about their user's convenience or RSI issues... (Maybe the Pro version has more features?)
I took a run at this, and Keyboard Maestro fails – period. Some apps don't like the way KM emulates the mouse. KM is not nor will it ever be a mouse driver and thus will always have certain limitations.
I use a great little command line tool called cliclick for testing and was able to achieve reliable success using it for this task (see the appended macro).
I had to use the ease feature which somewhat emulates a human-like motion.
clicclick can be made from source or using HomeBrew or MacPorts.
The help for clicclick can be found by running this in the Terminal:
cliclick -h
-Chris
P.S.
FYI @peternlewis – I'm a little surprised Carsten's command line tool is outdoing Keyboard Maestro here, although it's happened a time or two in the past. Not sure what kind of witchcraft he's using...
There are a couple different APIs for simulating events, and a whole bunch of ways you can tweak them, so its hard to say what the difference might be.
I had a quick look, and Keyboard Maestro’s code is much more complex that cliclick, unsurprisingly, but uses the same basic API. The most obvious difference is this line:
usleep(15000); // Improve reliability
which essentially means that cliclick posts the click down event, waits 15ms then posts the click up event. Keyboard Maestro waits only 1ms. It's plausible that could be the difference in a poorly written target app.
I also tried a pause between the drag-down and drag-up events with cliclick, and that too failed.
Only by adding an easing flag of 20 could I get cliclick to work with this task.
-e <easing>
Set an easing factor for mouse movements. The
higher this value is (default: 0), the more will mouse
movements seem “natural” or “human-like”, which also
implies: will be slower. If this option is used, the actual
speed will also depend on the distance between the start
and the end position, i.e. the time needed for moving will
be higher if the distance is larger.
Ahh, if you are trying to drag, then you can try using Set Action Delay to set the Drag delay, which will delay after the click down/before the move and after the move/before the click up.
In that case it may need something like:
Click and Hold
Pause
Move a bit
Pause
Move a bit
Pause
Move a bit
Pause
Release
Using a loop for the move.
I'm sure I've posted code for moving the mouse smoothly somewhere on the forum. Something like this:
Except different calculations so the mouse moves from the start location to the end location.
You could probably just use Move 131,20 from the current position 10 times (not sure if that will be "smooth" enough for the target app, who knows.
It's not completely reliable for me on Mojave, but upping the repeat number and turning off activate Finder have improved that considerably.
With more adjustments I might be able to make it bombproof, but I think I'll quit here.
I'd like to add a found image action to move the initial point of the mouse movement, but the selection has a number of possible looks – and I'm not that motivated.
First of all, thanks a lot for taking my lazy-mouse-hand problems so seriously and sorry for me being so quiet recently on the topic I brought up.
Very interesting debate that was way too advanced for me which was one reason for my silent mode. I'm really glad and happy with the easy solution Neil came up. It works!
This version uses a found image of a section of the highlighted region to set the location of the click-and-hold. It also opens the destination folder specifically, in case it isn't Finder's front window at the time (set its path in the green action).
There's an optional group that sets how the Finder window will be displayed, to ensure that the file is dropped properly. This is just in case, for example, you're in Column View and a parent directory happens to be at the drop coordinates. You may find this to be unnecessary or undesirable; if so, simply disable the group.
Ah ok. We could do some found image conditions I suppose, but ultimately, the mouse is already likely to be near what you want to drag anyway. I can see why you gave up!
