Peter Schlaile hat geschrieben:* es geht nur um das Dauerthema den Sequencer endlich mal auf eine ordentliche Codebasis zu stellen, damit das Ding wartbarer wird.
* dazu muß man den alten Code zu großen Teilen entsorgen und nochmal richtig machen.
wenn man man das ernst nimmt, schreibt man am besten wirklich gleich eine entsprechende video-anwendung mit vernünftiger oberfläche von grund auf neu. das ist halt leider eine sache, die man nicht einfach so nebenbei aus dem ärmel schüttelt. deshalb sind wohl auch alle entsprechenden freien ansätze im linux umfeld bisher recht unbefriedigend ausgefallen. wobei manche sachen wenigstens dazu geführt haben, dass gute und nützliche basis-infrastruktur geschaffen wurde (bspw. MLT).
ich bin in dieser frage ein bisserl skeptisch und will nicht so recht dran glauben, dass ein zuruf vom ton roosendaal alleine bereits genügen würde, damit sich an dieser situation etwas ganz grundsätzlich ändert. im gegenteil: manchmal würde ich mir fast wünschen, dass es diesen schreckliche krampf unter dem stichwort: "blender VSE" gar nicht geben würde. dann würden nicht immer wieder zeitgenossen diese längst verlassene monster-baustelle als "beste alle linux-videoschnittlösungen" entdecken und weitere sinnlose bemühungen aufs falsche pferd gesetzt werden.
ich würde es augenblicklich für wesentlich zielführender halten, wenn man mit vereinten kräften natron um eine timeline nach dem vorbild von nuke-studio/hiero erweitern würde. das schaut einigermaßen bewältigbar aus und würde entwicklerressourcen/-interessen sinnvoll bündeln.
ob das ganze dann auch für 3D-orientierte blender-anwender praktischen nutzen bietet, entscheidet sich alleine an der frage der interoperabilität bzw. kompatibilität in offenen workflows. genau das aber ist es, was professionelle lösungen momentan so deutlich von den ganzen linux videobastellösungen unterscheidet. es ist eine katastrophe wie erbärmlich es um entsprechenden projektaustausch im freien video-software-umfeld bestellt ist. den schwerpunkt also besser ganz bewusst dahin zu verlagern -- sich also nicht ständig nur über irgendwelche ad hoc flickereien am rande von in-house produktions-experimenten weiterzuwursteln, sondern vielmehr in sauberer zusammenarbeit mit unabhängigen anderen werkzeugen, anwender- und entwicklergruppen zu üben --, würde vermutlich mehr bewirken!