On Tue, 29 Jan 2008 [EMAIL PROTECTED] wrote: > The Name? "Cin-3" is a placeholder until we have decided on a new name, > then we will do the renaming. Indeed, for all of us there /is/ a tight
I don't think the name is really all that important... but I do think that separating from Adam Williams and his project, is important. I want to contribute to an open-source project. I don't want to contribute to a commercial product that calls itself open source but releases code you can't actually use, which seems to describe Cinelerra. That doesn't have to be an insult to or disrespect of Adam and the many valuable things we've gotten from him; but benefiting from his generosity doesn't mean putting him eternally in charge of the open-source video editor he doesn't want to develop. It looks to me like many people involved with this project are not willing to really make it clear that they are doing something separate from Adam and the "official" Cinelerra. I think a name that didn't resemble "Cinelerra" would help make that clear, but the mindset (as you mentioned) is what I'm really concerned about and the name is just an indicator of that mindset, not the real point. > > Honestly, it's depressing how > > many of the suggestions I've seen are still obviously trying hard to work > > in as many letters from "Cinelerra" as possible, and still calling it > Can you tell me please what's depressing with that? I think the people suggesting names that sound like "Cinelerra" aren't willing to really accept and buy into the idea of having a name that isn't "Cinelerra," even though Adam asked us not to use the name "Cinelerra" and there are also good reasons independent of him that the project should want a name other than "Cinelerra." It's depressing because these are, nonetheless, the very best people available. If anybody could make this work, it should be the volunteers this project has; but even programmers of this caliber are getting bogged down in a destructively limited view of what they want to do. > Even if we often curse Cinelerra, because it crashes or hinders our work by > some features being designed in a limited and to simplistic fashion, > we should never forget it /is/ an achievement to have a complete editing > application which is basically usable for pro work. Would you have started I don't think it's basically usable, and it won't be until there are a lot fewer "remember to back up before trying this command" and "you can't do that" warnings necessary. At the moment I think it has to be called alpha code. Also, I have to be able to run it in the first place. If I could expect to be able to get it installed without being a programmer then it might be beta quality; but I can't. This is not about features being missing; it's about features that are there but don't work. It's also about behind-the-scenes issues, like being able to compile and install the software at all. That's barely possible with the existing system - I can sort of do it, but only by checking out a development snapshot and carefully modifying a lot of files that ordinary users should not have to understand, and installing a lot of libraries that I *already* installed and shouldn't have to go through installing again, especially because they're only used to support features I don't need anyway. In fairness: the build and install systems for all Linux video software packages suck. Mplayer is particularly bad. To some degree that may be inevitable given the unique combination of general complexity and intellectual property encumberances that applies to video software. But I think Cinelerra's build system is the worst of the bunch. > - Cinelerra can work with uncompressed material, and enables you to > work on MPEG material (eg. HDV) as a source format (not a delivery > format!) ...and you'd better remember to index the MPEG files with a separate command-line program first, because otherwise it'll load them but they won't actually work. And if you generate MPEG, you can't put it on a DVD because it'll have to be multiplexed first by external utilities. There are design reasons for that limitation (DVD authoring being a complicated task very different from video editing, so we can say it's not part of what the editor is for), but those issues aren't explained anywhere in a form understandable to someone who doesn't already know what "multiplexing" means. What the newbie sees is "I can't make DVDs with Cinelerra." You bet MPEG is not a delivery format; you can't deliver the MPEG you generate with Cinelerra. > - Cinelerra gives you *total* control on what is happening with your > video data. No "wizzard" or "cheat sheet" is patronising you, which > is an absolute must for professional work. Agreed. That's a good thing, but I don't think it's relevant to what I was talking about. > - Cinelerra has an compositing engine seemlessly integrated into the > normal workflow. Together with the automation facility, you can build > quite advanced processing chains "right in there" out of basic > building blocks (including the "pull" principle for rendering) That too is a good thing. But it's irrelevant to the problem I've raised that many existing features just don't work. It's not that they are hard to use or that they don't exist or are unimplemented or not user-friendly or have an ugly GUI: it's that they plain don't work. > I don't want to loose this power and I don't want to change the fundamental > approach with regards to this points, and I don't see any reason to be > ashamed of following this route. You don't have power if you can't use it, and if I can't compile and install Cinelerra, then I can't use its features no matter what its features are. That's more or less what I tell my students when they hand in code that doesn't compile, and they get the inevitable mark on it; as open source developers we don't get marks for our code, but maybe we should. Making it able to compile on a standard system, and use the installed copies of libraries it already requires, would not involve any major design changes or shame to the fundamental approach. It probably would mean having to break from Adam Williams, because he's not willing to cooperate with such an effort. There doesn't have to be any unfriendliness involved. If he doesn't want to work on a really open-source project (i.e. one that people can compile themselves, for real, expecting that that will work, no "don't do this, use the binaries instead" disclaimers) and we stop demanding it from him, everybody wins. > I understand, that from a users POV, you may not find much "killer > features" in our new project to start with. We even postponed GUI > discussions. We just want to unleash the power by removing obstacles. Don't confuse me with Marquitux - I don't see "missing features" as a significant problem with the existing system. I'd be quite happy with the existing features if only they worked. I see "build process doesn't really work" as a significant problem, but that shouldn't be a "feature"; it should be something we can take for granted. On my four-point list I guess DV support could be called a missing feature, but even that is mostly just because it appears in the menu. Given that DV doesn't work, DV has never worked, and nobody is trying to make DV work, why is it still listed as an option on the menu? And why do we still have a "record" dialogue box when recording in general, and recording from DV over Firewire in particular, doesn't work? And why are we still requiring the libraries for DV and Firewire and so on when those features don't work? Let's take DV off the menu already and get rid of the "record" dialogue box, since they don't work and evidently aren't going to in the future either. The other three are not feature-related. I think the system shouldn't crash, but no system should crash; that's not a missing feature. I think the system should be compilable and play nicely with the other software on my computer, but that also is something I ought to be able to expect from all software. And being really open-source has to do with the organization of the development team and isn't really anything to do with the software itself at all. -- Matthew Skala [EMAIL PROTECTED] Embrace and defend. http://ansuz.sooke.bc.ca/ _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
