Flat UI StopWatch

Composition Gallery
, , , , , , ,
1

Simple flat UI stopwatch with the last runs displayed …

_

When going fullscreen, then leaving fullscreen again, pressing the keyboard make some finder alert noises. Because the window is not the most active front one then or something. Is there a way to get rid of this ? Just asking :)

I was also wondering what would be the best way to hide the flickr glitch on app launches. How can I make the composition show up only when the first fire on start hits the last patches ? I could make a dark layer on top that would fade out after a second. But any other ideas or comments welcome !

I hope to see a patch similar to Quart’z Signal patch. Fire after x seconds, fire on start then every x seconds … Much easier then to measure time and compare it with a “if value is equal or bigger” trick. Not the most awaited patches though :) But I might be missing an easier way in Vuo to do this ?

Instructions

Just hit the space bar to make runs, press enter to reset the stopwatch …

Note : Uses the Avenir font installed by default only starting at OSX 10.8 if I’m right

Flat UI StopWatch.vuo (18.6 KB)

Flat UI StopWatch.zip (7.57 MB)

StopW.png

2 Likes
2

Hey, @Bodysoulspirit. I like how this stopwatch is designed for timing a bunch of consecutive things.

When going fullscreen, then leaving fullscreen again, pressing the keyboard make some finder alert noises. Because the window is not the most active front one then or something. Is there a way to get rid of this ? Just asking :)

Sorry, that’s a known bug. As you said, after you leave fullscreen, the window is not active until you click on it.

I was also wondering what would be the best way to hide the flickr glitch on app launches. How can I make the composition show up only when the first fire on start hits the last patches ? I could make a dark layer on top that would fade out after a second. But any other ideas or comments welcome !

The composition has 3 triggers firing within the fraction of a second after the composition starts — Fire on Start Started, Render Layers to Window Showed Window, and Render Layers to Window Requested Frame. These are all happening at slightly different times, hence the glitch.

To avoid this, you can basically synchronize everything to the “Requested Frame” trigger. Specifically: Replace the Fire on Start with Allow First Event. Add Hold Value nodes to block the events from “Showed Window” from reaching the Render Layers to Window input port. That way, the only events that cause layers to be rendered are the ones from “Requested Frame”. See attached composition.

(I see that the reason you even have “Showed Window” events going into Render Layers to Window is because you’re making the text scale with the window. It would be nice if there were a more straightforward way to get sharp text in scalable layers. I made a note in our internal bugs/features system.)

I hope to see a patch similar to Quart’z Signal patch. Fire after x seconds, fire on start then every x seconds … Much easier then to measure time and compare it with a “if value is equal or bigger” trick. Not the most awaited patches though :) But I might be missing an easier way in Vuo to do this ?

You can fire every x seconds with Fire Periodically. As for the measure time setup, there’s a feature request: Node to set off a sequence of animations.  

Flat UI StopWatch_0-mod.vuo (19.6 KB)

3

Hi @jstrecker !

Thanks for your answer and I’m glad you liked the composition !!

Thanks for the tips and the modified composition, I will dive into that and learn from it !

Concerning the scaleable text you mean using the showed window is bad because it’s a heavy repeating input or what ?
Yeah the difference in Quartz as far as I remember is that still you could use the rendering dimension patch to calculate a text size, but once a value was given, it was given in Quartz’s coordinates and that was auto adaptive as the window resized.
Glad you take internal note for more text features for Vuo, I will perhaps make a feature request for it in a near future so that people can vote for its priority :)

And yes, fire periodically is already great, but firing once at a certain delay is great too, can’t wait for that new upcoming node you already chose to implement !

:)

4

Concerning the scaleable text you mean using the showed window is bad because it’s a heavy repeating input or what ?

In terms of the glitch on launch that you were asking about, the trouble with the Showed Window trigger is that it fires an event right when the composition starts — at roughly the same time as other triggers. This meant that the stopwatch graphics would be partially set up by the Showed Window event and partially set up by other events, at slightly different times.

The way this showed up for me (might be different for you) is that some “hello world” text would briefly appear, and then the stopwatch would appear. This happened because some Make Text Layer node would get an event from Showed Window into its Font port (causing it to output the default Text value, “hello world”) before it got an event into its Text port with the text to be displayed.

5

@jstrecker ok thanks