Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Could you explain this more? svn allows branching, so why not just create as many development branches as required and work there? I do not know git, so could you please explain what git has over svn? (Not intended as an attack). On 16/08/07, Christian Thaeter [EMAIL PROTECTED] wrote: ... 2) Stop using SVN Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Martin Ellison wrote: Could you explain this more? svn allows branching, so why not just create as many development branches as required and work there? I do not know git, so could you please explain what git has over svn? (Not intended as an attack). I am out of office today. In short: SVN allows branching but does not support (enough) merging and has many many more problems. Best let linus explain: http://uk.youtube.com/watch?v=4XpnKHJAok8 Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On Thu, 2007-08-16 at 16:37 +0800, Martin Ellison wrote: Could you explain this more? svn allows branching, so why not just create as many development branches as required and work there? I do not know git, so could you please explain what git has over svn? (Not intended as an attack). SVN is centralised, git is decentralised. Git is reputably easier to merge. It also has scalability advantages, esp. wrt branching. In git, there is no authority. If I want to add a cool feature, I fork a repository, and add a feature. My repo then becomes one among any number of forks of the project. It is successful for Linus on his kernel development, but I think in Cinelerra it has lead to a bit of a mish-mash - surprising since the Linux kernel is undoubtedly a 2,3,4 or even 5 orders of magnitude more complex than Cinelerra. I think the problem is that git is good at creating forks, but merging is a social issue. So I might create a cool feature, but there's no guarantee that it will make it upstream. What Linus does is have a core of developers who he trusts, and he willingly accepts patches from his core team. He probably doesn't even look at what anyone else does. Now, those core developers probably work in key separate areas, meaning clashes are kept to a minimum. The core team, in turn, have their trusted sources - and in this way, the whole thing builds like a pyramid with Linus at the apex, Lord of all he surveys. Now, I could go and take a copy of the Linux kernel, and immediately produce a fork, declaring my branch to be superior. But that's a really bad idea. It's a bad idea because no-one is interested in my fork. What I probably should do if I want to submit a patch is branch something that is interested in the kind of patch that I want to contribute, and whose branch is eventually propagated upstream. And I think this is the main problem we're seeing in Cinelerra: lots of branches, but no upstream merging. So we're seeing lots of people making useful contributions. but that the code is just whithering on the vine. And I strongly suspect that as time goes on, the patches will become unmergable. Probably git is much better at svn when it comes to merging; but like svn, it isn't able to magically resolve code conflicts. I think what I'm saying is that git is merely a tool, it doesn't solve the social and organisational issues. That's for humans to sort out. At the moment, what I see, as I understand it, is: * Cinelerra-HV, which is Heroine's version * Cinelerra-CV, which is basically HV plus or minus a few patches, * ct, which is happy to part from both, attempting to bring architectural improvements and some bug fixes * cinelerra 3, which is basically a Cinelerra redesign * a number of other players (including my branch), which attempt to do various things in various combinations Git makes it easy to create forks. But forking is a serious business, and shouldn't be undertaken lightly. I think interested parties really need to discuss this issue. And perhaps we should be asking the question should we even really have a Cinelerra-CV version? Another key question might be: who produces the most code: HV, or CV? If HV is chugging along at a steady pace, rarely accepting patches, whilst CV is mired in difficulties, then one might form the conclusions that it's better just to use HVs code, and forget about CV, or maybe just use it for occasional minor bug fixes. OTOH, if the opinion is that HV is sluggish, buggy, and the CV version would be more dynamic, then we should probably conclude that we should form a proper fork, probably using git, and let HV play catch-up with us. It all depends what you think. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On 2007-08-16 00:49, Christian Thaeter wrote: Kevin Brosius wrote: On 2007-08-15 17:36, Christian Thaeter wrote: ... I think you won't get much feedback from the older core developers since these goals are so large and you haven't tackled a smaller piece of Cin first. I have done little work in my branches but get demotivated by this 'bottomless pit' discovery and that there is no much perspective to get new things merged into the SVN trunk because it breaks the current concept. I think thats exactly what many other potential contributors see. There are patches and contributions rotting somewhere. Well, this 'patches rotting somewhere' is an argument without evidence that you seem to keep making. You understand that we've had a standing policy that patches get added to the bug tracker for best tracking, or sent to the mailing list if you can't be bothered to add them to the bug tracker? They don't 'get lost' either place. A search will turn them up easily (which is one of the reasons I personally like these methods.) Maybe these patches you mention are rotting in git somewhere? ;) The more places people are told they can submit things, the more confusing it is. I only know of one or two Cin people that might go look at the git repo for patches, so if they don't get mentioned on the mail list or bugzilla, then they are going to rot there just as easily. And while mob is a cute idea, you'd better tag things with email addresses or some other contact information. If we can't come back and ask questions, verify platforms, or test cases, I'd question the value of any anonymous contribution. That just leaves you with a much larger pile of average quality code that you can't get further info on. Do you have any experience over 6 months on a large software project to have an idea of what it takes to get a usable product out? -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On 16/08/07, Herman Robak [EMAIL PROTECTED] wrote: ... Adam would not be able to fix this in a reasonable timeframe, even if he was given an exhaustive TODO list. Neither will we, unless a lot of the underlying code is redone to support all the stuff that an NLE and compositor of the future should support. It has to be maintainable, extensible and reasonably layered. It needs to be elegant and beautiful, too, or too few coders will be attracted to it. Doesa anyone know Adam's views on the questions that we have been discussing recently? -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
On Wed, 2007-08-15 at 00:21 +0200, Herman Robak wrote: On Tue, 14 Aug 2007 23:32:01 +0200, Edouard Chalaron [EMAIL PROTECTED] wrote: Well I am sorry, but the way icons look is of the last relevance I don't work better because icons look better. They could look better but I could not care less either. Same here. But people _will_ complain about the things they see, perceive or understand. So we will keep hearing complaints about the colours and the icons until they become more in style with the flavour of the month. We've had a similar debate in one of the Linux audio channels, about whether or not Linux soft synths should have realistic GUIs. Now me, I think it should be switchable - if I want a shiny groovy panel that looks *just like* a TB-303, then I should be able to turn that on and impress my Reason-using mates. For actually getting work done, I might want to turn it off, though. First impressions *do* count. Gordon ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
On Wed, 15 Aug 2007, Gordon JC Pearce wrote: First impressions *do* count. I am rather impressed by low-latency and real-sounding-effects than a GUI that is pretty. So a program needs to have a demo 'what kan be made with it'. You might notice that all 'keyboards' or synthesizers have this 'demo' button. To play a song or a rythm to show off what is capable... Stefan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
i am a bit pissed about any system and written http://www.pipapo.org/pipawiki/BuildingSoftware , Your comment made me think of Lisp, and how it already has a packaging system. I'm no Lisper, though. Whenever I've tried to use it, I generally think, oh hell, why don't I just do it in Python. Hope I haven't ticked off any real Lispers out there. ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
One of my fears about cinelerra is that there are a lot of git code branches out there, each doing its own thang, and I wonder how much good effort will ultimately be effectively wasted. Looking at http://www.pipapo.org/pipawiki/Cinelerra/GitBranches is enough to make most people's head swim at what's available. Look at one of the descriptions: ct My branch/fork of cinelerra. Fixes, code cleanup and redesing regardless of upstream mergability. My fear is that Cinelerra wont progress, but will just move around in circles, with users being left to decide which branch might best suit their needs. I almost feel there should be a committee of developers, perhaps like the PEP proposals of Python, or soemthing. Its purpose it to access one fact - the intergrability of any change. We basically want to know if any change will conflict with the change of anyone else, and work out ways of mitigating the problem. Just thinking out loud, you understand. - Original Message From: Christian Thaeter [EMAIL PROTECTED] To: cinelerra@skolelinux.no Sent: Tuesday, 14 August, 2007 11:28:58 PM Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? The downside is that we massively lack developers, unfortunally many previous contributors fallen away because they finished university, got new jobs or whatever. We aim to make cinelerra3 a open project where anyone can join and help as much as possible! If you are coder and interested, just join us. ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Martin Ellison wrote: I should also add, in regard to the icon controversy: The user interface should be organized around the user's workflow (that is, the workflow of whoever is editing the video using Cinelerra) . The important thing is that they are able to manipulate the workspace (the media assets, the clips, the EDL) in the way most conducive to producing the right output. The visual appearance of the interface is important to the extent that it facilitates or hinders that purpose eg can the user find thae function that they need by looking at the icons? is the interface clear and easy to read? I would toss out there that beyond even actual usability, in my experience a polished look to an application can make a bigger difference than it should. Don't underestimate the psychological effect that a friendly, professional looking GUI has on a user. For a tool like Cinelerra, which already has a steep, steep learning curve, it's somewhat important to give as many hints to a new user that it's going to work out in the end. I certainly understand that in a developer resource-constrained project like this, it's probably better to focus on core functionality until that's pretty solid. The plan I saw described recently seems reasonable, and as someone who's probably not going to contribute to development any time soon, I'm not going to make any demands... I would just suggest that users often find instabilities more tolerable if the rest of the interface seems to have been well-designed. Thanks to the devs and everyone for a great project. joey ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
I think this is a good idea, and one that I intend to have a go on. No promises, of course. After playing for a little while, I realised that it was going to be trickier than I first thought. Looking at flip - the simplest plugin - one sees that one has to worry about threads, and whether one is using opengl. So instead of saying here's a bunch of old pixels, now give me a new bunch of new pixels, a plugin writer seems to be burdened by all sorts of stuff. I'm wondering if the opengl idea was the worst idea ever. It just adds a whole new layer of complexity. - Original Message From: Martin Ellison [EMAIL PROTECTED] To: cinelerra@skolelinux.no Sent: Wednesday, 15 August, 2007 4:37:06 AM Subject: Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? have test benches for plugins so they can be debugged and tested independently of the main program. ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
On Wed, 2007-08-15 at 10:32 +0200, Stefan de Konink wrote: On Wed, 15 Aug 2007, Gordon JC Pearce wrote: First impressions *do* count. I am rather impressed by low-latency and real-sounding-effects than a GUI that is pretty. So a program needs to have a demo 'what kan be made with it'. But as I said, first impressions count. If it looks like it's going to be fun to play with, people will want to play with it. You might notice that all 'keyboards' or synthesizers have this 'demo' button. To play a song or a rythm to show off what is capable... I don't have any with a demo button, although admittedly the first few patches on a couple of synths are show off to your mates patches, like the M1 Universe patch (I don't have an M1). Gordon ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Mark Carter wrote: One of my fears about cinelerra is that there are a lot of git code branches out there, each doing its own thang, and I wonder how much good effort will ultimately be effectively wasted. Looking at http://www.pipapo.org/pipawiki/Cinelerra/GitBranches is enough to make most people's head swim at what's available. Look at one of the descriptions: *ct* My branch/fork of cinelerra. Fixes, code cleanup and redesing *regardless of upstream mergability*. The SVN was declared to be following HV and staying mergeable, hence I started my 'ct' branch where developers can work without this brakeshoe. When your ficl integration is finished I would be happily to merge it there, if I don't have the time, just turn it, get my ct branch and merge your work, publish it. Read on ... My fear is that Cinelerra wont progress, but will just move around in circles, with users being left to decide which branch might best suit their needs. Users should not come at the point where to have to decide, this is where developers play with and finally agree about whats going into a official distribution. Having developers work public is just more transparent, note that many things in these git branches (ichthyos bezier patches, pmdumuids widgetgrid, the bluedot theme fixes and many more) predate the git repos. Just no one known/noticed that they where hidden privately on some developers harddisks or forgotten as patches once send to the ML. Having the code publically available with a convinient tool is a big improvement. I almost feel there should be a committee of developers, perhaps like the PEP proposals of Python, or soemthing. Its purpose it to access one fact - the intergrability of any change. We basically want to know if any change will conflict with the change of anyone else, and work out ways of mitigating the problem. I almost agree, using git gives us only the tool at hands to be able to publish, distribute and merge code. There is still some need to make decisions what goes into the distribution. I say this is a *big* problem when working in a centralized way like with SVN, every commit has global implications for anyone else so people better don't do decisions than being blamed for breaking anyone elses expections. This might work in a cooperate environment where is some big boss who decides whats to do and what not. But in a community project where no one wants to take this role this just does not work! People have to lobby their ideas endlessly and still might be unheared, commiters which advance with new ideas get blamed because the thing was not acknowledged, ... For cin3 we now work in distributed way and everyone happily merges everyone elses work, decisions are just done by the one which works one some part and sometimes simply acknowledged on irc/via email. If cin3 gets some drive and more developers we might need some PEP process, voting or some comittee. But so far it turned out that the current friction-less approach works quite well. I would like to see such in cinnelerra CV too but this would require some redefintion of the project goals. My ideal would be if free software could be done in a evolutionary process, where good ideas are exchanged and reviewed between developers and maybe seasoned/interested users (only a distributed revision control system makes this possible). Good things will persist and be merged while unimportant or bad things just get abadoned (but stay alive somewhere in a public repo to be fixed or reconsidered anytime later). Its true that distributed revision control encourages forking and branching which leads to many many diverged copies. For a closed/centralized project this is a horrific scenario. People need to rethink this when they use distributed revision control, they have the tool to merge such a diverged source back under their fingertips giving them ultimate control of whats going into their branch. That saied still means that git is just a tool to enable such a workflow, for certain (many) things there is still need to communicate and decide about a future project directions between the developers. imo it becomes easier with git since it gives the right tool at hand to branch, try and review ideas without global effect on other people and without dazzeling with patches send per mail, but it is still only a revision contol system not your boss or project manager which makes the right decisions for you. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
From: Christian Thaeter [EMAIL PROTECTED] The SVN was declared to be following HV and staying mergeable, hence I started my 'ct' branch where developers can work without this brakeshoe. If I understand correctly: * Cinelerra-CV is the ct branch, and the ct branch is considered stable * Ubuntu uses the ct branch to create Cinelerra * cinelerra-svn is a track of the svn repository. What's the svn repository? * you are now mostly working on Cinelerra 3, and not the ct branch So a good strategy for those hoping to see their stuff into Ubuntu would be to base their repo on the ct branch? ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Mark Carter wrote: From: Christian Thaeter [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] The SVN was declared to be following HV and staying mergeable, hence I started my 'ct' branch where developers can work without this brakeshoe. If I understand correctly: * Cinelerra-CV is the ct branch, and the ct branch is considered stable no: cinelerra-CV is the SVN provided on cinelerra.org 'ct' is my private experiment to seed a version where people can actively do development work which may yield stable releases from time to time. * Ubuntu uses the ct branch to create Cinelerra I dont know what ubuntu uses. There are some fixes in 'ct' and people reported my branch working well (except some build system bug I can't track down, when it builds it should be stable at the current state) * cinelerra-svn is a track of the svn repository. What's the svn repository? cinelerra.org has a SVN repository, the git repository here at pipapo.org just tracks that for convinience. * you are now mostly working on Cinelerra 3, and not the ct branch currently true, the reason I started the cin3 thing was when I found some things which are hard to impossible to fix in cin2 (and thus in the 'ct' branch) which made me thinking that 'ct' may fail its goal being a refactoring/improvement. Dunno now if thats true but it definately needs much more work, prolly more than I want to invest alone. (Well, doing a cinelerra3 rewrite is even more work, but we will gain more than just bugfixes from that) So a good strategy for those hoping to see their stuff into Ubuntu would be to base their repo on the ct branch? I ever declared my 'ct' branch as private experiment, until others joins these efforts and it could be blessed some official 'cinelerra-improved'. This was only meant as seed for such a 'improved' version while I dont want to maintain it alone for an eternity. I had some talk with the ubuntu studio people some time ago with the conclusion that when they have issues (they had some about licensing) they should maintain their own branch and solve their issues in a way which is possible to feed back either into my branch or into SVN. I offered help when they approach me with this concept, so far no one came along so I don't really know whats going on there. When someone of the Ubuntu people reads this, please make a statement about this. I think, I write a separate mail about cinelerra2 maintenace.. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV Currently CVs goal is repackaging the HV version and fixing bugs. But a real community version should acknowledge progress and new features which are contributed by the community. 2) Stop using SVN Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. 3) Make releases Cinelerra CV has only this SVN there is no release schedule and no defined point when the source is called to be stable (well we can't define in a lack of testsuite and presense of many bugs anyways). This yields the result that anyone (including distributors and packagers) build on some (maybe recent?) svn revision. There are packages from many different versions out there which makes it not really easy to track reported bugs down. Users have doubts which is the best version for them already just because this linear revision history without release statements, which is imo more worse than a magnitude of git branches with defined releases (and maybe bugfix revisions on them) 4) Make tracking HV less important We want some branch which tracks heroines versions and refactors it into smaller commits as we are doing now, but this should be considered as tool and foundation of any work which is done on our releases. This means the CV version should be maintained in another branch and new features should be added on our development (or release) branches. Finally we may provide a backporting branch where imminent bugfixes are prepared to be mergeable with the hv-tracking version. So this becomes a way how we can contribute back to HV which is currently not a easy case. Maybe Adam once speaks about what he wants, so far he complained that the community didn't provide much useable feedback .. and admitably he was right, takeing HV less important will actually allow us to do more work and thus may provide more benefits for HV getting some contributions feed back. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Christian Thaeter writes: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV [ ... ] 2) Stop using SVN [ ... ] 3) Make releases [ ... ] 4) Make tracking HV less important Hear hear. I've been reading this thread and this is precisely what I would have liked to have said, but I'm not a developer so it's not my place to say. But even to an outsider, it seems that both communication and code exchange with HV is much, much too infrequent, and that this is holding things back. Btw. regarding the debate about the graphical interface and the style of icons, I'd suggest people take a look at the Jokosher project. Jokosher is an recording studio / nonlinear editor for audio, and it has very much focused on usability from the start. Imagine a first-time user trying to use something like Jokosher on one hand and something like Cinelerra on the other. I _like_ the concept and efficiency of the Cinelerra interface, but the GUI is ugly, hard to read and feels needlessly foreign in places where it could easily follow the conventions of common Linux apps (e.g. GNOME / KDE human interface guidelines). This is about much more than looking pretty, it truly is about usability and following interface conventions. I think there is a lot of low-hanging fruit that Cinelerra could pick relatively easily. It wouldn't be necessary to change toolkits or anything. Mikko ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On Wed, 2007-15-08 at 21:20 +0300, Mikko Huhtala wrote: Christian Thaeter writes: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV [ ... ] 2) Stop using SVN [ ... ] 3) Make releases [ ... ] 4) Make tracking HV less important Just gently to put my oar in again, I guess there are some good motivations for doing this, although I liked the black nature of the interface and thought it looked very professional from the start, and any of those changes are in the future, I understand. I just wonder if this might involve the demise of Cinelerra if you start a massive rewrite of the program, decoupling it from HV, then what happens to the CV version of things? Does it end here? Why not write a separate Video Editor with a *new name*, if it's going to be so different in structure and allow the current Cinelerra to continue, both HV an CV. I've come to like it and I fear that you might not get enough coders to successfully develop the new version and we'll wind up with lots of half developed lines none of which function well if at all and no really good freeware video editor. Maybe I'm seeing this wrongly, but it's just the impression I get from reading the recent posts,... like I've seen this scenario on other projects and it usually ends up badly, not always, of course. Just a thought. Hear hear. I've been reading this thread and this is precisely what I would have liked to have said, but I'm not a developer so it's not my place to say. But even to an outsider, it seems that both communication and code exchange with HV is much, much too infrequent, and that this is holding things back. Well, that could be. snip I _like_ the concept and efficiency of the Cinelerra interface, but the GUI is ugly, hard to read and feels needlessly foreign in places where it could easily follow the conventions of common Linux apps (e.g. GNOME / KDE human interface guidelines). You mean like putting preferences under the edit menu and stuff like that. Yes that would be progressive. This is about much more than looking pretty, it truly is about usability and following interface conventions. I think there is a lot of low-hanging fruit that Cinelerra could pick relatively easily. It wouldn't be necessary to change toolkits or anything. Could be nice, but is this what is falling under the category of human interface, which won't be touched for a couple of years. Fine, it can be good to get requests in early, but they may not remember it by then. Good ideas, though. -- Warmest Regards, Fred Williams ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
On Aug 15, 2007, at 06:12, Mark Carter wrote: I think this is a good idea, and one that I intend to have a go on. No promises, of course. After playing for a little while, I realised that it was going to be trickier than I first thought. Looking at flip - the simplest plugin - one sees that one has to worry about threads, and whether one is using opengl. So instead of saying here's a bunch of old pixels, now give me a new bunch of new pixels, a plugin writer seems to be burdened by all sorts of stuff. I'm wondering if the opengl idea was the worst idea ever. It just adds a whole new layer of complexity. I think the performance benefits of OpenGL are worth the complexity. Furthermore, you can deal with the complexity by providing an abstraction layer on top of OpenGL. That is, I believe, what Blender and Mac OS X do for their respective GUIs.
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
mark carter wrote: On Wed, 2007-08-15 at 19:36 +0200, Christian Thaeter wrote: 2) Stop using SVN I just saw a YouTube vid by Linus who is talking about git: http://uk.youtube.com/watch?v=4XpnKHJAok8 Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. I think the problem is that there's a lot of good code out there that isn't making it into the main tree, for want of a better word (and no, I'm not necessarily thinking of my code). Actually, I think the problem is only partly to do with it being in SVN and not in GIT. I think the main problem is lack of modularity. Without sufficient modularity, GIT can't help much. For example, I might even suggest (radically) that the plugins shouldn't even be in the git repository. People who want to write plugins should make their own repos consisting only of the plugin they want to submit. People developing the core of cinelerra wont even care about the plugins. Users can just download the plugins they're interested in, from whatever place they are available, and use those. Maybe packagers will come along and bolt the cinelerra core together with the plugins. It can go further. Take file loading. If file loaders were plugins, then that would be another that could be separated out. For cin3 we will do it this way, using the brand new git-submodule support which will become useable really soon. When it is time, detailed instructions will follow. For cin2, using git will just enable that someone sets up this infrastructure (I thought about doing this with the docs first, working together with raffa sometime next). You won't be able to propose / show such radical things on the SVN, git is just a enabler for this. The problem I see is that this has 2 parts 1. The modularization on the repository level, which is doable. 2. Tear the current sourcetree apart to modularize things, which has impacts on dependencies and build system setup. For the plugins that would be easy since they have already their own subdirectories, for filehandling and codecs this may involve quite much work and refactoring. What I'm saying is that in order for git to work, you have to have separate subsytems - with well-defined interfaces, of course. Thats one of the reasons which motivate cin3. I started to refactor cin2's sourcebase which seemed just to be a bottomless pit. I could be misunderstanding how git derives its strength, though.But I think the problem we're seeing is a lot of forks that don't stand much chance of being propagated to the main branch, which I think is a shame because it means that a lot of good effort has gone to waste. The question is who is responsible for deciding what goes into the main branch or moreover what defines a main branch. We need to change our goals first and define what has to constitute CinelerraCV releases and then think about some way how we work together to get the stuff in place, distributed revision control would be only a tool providing us the ability to reach this goals, but not make decisions about the project direction, thats clear. And thats exactly why I created this mob repository and my 'ct' branch, to free developers from the constraints that there is a stalled SVN branch with no much perspective to get things merged. Finally we have at least some discussion how to work this out, maybe really soon we can agree on some process how we assemble releases, maybe we just happily merge from each other and meet again in a few months and decide/vote what should go into a official release, or we nominate a Release Manager among us who is responsible to prepare the next release, or we use some shared git repo where anyone can push changes which will be blessed official and reviewed with the goal of a releaseable state. How we decide to do it lies in our hands, after all I try to push us into a Just-Do-It direction, we could talk endlessly about it, as long the current centralized branch is there, we will stuck to discussions with no progress. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On 2007-08-15 17:36, Christian Thaeter wrote: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV 2) Stop using SVN 3) Make releases 4) Make tracking HV less important I've been pretty silent on these issues so far, not wanted to put a damper on new ideas and contributions, but looking at all the ideas makes me think you should really consider a true fork. You've proposed: * Changing the project goals * Changing the project tools * Redesigning the core of Cin * Rewriting the core of Cin I think you won't get much feedback from the older core developers since these goals are so large and you haven't tackled a smaller piece of Cin first. The other thing that comes to mind is that you shouldn't co-opt the Cinelerra name for a new project (Cinelerra 3) if Adam does not contribute a reasonable portion of the code. It is, after all, his video editor. As the Cinelerra 2 code base is GPL, you can certainly use portions of it for a new design with attribution to Adam. The amount of work proposed for the new project is not unlike the scope of a project we presently have running at work. It's probably a 10 year project until completion. I suspect the core contributors are not thinking about a full rewrite at this time. I'd like to hear their thoughts also, of course. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Kevin Brosius wrote: On 2007-08-15 17:36, Christian Thaeter wrote: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV 2) Stop using SVN 3) Make releases 4) Make tracking HV less important I've been pretty silent on these issues so far, not wanted to put a damper on new ideas and contributions, but looking at all the ideas makes me think you should really consider a true fork. I think declaring this a true fork would be contraproductive, my least intention is to divert the cinelerra community, I wan't to get some new drive where people are motivated to contribute. At some extent, this will only work if the Community supports this (if not, fine, stay where you are). Yet alone the discussion started now may hopefully yield some result which leads to little progress. You've proposed: for current CinelerraCV: * Changing the project goals * Changing the project tools As new project: * Redesigning the core of Cin * Rewriting the core of Cin Take this as 2 different things which don't depend on each other and could happen each one alone and in parallel. I think you won't get much feedback from the older core developers since these goals are so large and you haven't tackled a smaller piece of Cin first. I have done little work in my branches but get demotivated by this 'bottomless pit' discovery and that there is no much perspective to get new things merged into the SVN trunk because it breaks the current concept. I think thats exactly what many other potential contributors see. There are patches and contributions rotting somewhere. The other thing that comes to mind is that you shouldn't co-opt the Cinelerra name for a new project (Cinelerra 3) if Adam does not contribute a reasonable portion of the code. It is, after all, his video editor. As the Cinelerra 2 code base is GPL, you can certainly use portions of it for a new design with attribution to Adam. I agree that we could only name it Cinelerra 3 when Adam supports this decision. We will certainly reuse some of his code and I have the hope that he contributes/joins the efforts somehow/sometime, but thats really up to him and I don't want to make guesses unless he speaks out. So far we would like to name it cinelerra 3 because out intention is to create the next incarnation of cinelerra and not just another video editor. The amount of work proposed for the new project is not unlike the scope of a project we presently have running at work. It's probably a 10 year project until completion. I suspect the core contributors are not thinking about a full rewrite at this time. Well, then think about it. I know that this is a massive task for the next few years and we won't or even can't do it alone without support and help from the rest of the community. I'd like to hear their thoughts also, of course. Me too, well I can only stress that this might be started by a few people as now, giving it a seed and motivation, but it will require the experience and involvement of more people in future to become a success. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Hi all, Hi Marquitux!! Nice to see you again. And happy to know you always use Cinelerra for your telenovela's editing needs. I like your question. Are you satisfied by the responses? I agree with you : Cinelerra-CV didn't already choose his own way to follow (as cehteh said in one of his previous mail == the CV version should be maintained in another branch and new features should be added on our development (or release) branches). So FIRST OF ALL to answer to your principal question, Cinelerra need to make his (or her) own way to know where he (or she) is going. Lot of ideas expressed here to improve Cinelerra are (in my opinion) all valuables: Cin3, Cehteh's plan for Cinelerra maintenance in four steps seems nice, Mcarter's ideas about modularity, or your ideas to make DVD templates. BUT to do such things you need people ... and the goods one : CODERS! In my opinion Cinelerra needs both Coders and Users: The most the merrier! So I think to attrack both of them we have to create a sort of buzz arround the Software and making videos with open source softwares (since Cinelerra is one of the most interesting video editing software in the OS community). Rafaella aka raffa (on irc://freenode.net/cinelerra ) would say I'm a dreamer so let's dream a little: - First we should be conscious that Cinelerra is one (maybe the better)of the few quality valuable software for open source video editing. Nevertheless, Cinelerra is not very known by the OSS community. Lot of people knows Kino but ignore Cinelerra. We should promote Cinelerra more and invite poeple to use it. No need a 64 bit workstation. We should not say Cinelerra interface is hard to understand (or it's ugly) ... This is not true. - How about designing a new web site to make it more appealing? As a user suggested it on the irc... cvs.cinelerra.org looks like a developers' website. - How about having a blog for the community ? The reasons of this blog was explained in one of our precedent discussions. - How about searching a sponsor to support the development of Cinelerra? This idea was expressed on the irc by Cehteh in particular. What about Mainconcept or an association of little broadcasters? Why not? - How about porting (to a long term) Cinelerra to Windows stations? Like this is done for major OSS software now like gimp, inkscape, blender, firefox etc etc. The fact is Windows users (no pro users) don't have lot of alternatives to edit videos on their stations. Marquitux, your thoughts on Cinelerra's (bad quality) effects interest me. Why do you think they are bad? How should they do? What do you think about freeframe == ( http://freeframe.sourceforge.net/about.html ) ? Lot of things can be done with Cinelerra, we should have some tutorials on the cinelerra-cv site like the link you provided. Thanks With regards Roland C. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Well I am sorry, but the way icons look is of the last relevance I don't work better because icons look better. They could look better but I could not care less either. Moreover they probably are gif files in a corner of the source directories ... If conversely someone could write something in depth about keyframing that would be great. Thanks E On Tue, 2007-08-14 at 15:24 -0500, Timothy Baldridge wrote: Well said, I feel the same about Cinelerra. If nothing else, replace those horrible effects icons with something that at least tries to look professional. Timothy
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
On Tue, 14 Aug 2007 23:32:01 +0200, Edouard Chalaron [EMAIL PROTECTED] wrote: Well I am sorry, but the way icons look is of the last relevance I don't work better because icons look better. They could look better but I could not care less either. Same here. But people _will_ complain about the things they see, perceive or understand. So we will keep hearing complaints about the colours and the icons until they become more in style with the flavour of the month. The developers don't feel strongly motivated by that, though. I am not shaming the developers for not caring about the end users' complaints. Nor am I shaming end users for complaining about things that the developers never will consider urgent. I am just pointing it out. If you want to vent here anyway, I don't mind. :-) In light of this, I think Christian Thäter's protocols for work on Cin3 are clever. You have to hang around on IRC and poke around with the git repositories, regularily. If you don't, you are out of the loop. People who are talkers and not doers will have to spend a lot of energy just to stay in the loop. They will either get a more intimate insight into which ways things are going, and why, or they will get fed up and leave. It makes trolling much more expensive, and it makes the doers stand more clearly out. These are interesting times :-) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
marquitux caballero wrote: in the comunity very cool people tried to explain me thos things, but they seems to be very focused in specific issues, and those BASIC things, are not important in this part of the coding process, and they told me those things are BUGs... really? bugs? or bad plannig, or even no global vision? Few people from IRC gathered together to plan a rewrite/redesign of what ought to become 'Cinelerra 3'. Please take a look at: http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/Manifest http://www.pipapo.org/pipawiki/Cinelerra3 So far we have very cool ideas about a new design which allows a lot of things which are currently not possible, some coding has started but this is rather in a experimental, preparation phase. The downside is that we massively lack developers, unfortunally many previous contributors fallen away because they finished university, got new jobs or whatever. We aim to make cinelerra3 a open project where anyone can join and help as much as possible! If you are coder and interested, just join us. I've send a http://www.pipapo.org/pipawiki/Cinelerra3/Announcement about this 'cinelerra 3' project to all developers, so far the responses where very sparse but postive. A note to all 'users' reading this: Please refrain from sending feature request and ideas to us, its way to early and only costs our time to explain that we consider this things later. Ichthyo and me decided to design cin3 from ground up. Interested people should start by checking out the git repositories and review what is there. If you know how to do things better ask the responsive author of the current thing on IRC or via mail and do a discussion with the involved people about it. Speaking for me, I would like to see improvements and new ideas, but I don't want to become overthrown by people just dropping ideas and then disappear. Further note about HV's involvement: I informed him at first about this ideas, but his responses are sparse as usual. It is clear that this may only become Cinelerra 3 if he acknowledge on this project at some time and he is invited to join and contribute whenever and as much he wants to do (we aim to reuse code and ideas from cin2 anyways). Cinelerra is a heroinewarrior project, Cinelerra CV is a (friendly) fork of it, we don't want to take over the project, our goal is just to make the best free Linux Video editor in existence :). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
On Wed, 2007-15-08 at 00:21 +0200, Herman Robak wrote: On Tue, 14 Aug 2007 23:32:01 +0200, Edouard Chalaron [EMAIL PROTECTED] wrote: Well I am sorry, but the way icons look is of the last relevance I don't work better because icons look better. They could look better but I could not care less either. Same here. But people _will_ complain about the things they see, perceive or understand. So we will keep hearing complaints about the colours and the icons until they become more in style with the flavour of the month. Well, I don't write here often, but it doesn't bode well for the future of the product if developers don't care about things that the end users want to see. It makes me nervous about what might become of Cinelerra. Keep the good stuff, please, because I like the thing. If there's streamlining that can be done, great, but the interface, icons notwithstanding, has been good. I like working with it, what little I've done, and I don't want to have to stop and learn a new system. For goodness sakes remember to document too. -- Warmest Regards, Fred Williams ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
I really have to learn how to use a wiki... On the site, I noticed you want to keep as much as you can to C coding. That said, has anyone considered using Qt for a GUI front-end (or at least the qmake mechanism)? It might make it easier to build Cinelerra for multiple platforms and expand the user base. Just a thought... Dave On Tuesday 14 August 2007 18:28, Christian Thaeter wrote: marquitux caballero wrote: in the comunity very cool people tried to explain me thos things, but they seems to be very focused in specific issues, and those BASIC things, are not important in this part of the coding process, and they told me those things are BUGs... really? bugs? or bad plannig, or even no global vision? Few people from IRC gathered together to plan a rewrite/redesign of what ought to become 'Cinelerra 3'. Please take a look at: http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/Manifest http://www.pipapo.org/pipawiki/Cinelerra3 So far we have very cool ideas about a new design which allows a lot of things which are currently not possible, some coding has started but this is rather in a experimental, preparation phase. The downside is that we massively lack developers, unfortunally many previous contributors fallen away because they finished university, got new jobs or whatever. We aim to make cinelerra3 a open project where anyone can join and help as much as possible! If you are coder and interested, just join us. I've send a http://www.pipapo.org/pipawiki/Cinelerra3/Announcement about this 'cinelerra 3' project to all developers, so far the responses where very sparse but postive. A note to all 'users' reading this: Please refrain from sending feature request and ideas to us, its way to early and only costs our time to explain that we consider this things later. Ichthyo and me decided to design cin3 from ground up. Interested people should start by checking out the git repositories and review what is there. If you know how to do things better ask the responsive author of the current thing on IRC or via mail and do a discussion with the involved people about it. Speaking for me, I would like to see improvements and new ideas, but I don't want to become overthrown by people just dropping ideas and then disappear. Further note about HV's involvement: I informed him at first about this ideas, but his responses are sparse as usual. It is clear that this may only become Cinelerra 3 if he acknowledge on this project at some time and he is invited to join and contribute whenever and as much he wants to do (we aim to reuse code and ideas from cin2 anyways). Cinelerra is a heroinewarrior project, Cinelerra CV is a (friendly) fork of it, we don't want to take over the project, our goal is just to make the best free Linux Video editor in existence :). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
David Kletzli wrote: I really have to learn how to use a wiki... On the site, I noticed you want to keep as much as you can to C coding. That said, has anyone considered using Qt for a GUI front-end (or at least the qmake mechanism)? First is was just up to reply following text to Fred Williams: Just before someone complains that I told we don't take user requests for cinelerra3 some explanation: * we currently work under the hood, how the render pipeline is constucted, how files are accessed and cached, how plugins are loaded into the core, how to interface different programming languages and so on. * A new GUI is far out of topic yet (and for long time comeing) and we don't want to be disturbed by Qt vs. Gtk flamewars. * When we start a new GUI (in 1-2 years?) first and foremost it should be functionally as identical as possible to the existing GUI. * After that we need to add some sane way to support the new features which will be there by then (more modifications on the render pipe etc) * Finally completely new features may be added, maybe users have ideas we don't know about, lets see. I opt for a 'add only, dont alter/remove' functionality (with *very* careful exceptions) * as ongoing effort we would consider how to improve existing usability in a convinient way, where user feedback and testing would be welcome. It might make it easier to build Cinelerra for multiple platforms and expand the user base. Multiplatform is far more than a build system and gui toolkit decision. Cinelerra is free software and we target Linux, at a lesser degree we might target other unix'ish platforms (thats not too complicated Edward Sutton already maintains a FreeBSD port). But considering our very low developer resources, the non-freeness of some other OSes, a broad competition of other products on mainstream desktop OSes, the uglyness of Win32 API's (and aqua likely too?) and many many other things. I'd just say no thanks I don't care for such portability. The price is just to high. That saied, if someone else wants to maintain ports to non free/nonunix OSes, go ahead, his contributions will be welcome. About build system: we currently trying to use some in parallel (namely scons and automake, someone wants to provide help with cmake?), as long we are testing and playing and the project is quite small this gives a good prooving ground for later decisions which we want to keep. Actually i am a bit pissed about any system and written http://www.pipapo.org/pipawiki/BuildingSoftware , even started to play a bit with the idea, but put that on ice, as long no one will help with such a project, its just to time consuming for me. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Free/open source projects that succeed seem to follow the pattern of moving as much functionality as possible out into plugins/modules that can be decoupled from the core code. This makes for something of a Darwinian development process as individual plugins can be written, debugged put into the optional list, tried out, used, and ultimately replaced. Also it makes it easier to code, test and understand the code. I would suggest: - have test benches for plugins so they can be debugged and tested independently of the main program. - use Cinelerra-independent standard interfaces if possible, so that the plugins can be reused in other projects, and other project's plugins can be used in Cinelerra. Generally go for standard everything (and cross-platform) if at all possible, you get more people who already know it: - C or C++, python, ant, wxWidgets (what does Cinelerra use at the moment?) - there is a standard Edit Decision List (EDL) format out there; could Cinelerra use that too? -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
I should also add, in regard to the icon controversy: The user interface should be organized around the user's workflow (that is, the workflow of whoever is editing the video using Cinelerra) . The important thing is that they are able to manipulate the workspace (the media assets, the clips, the EDL) in the way most conducive to producing the right output. The visual appearance of the interface is important to the extent that it facilitates or hinders that purpose eg can the user find thae function that they need by looking at the icons? is the interface clear and easy to read? -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
[CinCVS] WHERE CINELERRA IS GOING? ...anyone?
hi, I´m Marcos Cabalero from Argentina, and I have replaced adobe premiere for cinelerra for almos a year, so I want to ask: Does anyone knows where cinelerra is going? I mean I love the speed in my AMD64, premiere stays behind playing clips or stuff like that. but After all this time, why am I supposed to have a 64 bit, with a 1990´s envirnoment, come on people, I can´t still drag several clips at the same time... what is the workaround? cut and paste silences? seems like cinelerra STILL very grab to the Broacas2000 audio suite environment. Why do I need to create a renderfarm, wich is a great idea, just to see thos horrible effects, I mean, have someone use afterFX or premiere sometime? way not make Cinelerra compatible with some other filter package? come on, even hollywoodFX is better. should I buy another AMD64 or a dual opteron? WHY? to have those horrible and few EFFECTS in realtime? even kino FX looks better. in the comunity very cool people tried to explain me thos things, but they seems to be very focused in specific issues, and those BASIC things, are not important in this part of the coding process, and they told me those things are BUGs... really? bugs? or bad plannig, or even no global vision? who runs this project? I whould really love to know where cinelerra is going, perhaps, I´m totally mistaked, and cinelerra 3.0 is more flexible, with function curves, GREAT transitions, 3D effects, 3D camera Space, and GREAR FXs, and I will say wow, but really, Is that gonna happen someday? cinelerra 4,5, or 10? why some lone guy can create an OPENMOVIEEDITOR, and cinelerra after all this time, and the HD/SD/HDV, o maybe someday AVCHD and SFTUFF like that, can´t trim clips, or move to sinc editing with music beats, or export direcly to MPEG PS. Premiere, can export directly to DVD, wich KINO seems to achieve, but premiere creates the MENU, is that so hard to achieve? I can create in gimp GREAT templates If cinelerra coul do it, but still is a missing. someone shares my concern here? please I´m not trying to criticize any programmer´s job, just asking, is cinelerra going somewhere? if so... can anyone tell me where, and if there is some estimated time to RENDER, those improvements? when the rendering time is too long, I usually go somewhere else to do some other thing. I´m creating a weekly tv show and a documentary now in cinelerra... can other users tellme if I´m wrong? suddenly, 200 dollars for a 32 bit of MAINACTOR isn´t to much, but unfortunately mainactor is not in development anymore. I guess the PROFESSIONAL editing in linux with 64 bits platforms, was an advantage in the past, now the 64 bit systems are very common, and the renderfarm stuff seems expensive, and a space/energy waste too... now cinelerra is just ANOTHER 64 bit app, wich is not as usefull than the blender3D /sequencer , not so vaporware like jahshaka, or even so fragile as DIVA. should the professional be considering to buy a Apple/finalcut, or buy a cheap PC with Matrox RTx100? cinelerra has some surprises for the average editor? or still in the stoneAGE somehow? please, answer, I love cinelerra and saddly have to say that is getting FAR behind... very in the XX century. marquitux From: [EMAIL PROTECTED] Reply-To: cinelerra@skolelinux.no To: cinelerra@skolelinux.no Subject: Cinelerra digest, Vol 1 #1844 - 5 msgs Date: Tue, 14 Aug 2007 06:40:20 +0200 Send Cinelerra mailing list submissions to cinelerra@skolelinux.no To subscribe or unsubscribe via the WorldWide Web, visit https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Cinelerra digest... Today's Topics: 1. Re: I found a linux motion interpolator! :)) (Scott C. Frase) 2. Re: #cinelerra irc channel usage (Scott C. Frase) 3. Re: I found a linux motion interpolator! :)) (Graham Evans) 4. Re: I found a linux motion interpolator! :)) (Scott C. Frase) 5. Re: I found a linux motion interpolator! :)) (Edouard Chalaron) --__--__-- Message: 1 Subject: Re: [CinCVS] I found a linux motion interpolator! :)) From: Scott C. Frase [EMAIL PROTECTED] To: cinelerra@skolelinux.no Organization: CrazedMuleProductions.blogspot.com Date: Mon, 13 Aug 2007 21:24:05 -0400 Reply-To: cinelerra@skolelinux.no On Sun, 2007-08-12 at 13:14 +0800, Graham Evans wrote: Speed is not such an issue for me - many of Cinelerras effects are a long way from real time. That's what the background renderer is for. I use it all the time. I have a second networked computer running cinelerra to make it more effective. Hi Graham, I assume your second box is a node in a renderfarm, correct? If so, I'd like to hear about your farm setup (CPU speeds of primary farm
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
On Tue, 2007-08-14 at 02:29 -0300, marquitux caballero wrote: I guess the PROFESSIONAL editing in linux with 64 bits platforms, was an advantage in the past, now the 64 bit systems are very common, and the renderfarm stuff seems expensive, and a space/energy waste too... Not for image processing.
