On Tue, 2007-08-07 at 11:35 +1200, David McNab wrote:
> Thoughts? Well, I've been thinking about the whole business of file loading. Although I'm completely new to Cinelerra and its development, I've had a scratch around the file loading. My basic thinking is that I think a lot of things are "too mixed in together", and a better layers of abstraction are required. It seems that the donkey-work for loading is in a function called get_frame(). get_frame() does some monkey-business with the classes VFrame and Asset. I have yet to determine what gets used in these classes. Plus, threads get in on the act, and there seems to be a special class for PNGs. Heaven alone knows why. What I would like to see is developer documentation, and a really clean interface. Separate the layer between interpreting the file and all the other bits that go on. Some of these classes have threads, which just complicates everything. It's a mess. Given a thin clean API, it would allow developers to separate out their code from the rest of Cinelerra. This would enable them to test sections separately. The whole approach holds the promise cleaner, more reliable, more compact, more reliable, and easier to program code. Debugging would be sooooo much easier. I'm not trying to sell magic pixie dust here. I think it'd really work. A file loader, for example, shouldn't have to worry about threads. That's somebody else's problem. Also, I haven't looked at the effects plugins that you were referring to. But again, I suspect that the plugins have to know a lot about the plugin architecture. This suggests that there ought to be a layer of abstraction between them and the effects coding. That way, one could write an effect, slap on a plugin archtitecture as an afterthought, or even "not bother" (just compile it straight in with the code). A guy could test his code without worrying about what PluginServer did or didn't do. ... of course, I'm saying all this without having read any code on the plugins. I'm suggesting that cinelerra 3 is cinelerra 2 with proper layers of abstraction. On the subject of scripting, and so on ... I'm not a Forth fanboy, but I've been thinking about a Public Domain forth called atlast. It's quite famous on account of its connections with AutoCad. With forth, you have a user/developer scripting language, configuration language, and even dynamic glue. Pretty good really. Another thought that springs to mind is if there could be some co-operation between the non-linear video editors. You know, Kino is writing its own effects, and file loaders, Open Movie editor is writing its own effect, file loaders, and so on, Cinelerra is writing is own ... you get the idea. Seems like an awful lot of similar things going on, all that duplication of effort. Those are my thoughts, anyway. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
