-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Murphy schrieb: > Some people see editing as taking a long film and splitting it up. > For me it about organising lots of small clips into a big one and > PiTiVi was fairly good for that.
Hi Tim, yes, both concepts are equally valid and are known since the beginning of cutting film. I heard some people associate them with the two prevalent types of editing machines, where the horizontal working editing desk type machines would rather fit the "split and chain together" approach, while the vertical working moviola-type machines would rather tend to support "vaporize it into tiny clips and then build the movie up". > I would like tools that make it easy to see all my clips (first > frames) organise them into some rough groups and sequences - a kind > of album a bit like google picasa but with ordering. As far as I can see, we (Lumiera devs) are well aware of the importance of storyboard work, organizing your clips in the media bins etc. It may look as if we don't care, but this is just due to the fact we need to concentrate at the goal and with it the timeline first. Having said that -- especially this "media manager and storyboard" part would be a nice opportunity, where another developer could work without much interference with the work on the editing core. Btw, as our our current planning, Lumiera will have several "perspective" like GUI arrangements for focussing on different tasks. > Edit in low resolution Is one of our prime objectives. Support will be built into the core. > Use separate, asynchronous processes. Of course we do it this way ;-) Our rendering and data backend works mostly asynchronous with respect to the GUI. Christian is about to build an elaborate cache, which maps to a user provided caching area/file on disk. I (for the middle layer) will collect and provide the necessary information to invalidate cached data precisely on edit operations. I know this is ambitious, so please don't expect any results soon :-P > I also think that video processing tasks should be run in a separate > process from the gui so that they can't cause it to crash if they > crash themselves. No, No, No! That would be completely misguided, IMHO. We should never bend the architecture in order to "isolate" against possible crashes. The application must not crash, period. We should never tolerate "possible" crashes. That's the "broken window" theory, you know. Besides that, there may be arguments in favour of running the GUI in a separate process, e.g. to have the core and backend running on a dedicated video processing machine somewhere in the network. But there is also a massive drawback with this approach: having multiple processes means you need Inter Process Communication, which is costly both in terms of execution and development resources. Cheers, Hermann V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITBITZbZrB6HelLIRApskAKCDAcuP8bFZz3RA23d6GzwLhyY4sACdGYVI jGXSM7oxNCqQWAKu1n+D87M= =+Gs5 -----END PGP SIGNATURE----- _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
