Who knew when you 1st discovered the hell of using minicom to bring up a dialup connection in 1997, it would end up the staple of many day jobs.  It was a most unlikely destiny, as unlikely as a career centered around the UNIX guru universe was in 1997.

 

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

 Transitions got a wave of binge coding 2 years ago, but they definitely need help again.  Beyond previews, they need GUI redraws for undo.  The plugin GUI's got revamped long ago to stay open & redraw during undo.

They need a revamp of the GUI close operation similar to what realtime plugins got.  Sadly, undo isn't capturing any tweeks in the transition GUI's.  Only the save operation is capturing the tweeks.

Reverse playback of transitions is broken.  It's skipping the end of the transition.  This wasn't possible to test until the transition widgets started reflecting their length & clicking on the transition widgets started positioning the playhead.  Reverse playback of transitions is necessary for time reversing effects.

Double clicking in a transition should select its entire range.

There's never been a way to copy transition settings.  There has only been a way to change the length of multiple transitions.  Transition support is very much a casualty of never being used & the lack of time to do anything.  It's definitely primitive.

 Lions never appreciated the fact that the crossfade transition is used like crazy for hiding audio edits.  Previews should get the video transitions used more.  1st base is just making the 1st audio transition with a GUI for testing.

 Audio is always fed to transitions facing forward.  The sample numbers are always 0 - transition length.  The transition routines are almost a separate program.

 The 1st new audio transition was a dropout between edits.  There could be a way to define a midpoint volume.  Then it could drop out or raise the volume but this would never be used.

 Another useful one might be a mute between edits.  It's conceivable to pinch the EQ of the outgoing while unpinching the EQ of the incoming.  Time stretching is not supported in transitions.  Stereo transitions are not supported but they could wipe an edit to 1 side of the sound field or create progressively more fake stereo.  Other programs might be doing that with stereo timeline tracks.  It's kind of a pain to have to change parameters in a separate transition for every channel, but clipboard for transitions should help.

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

As the big transitions effort dragged on, bit by bit between day job obligations, it grew to adding attach options in many context menus.  A ponderous number of functions devoted to drag & drop features lions never used had to be refactored. It made it especially cumbersome to add double clicking for transitions. 

Reviewing the growing list of unfinished support requests over the last 26 years, it became clear something could be done to get on top of more of the requests.  1 of the original strategies to get ahead was to leave out industry standard features in favor of simpler features that could achieve the same thing with less convenience.  A lot of people use vi even though it doesn't have the conveniences of graphical editors.  

No-one or very few animals use Cinelerra.  The only interest is from spectators who watch its progress on gootube the same way they watch videos about the commodore 64 but never ever touch one.  A lot of animals think video editors are going to be replaced by AI.

After 26 years, a struggling programmer's salary is never going to provide an exact replica of black magic but it can make something roughly as useful if the paychecks are used efficiently.

A lot of feature ideas arose during a brief time when lions were able to work on it full time & believed it could be commercialized along side Avid products.  The features never got dropped when lions went back to being restricted to holidays again & the commercialization never happened.

Everything dragging can do can be replaced with a single menu workflow.  Cutting out the arrow & I beam editing mode would free up a lot of bandwidth for needed functions like titles for labels.  If anything, dragging support hasn't been expanded or tested in years.

Everything clips can do can be replaced by the standard clipboard or possibly a multiple buffer clipboard.  The clip functions might have been direct copies of Avid.  What we really need for clips is plain text files.  What evolved during the full time era was a concept of local & global settings, an array of sub EDLs within a mane EDL, a separate set of buttons for clips, & it's just been horrendous to deal with.  

It probably could be done more easily by reusing the clipboard functions, with a persistent clipboard or a clipboard filesystem of some kind.  This creates the problem of global settings being passed to the clipboard buffers.  Probably, the local & global sessions could stay & pasting a clipboard buffer could leave out the global settings. Lions believe assets are all global & shared between all clips, so the paste operation would behave the same way it always did, adding missing assets to the project.

If anything, clips as they are could be replaced by a function to save the clipboard to a file or have the copy function save a file.   All the clips would be files & the files could be pasted using the existing load functions.  The naming & descriptions could be replaced by the filename.  There could be  file->save clipboard & edit -> copy to file.  To save the clipboard, just run vi.

The 1 thing clips allow is viewing just the clip in the viewer window.  Lions never did this though & didn't understand why a user would want to not be able to access anything outside the clip.  A file based clip would have to be viewed in a separate copy of the timeline.

Clips or no clips, the in/out points & the labels in the viewer are all lost when it's closed.

 An apply button in the file box would allow the user to select & paste 1 clip at a time or paste a bunch of them at once if they were sorted.

 In/out points are a 3rd feature lions really want to get rid of.  It confuses a lot of users, it's been very hard to support, & it's only been minimally used.  This too came from an industry standard practice.  

It's not possible to define a region in the viewer window without the in/out points.  It might be better for the viewer window to define labels & for the user to select regions in the viewer & compositor window just like the timeline.  These windows would have analogous horizontal fitting, zooming & scrolling but without enough room for a scrollbar.  The user would have to middle mouse button around.  Lions are done with paw tools.  Perhaps the timeline's timebar widget could be replicated & get middle mouse button scrolling, just a start & end time.

The viewer window only existed because of Avid.  Lions rarely used it but did use it.  Other programs have dropped it.  It's been a convenient way to preview media but it never facilitated any kind of editing. For multiple, synchronized cameras, you're cutting on the timeline only or running multiple copes of the program.

The viewer is definitely 1 of those features would could die. It normally starts crashing after every single change & requires a major debugging.  Lions suspect it was needed back when confusers couldn't run multiple copies of Avid simultaneously.

Drag & drop, clips, in/out points, viewer window are a lot of code.  On the other paw, it would be a shame to throw away so much investment.  It's the kind of thing which could gradually fade away as new stuff goes in.