this isn't perfect, there's one delay when you tab out as the pending animationframe gets delayed before it switches to timeouts for new frames until the user comes back

Hm. I tried this patch out in several versions of Safari, Chrome, and Firefox, and while it doesn't cause any harm it doesn't actually appear to make any difference on Safari or Chrome.

Oh, I see the problem!

I did some experiments with both the above patch and a simplified version which entirely dispenses with requestAnimationFrame/onvisibilitychange and exclusively uses setTimeout().

In Chrome, requestAnimationFrame() and setTimeout() appear to behave identically; audio plays at the normal rate irrespective of page focus even with the simplified approach.
In Firefox, setTimeout() has a noticeably less consistent tempo on slower machines, but it does continue to trigger at nearly the normal rate when the page loses focus.
In Safari, setTimeout() is severely throttled when the page is not focused; it plays about 1 note every 2 seconds.

I'm not really thrilled about implementing features which work on Chrome but perform worse or not at all on other browsers.

hmm, it occurs to me that it might be a better idea to check how long a tick took and subtract that from the setTimeout delay, since i'm pretty sure that's effectively what requestanimationframe does (but with a variable refresh rate)