Set the next frame time at the project level.

[motion-canvas]

Set the next frame time at the project level.

[aarthificial]

switching to a x8 slowdown causes a recomputation that requires eight times as many frames to be computed.

There's no x8 slowdown, max is x4. But the recalculation that happens seems to be a leftover from before https://github.com/motion-canvas/core/issues/57
The goal of recalculation is to compute the new starting and ending frames which are currently independent of the speed. So I believe recalculation, in this case, could simply be omitted.

Currently, if the thread runner gets out of sync with the audio, the audio time is adjusted

That's not entirely true. If present, the audio serves as a master clock.
If the animation is ahead, it will wait until the next requestAnimationFrame:

motion-canvas/packages/core/src/player/Player.ts

Lines 300 to 310 in 355ce86

	// Do nothing if paused or is ahead of the audio.
	else if (
	state.paused ||
	(state.speed === 1 &&
	this.audio.isReady() &&
	this.audio.isInRange(this.project.time) &&
	this.audio.getTime() < this.project.time)
	) {
	this.request();
	return;
	}

If the animation is behind, it will try to catch on:

motion-canvas/packages/core/src/player/Player.ts

Lines 311 to 320 in 355ce86

	// Seek to synchronize animation with audio.
	else if (
	this.audio.isReady() &&
	state.speed === 1 &&
	this.audio.isInRange(this.project.time) &&
	this.project.time < this.audio.getTime() - MAX_AUDIO_DESYNC
	) {
	const seekFrame = this.project.secondsToFrames(this.audio.getTime());
	state.finished = await this.project.seek(seekFrame);
	}

So the framerate is variable, but it's controlled by the requestAnimationFrame loop and not the project itself.
The audio is only adjusted if the speed is different than 1 for obvious reasons.

When it comes to seeking/recalculation optimization, I played around with this idea when working on https://github.com/motion-canvas/core/issues/57 since the implementation was already there. If you set the speed to a high number, say 10, you'll see the performance gains you're talking about. But the disadvantage you've mentioned was the reason I dropped it.

Personally, I wouldn't say that accessing a value during a tween is bad practice.
It would only be a problem if you were to use this value to modify the timing. Pass it to waitFor or something like that.
Otherwise, the worst it could do is to produce some visual artifacts/discrepancies which I think would be an acceptable trade-off.

Anyway, as you've mentioned in the note, let's leave this as a ripcord for now.