
Flicks – A unit of time defined in C++ - robtaylor
https://github.com/OculusVR/Flicks
======
btown
This reminds me of how MIDI files [0] represent time offsets, in integral
"delta-time" units which can be set to either an arbitrary unit fraction of a
quarter note, or an arbitrary unit fraction of an SMPTE frame (which itself
can be specified in frames per second). Combined with an ability to
dynamically set tempo (at any delta-time offset) in microseconds per quarter
note, this allows practically any (Western) music to be represented with just
integer delta-times between notes, including crazy tuples and polyrhythms, in
a tempo-independent way; just find the greatest common denominator for your
subdivisions. You could have thousands of minute tempo changes over the course
of a performance and never lose fidelity due to rounding errors.

Apple's (formerly emagic's) Logic software actually made this visible to the
user, using 3840 delta-time units per quarter note and presenting an Event
List interface [1] where you could edit integers for offset and length
directly. As opposed to other WYSIWIG notation software like Finale and
Sibelius, it felt like Logic was hiding nothing from you; you could be sure
that everything you saw and heard was rendered declaratively from the same
underlying data. Moreover, if you were ever having trouble zooming/subdividing
the drag-and-drop user interface for whatever crazy triplet sequence you
wanted, you could just break out a calculator and specify exactly what you
want, knowing that you wouldn't be "fuzzing" anything by typing in a rounded
decimal number.

(It's a good lesson for us as developers - while it can be extra work to build
an interface that doesn't hide complexity, professional users will often
figure out how to use this to work around other shortcomings in your
interface, buying you time to fix them the right way. It's just a matter of
finding the right abstractions - representing time as integers is just one
example.)

[0]
[https://www.csie.ntu.edu.tw/~r92092/ref/midi/](https://www.csie.ntu.edu.tw/~r92092/ref/midi/)

[1]
[https://support.apple.com/kb/PH13096?locale=en_US&viewlocale...](https://support.apple.com/kb/PH13096?locale=en_US&viewlocale=en_US)

~~~
anigbrowl
_you could just break out a calculator_

Hold on while I break out a calculator to operate my computer. As a former
sound engineer I have to tell you nobody _liked_ Logic, they tolerated it as
the affordable alternative to Pro Tools until other tools came along. People
appreciated its reliability and depth but not the UX.

~~~
btown
Never claimed Logic had anything more than a tolerable UX - just that it got
the job done! As someone approaching it not as a sound engineer (for which Pro
Tools was/is the gold standard for a reason!) but as an amateur composer
wanting to actually have a modicum of control over both notation and the sound
of my demos, Logic straddled both worlds in a way that nothing else really did
- certainly Pro Tools barely even touched notation.

Though maybe I was just too stubborn to re-input things in different software
for each purpose. Needless to say, on the coding side, I was very excited when
Node.js was first released!

------
jhallenworld
I'm not sure I understand this:

"The NTSC variations (~29.97, etc) are actually defined as 24 * 1000/1001 and
30 * 1000/1001, which are impossible to represent exactly in a way where 1
second is exact, so we don't bother - they'll be inexact in any circumstance."

The NTSC color subcarrier is exactly 315/88 MHz, so one could make the flick
something like 1/528th of this period. The frame is related to the subcarrier
by 525 lines by 455/2 color clocks.

See:
[https://en.wikipedia.org/wiki/Colorburst](https://en.wikipedia.org/wiki/Colorburst)

So one NTSC frame is exactly 63063 flicks, one 30 Hz frame is exactly 63000 of
them, one 24 Hz frame is 78750 of them and one second is exactly 1890000000 of
them.

~~~
jepler
I agree with your line of thinking, but since they give 1/30 fps frame as
23520000 flicks, I get 1 NTSC frame = 23520000 * (1001 / 1000) flicks =
23543520 flicks.

I was all set to file a doc PR but noticed you have to file a CLA. newp.

~~~
zokier
It is worth noting that while you can represent single NTSC frame time exactly
in Flicks, it still does not fulfill their goal of representing "also 1/1000
divisions of each" for NTSC. To get there you'd need 1 Flick to be 25 times
smaller, i.e. 1/17640000000 seconds. Although this would go below 1 ns, which
was also one of their constraints, but I'm not exactly sure what importance
that really has.

~~~
pebers
Possibly range? At that scale the max representable duration is about 16.5
years (assuming they're 64 bits, IIUC the standard mandates that as a minimum)
which could be limiting - although that seems unlikely to be a concern in the
framerate domain, but who knows what it might get used for when that might
become an issue.

------
mshook
_While humans can 't hear higher than 48kHz, the higher sample rates are used
for working audio files which might later be resampled or retimed._

48 kHz? Someone probably got confused between Nyquist–Shannon sampling theorem
and the human ear...

And someone beat me to it hehe

[https://github.com/OculusVR/Flicks/issues/2](https://github.com/OculusVR/Flicks/issues/2)

~~~
vortico
>humans can't hear higher than 48kHz

Well, it's a true statement! (But yes, I agree)

~~~
jcelerier
Actually not that true, there were some experiments in the 50s that shown that
through bone conduction a human could hear up to 100khz. Likewise, babies hear
much higher frequencies than the "common" 20khz.

sources:

* [https://www.ncbi.nlm.nih.gov/pubmed/10848570](https://www.ncbi.nlm.nih.gov/pubmed/10848570)

* [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5285336/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5285336/)

* [http://asa.scitation.org/doi/full/10.1121/1.2761883](http://asa.scitation.org/doi/full/10.1121/1.2761883)

------
morio
Failure to handle NTSC frame rates is exactly why no one uses a time
definition like this. ISO/MP4 gets it right: Using a time scale with sample
durations. If you work with tracks or files with different time scales you
just use the smallest common multiple of those to become your working time
scale. Works every time, even for NTSC frame rates.

For instance for a file with 48Khz sound and 30000/1001 (29.97...) frame rate
you would convert to a time scale of 48048000. Worst case would be mixing
48Khz, 44.1Khz and NTSC video: 1009008000.

~~~
clord
I agree with you but what you describe is exactly what a flick is, except with
more stuff thrown in.

------
zokier
Its always amazing to realize how big 2^64 really is. 2^32 Flicks is about 6
seconds (which can be enough, but still not that useful), but 2^64 is over 800
years, which should be quite enough for anything needing this sort of
precision. It would be actually pretty nifty to have this in eg. `struct
timespec` and overall base rtc around Flicks

~~~
planteen
> It would be actually pretty nifty to have this in eg. `struct timespec` and
> overall base rtc around Flicks

I disagree. We already have enough confusion with time and another unit at the
level of timespec is not helpful IMHO. The SI unit of time is the second and
1/sec is Hz, which are used everywhere in science and engineering. I don't
want another non-SI time unit getting thrown around and messed up in
calculations. 800 years doesn't even come close to covering a single
precession rotation of the Earth (26,000 years).

The timespec structure already covers either 2^61 seconds (7.3 * 10^11 years)
at an accuracy of a nanosecond. So that's enough to cover 72x the current age
of the universe.

I have some experience in astronomical calculations. Things are already quite
confusing there, since you often need a monotonically increasing time scale
(without seconds leap seconds). There is already enough confusion if someone
is in TAI, GPS, or UTC time. Julian day, commonly used in ephemeris
calculations, works back to 4713 BC. Believe it or not, we sometimes want to
get positions going back that for things like computing proper motions from
ancient star catalogs, correlating supernova explosions, and various other
recorded historical astronomical events.

~~~
wahern

      > There is already enough confusion if someone is in TAI,
      > GPS, or UTC time
    

Don't forget BCT:
[https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time](https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time)

------
geuis
Was skeptical at first, but this makes a lot of sense. If you've ever done any
significant amount of media encoding or transcoding, this should at least get
a solid head nod.

------
jobigoud
To solve a similar problem FFMpeg uses fractions. So the unit of time is
defined by two numbers, time_base.num and time_base.den.

------
everdev
Can you "invent" a definition?

~~~
robotresearcher
Planck, Coulomb, Dirac, Fermi, Newton, Faraday, Avagadro, etc might think so.

[https://en.wikipedia.org/wiki/Physical_constant#Table_of_phy...](https://en.wikipedia.org/wiki/Physical_constant#Table_of_physical_constants)

Archimedes, Pythagoras and Euler might agree.

[https://en.wikipedia.org/wiki/Mathematical_constant](https://en.wikipedia.org/wiki/Mathematical_constant)

~~~
nextstep
Those people didn't invent those definitions...

~~~
mcgarnagle
... i don't follow, can you elaborate?

~~~
filmor
The units were names in honpur of those people, they (usually) didn't define
them themselves.

