Am 02.09.2011 21:19, schrieb Thomas Giesel: > > <hermanr> Oh, so bbb moves immediately, before aaa is touching it? > <hermanr> That's even weirder! > < skoe> yes > < hermanr> Is there a valid case to be made for that behaviour? > <hermanr> Any at all?
yeah agreed, I was struck numerous times by that annoying behaviour. As usual, you understand *why* it behaves in that strange manner just by looking into the code: it was low hanging fruit to code it up this way -- but making it behave more like intended would require to build up some additional infrastructure beforehand. So (that's my guess), the author(s) of that code just came up with a clever hack/workaround: attach each new effect as a separate "pluginset", and then -- by definition -- the problem doesn't exist anymore (haha, because there is only one effect in every pluginset). Unfortunately any serious use of effects will end up with gazillions of pluginset- sub-tracks, making the handling of such scenes almost impossible, <sarcasm>but hey! I'm a coder and not a luser</sarcasm> OK, so to explain the more technical deatils: Cinelerra attaches effects within "pluginset" elements. As every element, they are attached to whole tracks, because the session datamodel only allows very limited per-clip properties. A pluginset is a sequence of effects. Timespans, which don't need/get an effect, are just cleverly represented as applying a "null" plugin. So basically a pluginset is a list (numberof_frames) (effect_to_apply, effect_parameters) (numberof_frames) (effect_to_apply, effect_parameters) (numberof_frames) (effect_to_apply, effect_parameters) ... Initially, the numberof_frames are just arranged by the GUI to coincede with the clips on the same track. And since cinelerra doesn't really implement dragging of clips, but rather has an adjust-operation on all "armed" tracks, any pluginsets will be adjusted in one sway and effects look as being attached below the clips. WHAT NEEDS TO BE DONE -- when we want to adjust the length of a single effect 1) locate the effect entry in the pluginsets 2) build a datastructure (or similar representation) which actually captures the meaning of "effect boxes" and "empty space" 3) move an "effect box" and adjust the "adjacent" boxes 4) protect against "overlapping" boxes and/or provide an mechanism to let the colliding effect box "jump" to an adjacent pluginset Oh my. that is real work. Especially 4) is quite challenging, given, that the existing structure provides no notion of "jumping", "adjacent", "box" "empty space", "occupied place", "overlapping". And besides that, it's processing of possibly overlapping value interval lists. Every programmer knows that this is one of the least rewarding and surprisingly tricky basic programming tasks to encounter. Given that understanding, you may start to appreciate the cleverness of the solution implemented in Cinelerra ;-) It could be seen as an instance of the well known "80:20 rule of programming": 20% of initial effort give you already 80% of the feature, and the remaining 20% will consume 80% of the time. Thus, as a programmer, today you're highly advised to build up most of your work from "initial 80%-s". Because our current culture especially rewards outright visible results. And, secondly, you're highly advised to get away before the users realise the missing 20%-s all over the place. Cheers Hermann V. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
