More cinelerra bugs piled up, as lions continued doing more keyframe editing than usual.  Lions need to produce more movies that use all its features, though it has many alternatives at this point.  Constant keyframes didn't work in reverse playback & FloatAutos::automation_is_constant didn't work with constant keyframes at all.

 The problem is get_prev_auto & get_next_auto return different values based on the direction.

 get_automation_constant was an optimization in the days of 166Mhz to look up only 1 fade value for an entire audio buffer.  It might be overrated but it's technically correct.  It's used in a curious way inside VAutomation::direct_copy_possible because it's always true for a single frame of video.  It might be an artifact from when video was going to be processed in chunks, with pointers to arrays of pointers to frames.

 Then we have multiple ways of getting the constant value: 

IntAutos::get_automation_constant, FloatAutos::get_automation_constant always assume forward playback

FloatAutos::automation_is_constant, FloatAutos::get_value  use playback direction

Just a matter of yet more logic for constant keyframes. Got rid of the unnecessary constant check for video & converted the get_automation_constant calls to get_value calls.

Noted the range between 2 keyframes is a bezier curve if the left is set to linear but it's constant if the left is set to constant. The problem is some keyframe types for a rubber band curve should apply to the joining line instead of the keyframes but the difference between locked & unlocked bezier should apply to the keyframes.  It's a complex distinction other programs make.

The easiest compromise is to require the left & right to be bezier to get a bezier curve.  The user can only access the control points on both sides of the line if both sides are bezier.  The problem with that is it's impossible to go in & out of bezier in a single sample.  It needs to have a linear/constant keyframe & a bezier keyframe 1 sample apart.

Another option is drawing the left control point if the left neighbor is bezier, quite difficult but probably necessary.  Currently, the user has to temporarily change to a bezier type to edit the left control point.

Made the line type always follow the left keyframe's mode.  The edit keyframe dialog no longer disables the control point text based on keyframe type.  It would be extremely complex to enforce an ordering of operations & it's never been used.  The user shouldn't be forced into an ordering of operations.

Made the left control point drawn on the timeline if the left keyframe is bezier & the right control point drawn if the current keyframe is bezier.

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

 Then pondered if the keyframe edit dialog should update for user drags on the timeline, undo.  It would prevent clobbering of data, but the dialog has never been used.  The dialog actually updates the timeline in realtime.  It doesn't clobber the timeline when exiting.

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

 Then, a highly desired feature became a binding of = to the align edits function, but without the dialog box.  Lions ended up never using the align edits dialog.  It might be more efficient to have the options in global preferences or at compile time.  The signs point to getting rid of the dialog & making = the hotkey.

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

 A lot of stuff that would have been programmed 20 years ago isn't being pursued anymore.  20 years ago, lions would have pursued VST plugins, HDR capture, probably the MIDI support originally envisioned in 1997.  The everything editor died 1st.

Young lions might have continued developing the recording interface as they once did.  It could have supported multiple digital TV tuners, different input colorspaces.

 The timeline development could have continued with locked audio & video clips.  There could have been ports to newer graphics APIs.  Professional codecs could have been supported through investments in more cameras as young lion did.  There could have still been a server farm for manetaining the renderfarm feature.

 It points to a kind of attitude shift & time running out.  Young lion already knew time was limited, but it was more constrained by money than death.  Young lions programmed things for someone else to use instead of serving themselves.  But the capabilities young lion once pursued also became germane.  Digital TV & video capture isn't a major source of content anymore.  Cameras that are good enough are free.  There are now plenty of video editors with better capabilities.

Actually getting a program noticed by anyone is a bigger job than young lion thought.  There are hours & hours of support for every user & every patch contribution for things you'll never use has to be reviewed & fixed.  Continuous integration didn't exist in the shareware age.  It was still based on physical media.  You got 1 release as solid as possible & shipped it physically.

 

 

 

 

 

 

 

 

 

 

 

 

 

Comments

Popular posts from this blog