Sometimes, bald eagles are the lucky ones.

Dreamed about the current day job getting acquired.  Instead of getting rid of the less useful employees, they got rid of everyone else except the lion kingdom.  Everyday, they expected a good show.  They were a bunch of 25 year old New Yorkers who weren't keen on any of the acquisition.  The lion kingdom expected to be let go all the time.

In reality, another guy quit & went to Facebook despite living in Beaverton.  It's been a tough go retaining employees.  They have a bad habit of bad mouthing everyone who quits, but lions know better.

Since the goog tube saw fit to recommend IMAX projection room videos again, let us remember a time when owning a high quality movie meant owning a 600lb roll of physical celluloid.

It wasn't all glamorous wrangling of the 70mm hardware containing a dream.  The theater was usually empty.

The movie didn't arrive as 1 big 600lb reel.  It arrived as 116 small cans which you'd manually splice together.  No need to pay for heavy freight when a human freight reconstructor can do the job for a lot less.

Now having all that on an SD card doesn't give the visceral sense of conquest that having it on a 600lb spool did & the quality of digital projection is nowhere close to 70mm film.  

As for the state of large format movies today, the last thing lions saw in an IMAX theater was Apollo 11 in 2019.  The lion confuser maxes out at 4k.  Cinelerra got all the proxy support required for large format in 2015, but it never got used.  The next piece was hardware encoding.  Now the bottleneck is the playback.  There is a growing desire to allow rendering to use the same OpenGL path that playback uses, but that doesn't solve the decoding.  Hardware decode into offscreen memory, with random access, remanes a difficult problem.

The other question is what should be done with speed curves, another feature which was never used.  Instead of a maximally pedantic implementation of how a speed curve should work, an idea gaining favor is an implementation of how a speed curve is actually used.  

This would be a single speed curve shared with all the tracks.  The speed curve changes the speed of the play head.  Instead of advancing 1 frame, it advances 2 or .5.  The behavior would be as if every track's speed curve was ganged, but they would all share the same data.  The speed curve data would be stored in a global space outside the tracks.  This might involve a lot of duplication of keyframe functionality.  Ideally, there would be a dedicated speed curve track on the timeline.  

The alternative is the 1st track having the only speed curve & a lot of management of what happens to that speed curve when all the tracks are deleted.  This might be the easiest way.

This design makes reverse speeds impossible.  Practical use dictates the same speed curve applying to audio & video.  Having an unsynchronized sound track would require nesting the EDL.  Practical use normally involves synchronizing all the tracks.  Each track could have its own play head & position, but this has been really painful.  Manually copying the speed curve to every track proved too hard.

The synchronization problem is important enough for all other editors to contain the audio & video in a single track.