QuickTime Screen Recording with smooth click and drag

[KBM]

Please don't knock yourself out on this one. I did figure out I could use my iMac (Intel) mouse and do an OK click and drag. I couldn't do the drag smoothly enough on the trackpad.

Trying to do a QuickTime "Screen Recording". During the recording I need to do a click and drag. But it happens instantly (well very very fast to be "precise") and I want the drag to be smooth for say 5 seconds. Can a drag be slowed down? It might be able to be done as a series of drags, but I can't imagine getting them accurately enough and I'd need about 100 steps, in other word, 100 drags which would require tuning. So I scroll (click and drag) from 6 am to 8 pm in steps of ten second each. I can do the scroll manually, but I'm not steady enough on a laptop.

I can get by with a fix for the above, the following are niceties for something I probably won't do very often.

I'd also like to automate starting the recording. But I can't get the click to start the recording. I recorded the click but doesn't work. I see a start in the QT dictionary, but I never could get AppleScript syntax. OK, I put in a pause and start it manually.

Better if there was a shortcut to start the recording, then I wouldn't have to click on a spot that may not always be in exactly the same place.

FindMyShadow is an iOS app to show shadows of building moving during the day.

[Nige_S]

@KBM

I see a start in the QT dictionary, but I never could get AppleScript syntax.

Most AppleScript "actions" require a target, either as part of the command itself or by wrapping the command in a "tell" block that sets the target. So you can use either:

tell application "QuickTime Player"
	start front document
end tell

or

tell application "QuickTime Player"
	tell front document
		start
	end tell
end tell

These work because the "New Screen Recording" you open will be the frontmost document in the QuickTime Player app -- if that may not be the case you'd have to find a way to explicitly address the correct document, but you should be OK here.

As for the move, this is my first go a mouse-drag scripting in KM (prompted by @Yu_Cai showing me that click-multidrag was possible), so it's a hack that you could probably improve on! But 390 pixels in 100 steps over 5 seconds is a loop of a four pixel drag then a 0.05 second delay, repeated 100 times (if the 10 extra pixels matter, only loop 98 times!).

Tested by using the line-drawing tool in PowerPoint -- see if it works in FindMyShadow.

[KBM]

Nige_S Thank you. I couldn't get the QuickTime aspects to work. But the Click and Move got me the important part.

Since I don't have to do this often, I just activated Screen Capture (Cmd-Shift-5), manually start capture and then with KM to start and move the scrubber. (I have to make sure the initial scrubber position is set correctly. Also a few set up steps for Screen Capture). My scrubber action ended up as so:

The 4.5 lined up with 10 seconds. No pause needed as this is already too slow. If necessary I'll speed it up in post production.

Thank you.

[Nige_S]

@KBM

The 4.5 lined up with 10 seconds.

Hmmm -- not sure you can actually drag 4.5 pixels! I wonder what KM does in that situation? I feel a test coming on. Totally agree with over-capturing at a slow speed and making it right in post.

Glad it's now working for you. If you end up doing a lot of these then it might be worth revisiting the QT issue, and there's also the command line screencapture utility (though it isn't well documented).

[KBM]

Maybe I just got lucky. Four pixels was close to 10 seconds, so I just SWAGed at 4.5 and it worked. But can't guarantee I didn't change something else. Lots of fiddling to make it work reasonably well. Just checked, the 4.5 pixel setting kept the recording at 10 second intervals (the simulated time for the moving sun).

Note that the two "drag to" fields stacked whereas before they were side by side..

Don't foresee doing much of this. Was to support a project my wife is working on. FindMyShadow was cheap and did what was needed. A very simple interface.

After a discussion with my wife realized I should put in a feature request for controlling the time of the drag.

[Nige_S]

Sorry -- I wasn't clear. What I meant was that I'm not sure you can drag half a pixel, so I don't know how KM is handling the remainder -- 4 then 5 then 4..., always rounding down, or always up, or something else. Which is why I feel a test could be interesting.

Note that the 4.5 pixel setting has little to do with the speed or the time required for the loop to complete. Heavily load your processor with other stuff and it'll take longer, restart and load only FindMyShadow and it'll probably be quicker. The time taken will depend on how fast your Mac can process those 100 drag events.

You may already know this, but the same company also has a web page that does this -- and it has an autoplay button. I haven't used either app so don't know how they compare, but the web version may be good enough for what you need.

[KBM]

I understood your response. See "Move one click and drag" option for duration for some discussion on speed and a slightly different way to handle it. And these .mov files are less than 1/10 the size.

I did remember the developer had a site with a player, but I didn't want to try to transfer to the site or rebuild what I had. I did have a background image which I imagined would complicate. And I still would have had to deal with recording it. And assumed saving what I I'd done would be harder on the site.

But thanks for answers.

[Nige_S]

Yes, it's neater and more generic solution than the one that I (a complete newb to KM) knocked up while reading the manual. Definitely one to bookmark. But it uses the same steps -- click and hold, a looped movement and delay, finished with a release.

The principle remains the same. There is no "click and drag this far over this period of time" Apple Event, so you have to calculate a loop count, move distance, and delay-per-loop that will achieve what you want. And it will only ever be an approximately-correct total because time taken for the move event varies by machine and even current processor load, and that isn't accounted for in the pause.

It does give me an idea, though! You could time-stamp the start of the movement and calculate the pauses on the fly every loop, based on (time-stamp + desired_duration - current_time) / steps_remaining. It still wouldn't be totally accurate, but would give a closer approximation. I'll see if I can knock something up based on the macro in the other thread...