PlaybackSpeed, Long-running processes, Weird non-blocking behaviour

[mattvonrocketstein]

Describe the bug

Like the title says, I'm seeing some weirdness with PlaybackSpeed, long-running processes, and non-blocking behaviour. Honestly not sure if this is a request for help, a bug report, or a feature request.

Setup

Ubuntu / bash / gnome-terminal, vhs version v0.7.2 (484e440)

To Reproduce

Sleep a long time to simulate a long-running command, and try to speed up the recap in the recorded gif.

Source Code

Here's an example test.tape:

Output img/test.gif 
Set Shell "bash"
Set FontSize 22
Set Width 1200
Set Height 1000
Set TypingSpeed 100ms
Type "sleep 2; echo done sleeping 2s"
Enter
Sleep 3
Set PlaybackSpeed 100
Type "sleep 100; echo done sleeping 100s"
Enter
Sleep 3
Type "echo doing next thing"
Enter
Sleep 3
Type "finishing immediately"
Enter

Expected behavior

If I sleep 100s and have 100x playback, I'd expect the recording to show a pause of 1s and then show "done sleeping 100s".
I'd also expect that vhs takes at least 100s to record the video, because it has to record in real time even if the playback is sped up.

Actual behaviour

3s into the 100s sleep, "next thing" prints, as if vhs got bored waiting on the first longer sleep.

Based on the output from vhs test.tape during generation of the above, it looks like it indeed just skips to the next steps in the middle of the 100s sleep, but shouldn't these be blocking steps that run in series?

Additional context

My use case involves recording a terminal session where there are several commands, some returning in seconds and some taking several minutes. Fast things don't need to be faster, but the slow things do actually need a large speedup because most of the time is spent waiting and there's not screen changes (ie just polling a cluster until it's ready). I can't know in advance exactly how long it will take for the commands to run, so adjusting timing pauses and playback speed doesn't work very well.

Rather than adjusting playback speed based on multipliers like 1x or 100x a base speed, what might be much more natural is to allow the user to set a maximum playback length, then let the system determine the framerate/playback speed that works.

I'm probably doing this wrong. None of the examples in-repo seem to involve long-running commands, much less commands with kind of randomized run-times, but that seems like it would be a common use-case.