Reviewing some demos of kdenlive, it occurred to lions that Cinelerra might be manely used for compositing if it's used at all. Even then, it's used for compositing where some steps are better off baked in a paint program & imported as PNG alpha.

Kdenlive reminds lions of a lot of early features & workflows which later proved useless.  It's still interesting to see how much progress they made in a lot less time than Cinelerra, manely because they got ahead of the funding.  The hassle of going through a dialog to create a label & the rarity of ever needing names for labels were why lions got rid of it.

Looks  like they invested a lot in proxies but it was obvious that proxies weren't buying a lot of speed.  Lions started doing that & found it useless for the amount of use it would get & the mediocre performance boost.  

Keyframe easing was kind of interesting.  It looks like they have various baked curves.  Once again, a very rarely needed feature.  Lions only ever used plugin interpolation in the histogram to try to match a changing exposure.  That functionality might be useful in scale, translate, brightness.

Cinelerra probably could fold the plugin config object into PluginClient create, get, set functions.  The creator would take a parameter name, range, interpolation type, default value, supported interpolation types.  That would be a lot of overloaded functions.  The save & load functions would go away too.  Then there would be an interpolation selector widget for each parameter or for all parameters.

Histogram & curves would require a graph structure of parameters, quite complex to abstract.  Mixing the automated parameters with custom config objects would not be practical.  A single interpolation type would realistically have to apply to all the parameters,  This would be selected by a standard widget or menu on the timeline & each parameter would be limited to interpolation based on that curve type or not interpolated.

An alternative is keeping the existing config objects but creating an interpolate function to apply the plugin's curve type.  An interpolator abstraction probably needs to happen in any case.

The real solution is providing timeline curves for every plugin parameter.  That might entail a new timeline window for just editing curves & would be a big deal.

---------------------------------------------------------------------------

  The ability to specify start & end points for background rendering is huge & might actually make it useful.  Specifying multiple background rendering regions is bloat & a bit of a hassle.  Background rendering of any kind has hardly ever been used.  There aren't many tasks where the effort of setting up background rendering & being able to see every frame playing back at normal speed is justified.

Just changing the menu option from setting a start point to setting the region to the current selection would do it.  Manually restarting background rendering instead of dealing with the complexity of automatically detecting changes would be huge.  It's generally a very very complicated thing which has never justified the investment.

It suffers from the latency of getting started.  Having to wait to start playback is painful.

Young lion had a dream of background rendering with a renderfarm making very slow effects seamless.  Even today, the network latency would make that quite painful.  User interface responsiveness ended up more important than how fast it could go after it started.  OpenGL removed most of the need.

It's still kind of an interesting magic trick, just like in/out points. 

The only copies of lion kingdom's very first experiments in audio editing software are in

/dvd/floppies/dev_backup2/bobcast

with the original date stamps somehow surviving.  There's always been some interest in getting them running again, in order to compare the current level of bloat against the minimal product.  It would be quite difficult with modern, very complicated sound drivers.

Anyways, a long effort to revive bobcast involved converting the X11 calls to 24 bit color, commenting out the audio driver calls.  No matter what, it wouldn't draw the waveform properly.  The problem is the HP9000 it was written for was big endian.  That was it.  It came up again, just as it did 30 years ago.

Lions specifically went with X11 & UNIX because it was the most likely to work for all time with minimal changes & it did.

Beware the perils of going all the way & upgrading the audio functions to a modern driver.  There's nothing this program would be used for besides perhaps as some minimal WAV file player which shows a waveform & a cursor. 

Interesting design patterns involved never abstracting library functions inside functions.  Libraries were considered the final word, just like file formats.  The X11 calls were all called directly.  All user interaction was in the GUI when it would have been much easier to do text input & output in the console.

It definitely had bugs & limitations.  Vertical scaling wasn't clamped.  Waveform drawing had problems which still affect modern programs.  It had only 1 level of undo so the lossless editing was definitely relative.  Cutting an area was usually permanent.  The undo buffer was a binary EDL.

Labels were bare numbers.

 

 The workflow was to define sample accurate positions with labels, then select areas between labels with shift.

It could paste no farther than the end of the original file.  The edit list could grow beyond the end of the original file with paste only.  There was no way to paste silence or mute.  It was just for assembling recordings from bits of different takes.

In reality, this wouldn't have been useful without some kind of dissolve.  In those days, a fixed dissolve in every edit emulating tape splicing would have worked but been difficult to render.

Typical user interaction.  Young lion didn't yet realize that xterm was a graphical program written the same way.  Implementing a text console inside the bobcast window would have been easier than writing custom prompts out of drawing commands.

The EDL was a binary file.  In some ways, it was amazing how much of the essential functionality of an expensive program of the day could be achieved with 3000 lines of code on UNIX.  It was also amazing how much data such a small program could manage.  It could have been smaller if all text prompts were in the console.  Unlimited undo, mute, pasting silence would have been really small additions, but it seems young lion was running into the limitations of strictly keyboard commands & saw more than marketing in GUI's of the time.

Despite the romance of minimal, vintage software, lions would not be happy using this interface even for doing what it was intended to do.  Cinelerra has a lot of essential upgrades & a lot of bloat. Sometimes getting an essential feature requires a lot of bloat & a lot more stuff than originally envisioned. 

It was a different time when software was being written to solve problems rather than passing job interviews or making money.

Based on what was done with the Images Paint System of the 80's, keyboard commands had a lot of potential.  Some modern hacks like grapher could use keyboard commands to replace their difficult command line options. 

A lighter X11 toolkit might be worth it.  It would be single threaded, support just a single drawing canvas, take mouse, keyboard, resize events, support clipboard operations, & contain a text console library in place of all widgets.  The text console would overwrite the drawing canvas.  The biggest piece would be the clipboard support.  That could potentially be single threaded.

 

There's so much software nowadays, it's more practical to not have a graphical interface in most programs since no-one will ever see or have to learn how to use them.  The amount of software is going to push down the investment in interfaces.  Most content creation software is going to be replaced by generative algorithms.

----------------------------------------------------------------------------------------------------------------------------

Nice.  Nothing like that in US because US only votes liberal on election day.  This stuff destroys lion productivity, so they don't enjoy looking at it & have kind of a dread about participating.  It's still a bucket list item.