Flicks – A unit of time defined in C++ | Hacker News Reader

Flicks – A unit of time defined in C++

github.com

191 pointsrobtaylor53 comments

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/

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

wow. nice hack

The developers at Emagic were truly something special back to the Atari ST Notator days. It's really unfortunate how Apple bought and killed off gems like SoundDiver, not to mention Logic for other platforms.

> "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..."

Actually pretty much every midi tracker program (which Logic is even though it also does notation) use delta-time units, of which 3840 per quarter note is pretty standard practice.

Sibelius & Finale are only notation editors. But notation editors might even internally represent the midi event times using 3840 delta-time units even though they deliberately hide that from the end user, for good reason because their user base is musicans who play written sheet music instead of dealing with midi. I don't know that for sure about Sibelius & Finale since their code is closed, but the open source MuseScore editor does use 3840. [1]

[1] https://github.com/musescore/MuseScore/search?q=3840

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.

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!

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

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.

The problem is that NTSC isn't 30Hz, it's 29.97Hz (or exactly 30/1.001Hz). This was due to some technical issues when introducing colour transmission, see https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate

I don't think you understand the comment you are replying to.

Yeah, I had a brainfade with reading comprehension. The OP is of course correct.

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.

CLA?

Usually: contributor license agreement.

newp?

Diminuitive of 'nope' :)

Ahh like this: https://goo.gl/images/eRKmN4

Thanks.

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.

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.

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

>humans can't hear higher than 48kHz

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

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/pmc/articles/PMC5285336/

* http://asa.scitation.org/doi/full/10.1121/1.2761883

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.

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

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

Why would it be nifty to base the underlying format exposed by the OS time APIs and real-time clocks be based on a unit that happens to be a integer divisor of a bunch of common audio and video formats in 2018?

Sure, flicks seems like a useful tool for people working in those fields, but what about the rest of us?

Seems a bit short sighted, or at least extremely unusual for the average person who doesn't care how audio or video is encoded but still deals with high precision time.

If I'm interested in CPU performance, should I suggest that time be denominated in units that are compatible with common CPU frequencies?

Indeed. The majority of my longs only need a few bits more than an int. The largest value I’ve ever needed was a 58-bit index/key for a combinatorial thing.

> 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.

  > 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

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.

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.

Can you "invent" a definition?

Yes.

You can if you want to try and plaster your name all over VR as a facet of soft lock-in and to arbitrarily insert yourself into every potential aspect of a fledgling industry.

Next they'll invent the 'Ocu-ternion', which is the same as a normal Quaternion but each scalar value is divided by a constant because...VR? Facebook? Who cares, the point is they own it.

i mean this doesn't strike me as any worse than AU or eV or any other unit rescaled for convenience in some particular domain.

if they try to claim patent or trademark that's obviously a problem, but otherwise is this so terrible?

> Who cares, the point is they own it.

The header file they provided is BSD licensed. You can use it freely, forever, for anything you want.

And applies only to this particular implementation. Anyone should be free to implement the flick time unit in any other language, or re-implement the flick time unit in C++.

IIRC the BSD license doesn't say anything about trademarks or patents?

(EDIT: Obviously, this doesn't invalidate your conclusion, but your conclusion doesn't follow from the premise, at least.)

It does not. But did you hear anything about patent or trademark protection sought by Facebook for flicks? Does releasing a BSD licensed implementation suggest to you that they intend to protect flicks this way?

I don't love Facebook's products, but I struggle to see the downside in them publishing this idea.

Which is fair, but I still have a problem with the sheer temerity of licensing a unit of measurement.

They licensed the right to use that header file. A concrete implementation of the idea, otherwise protected by copyright.

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

https://en.wikipedia.org/wiki/Physical_constant#Table_of_phy...

Archimedes, Pythagoras and Euler might agree.

https://en.wikipedia.org/wiki/Mathematical_constant

Those people didn't invent those definitions...

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

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

Bah. That's either wrong or overly pedantic, depending on the case.

At least Newton's lab of universal gravitation and Coulomb's law defined their eponymous constants directly.

In other cases the people doing the defining named them retrospectively after the originator of, or most significant contributor to, the concept that motivated the definition.

The point is that we ascribe enough invention to these definitions to commonly name them after the people who invented them.

Also, giving a name to a formula is "inventing a definition". If you're a programmer and you write a function, or assign the result of an operation to a variable, the act of naming that function or variable can be considered the same.

If you couldn't, vocabulary would be impossible.

Most freshman undergraduate mathematicians have had their fair share debating whether you "invent" or "discover" definitions and proofs. The general consensus is that you "discover" things that are very natural, and you "invent" things for which different mathematicians would have perhaps come up different ideas. But only one thing is shared between both sides of the debate: the distinction really doesn't matter and is definitely bikeshedding.

According to half the linguists, both might be right, just a figure of speech, while the other half would help them find the right word.

What else do you call the process of coming up with a definition for, say, a second or a metre?

Can you "invent" a lowest common denominator?

Not only that, you can apparently add a code of conduct to it :-)

All definitions were invented. What alternatives are you suggesting exist?

It is fascinating to dig into definitions and conventions that we know, and to realize that much of what we think of as universal fact is actually an arbitrary choice of history, canonized by time.

It happens often in math that people decide on arbitrary definitions. One fun example is Donald Knuth was fond of defining 0^0 = 1, while some other mathematicians prefer to define 0^0 = 0.

Reply on news.ycombinator.com