Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flicks – A unit of time defined in C++

github.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Flicks – A unit of time defined in C++

#31

Post by psyc »

zokier wrote: post #21

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

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.

Re: Flicks – A unit of time defined in C++

#33

Post by 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/

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

Re: Flicks – A unit of time defined in C++

#34

Post by planteen »

zokier wrote: post #21

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

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

Re: Flicks – A unit of time defined in C++

#35

Post by sitharus »

markrages wrote: post #25
sitharus wrote: post #22

Earlier quoted context omitted.

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.

Re: Flicks – A unit of time defined in C++

#36

Post by RMGgondella »

btown wrote: post #33

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) mus…

wow. nice hack

Re: Flicks – A unit of time defined in C++

#37

Post by cmrdporcupine »

btown wrote: post #33

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) mus…

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.

Re: Flicks – A unit of time defined in C++

#39

Post by em3rgent0rdr »

btown wrote: post #33

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) mus…

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

Re: Flicks – A unit of time defined in C++

#40

Post by robotresearcher »

leggomylibro wrote: post #23
robotresearcher wrote: post #15

Earlier quoted context omitted.

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

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.
Post reply on HN