'Fast Forward' animation option?

Hi
Is there any way to create a ‘Fast Forward’ for an animation, giving the user the option to speed up playback or a simple way to copy the timeline and shorten it to give that effect when passing a FFD button?

Of the top of my head…

Using JavaScript you probably need to look at requestAnimationFrame

There are some examples on the site and out in the broader web.

But it would mean also controlling most of th animation from JS and could get complex.

Or you could go to the scene inspector and select the timeline you want and click the timeline duplicate button [+]]

I am not on a mac at the mo so cannot go into any of the above in more detail…

But you may also need to make sure the original timeline goes to the equivalent frame when the >> has stopped so it is not out of sync.

In theory, yes but it’s probably not what you would expect. :slight_smile: (more on this in a mo)

You wouldn’t be able to do this on the fly.

And as @MarkHunte mentions … You would have to set this up before hand and it would become a logistical nightmare to match up where the time is on the first timeline to where, in the second timeline, the same point would be, in order to make it a seamless experience. Not impossible though.


As mentioned earlier, the “not what you would expect (perhaps) approach”.

I would control playback of the timeline with my own “interval” set (requestAnimationFrame could also be used … math would have to change accordingly) and use the

hypeDocument.goToTimeInTimelineNamed(timeInSeconds, timelineName)

in order for it to “play”.

For example, I have a 10 sec timeline and I create a loop that increments the “timeInSeconds” argument by 33.3ms (0.0333 - the time for 1 frame) so every 33.3ms I increment by the same value (as Hype timelines by default are 30fps) so if I click a FF button then I can just set the increment amount to double, triple, etc thus playing more frames in the same amount of time.

logic in code:

moveTimeline = function(multiplier) {
		newtime = time +  0.0333 * multiplier;
		hypeDocument.goToTimeInTimelineNamed(newtime, 'timeline')
		time = newtime;
		
		if (time >= hypeDocument.durationForTimelineNamed('timeline')) {
			clearInterval(timer);
			time = 0;
			startBtn.style.pointerEvents = "auto"; // eye candy and enabling click
			stopBtn.style.pointerEvents = "none"; // disabling click
			hypeDocument.setElementProperty(startBtn, 'opacity', 1, 0.4, 'easeinout') // eye candy
			hypeDocument.setElementProperty(stopBtn, 'opacity', 0.5, 0.4, 'easeinout') // eye candy
		}
		console.log(time);
	}
	
	timer = setInterval(function() { moveTimeline(0.5) }, 33.3);

Then on scene load setup some variables with default values and then you can use buttons to start, stop, ff (change multiplier), etc.

timelineControl.zip (18.8 KB)

2 Likes

This is a a good feature request :slight_smile:. There’s no way within Hype to do it so the above example is the best method right now.

3 Likes

Any chance of seeing this feature added? It’s been a few years :smile:

Your feedback helps push us in that direction! We’re debating adding it to the API, but to be honest it is unclear if it is worth the UI complexity within the app. Thanks.

No need to make it complex I think, 99% of the time we need to speed up a symbol and not a whole scene and if we need to - we can just add the scene parts into a symbol. So - speeding up a symbol would make sense, could have it right in the Element panel when a symbol is selected.

Love the app between, there’s nothing like it and it’s really intuitive once learned how everything works - which took a lot of time, since there’s no “tutorial” trail to follow which cover section after section. That said, the documentation is very thorough and great, however, a visual tool need visual learning.

Im thinking it likely will be timeline based.
Similar to the control timeline.

That would be even more flexible and logical, I’d vote for that.

However, something rather than nothing, please :slight_smile:

Here’s something… Physics Mini Templates for Tumult Hype 4

…Physics has TimeScale. It’s kinda neat, but it does have some problems.

Ah, it sounds like you have the code already. How does it work? Where’s the concern?

1 Like

It’s in the engine; if you have a drag controlling at timeline with “continue after drag” it uses a speed factor to finish playing the timeline back corresponding with the speed of the drag.

Product complexity.

After writing ~18 pages of just “Index”, I think we’re well beyond that point :smile:

DUDE… wow… how can you resist not adding this?