[CinCVS] WHERE CINELERRA IS GOING? ...anyone?

[Roland]

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? proposal for CinelerraCV 2 maintenace

[Christian Thaeter]

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

Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace

[Christian Thaeter]

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

[Kevin Brosius]

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

[mark carter]

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.

What I'm saying is that in order for git to work, you have to have
separate subsytems - with well-defined interfaces, of course.

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. 


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?

[John Haiducek]

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

[Fred Williams]

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.



> 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? proposal for CinelerraCV 2 maintenace

[Mikko Huhtala]

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

[Christian Thaeter]

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?

[Christian Thaeter]

Mark Carter wrote:
> 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"
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?

[Mark Carter]

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?

[Christian Thaeter]

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] Concatenate tracks

[Martin Ellison]

I suppose the idea must be to take all your clips and make them into one
long movie in one click, presumably so you play through them and see what
you have. Never tried it though.

On 15/08/07, Raffaella Traniello <[EMAIL PROTECTED]> wrote:
>
> Hi all!
>
> Due probably to a sunstroke in this Italian summer, I decided to try the
> 'Concatenate tracks' operation from the 'Tracks' menu.
>
> Since I was not familiar with it, I read the manual:
> "Concatenate tracks is more complicated. It takes every playable track
> and concatenates it to the end of the first armed tracks. If there are
> two armed tracks followed by two playable tracks, the concatenate
> operation puts the two playable tracks after the two armed tracks. If
> there are three playable tracks instead, two tracks are put after the
> armed tracks and a third track is put on the end of the first armed
> track. The destination track wraps around until all the playable tracks
> are concatenated."
>
> It took me a *long* time to figure it out. (Please be surprised) ;-)
>
> I'm still quite perplexed. I wonder:
>
> - if I miss something
> - when I'm going to need this operation, in which context
> - if this operation actually affects tracks or rather assets (especially
> looking at its behaviour as insertion strategy)
> - if this is just a very particular kind of copy-and-paste operation
> - if this menu entry would be more appropriate in the Edit Menu
> - if the name 'Concatenate tracks' is misleading
> - if a plain 'Concatenate' could be a better name for this operation
> - if the Manual has been correctly modified
>
> So far I had never encountered in the Manual the concept of what I
> called 'set of tracks', meaning the group of tracks that contains an
> asset (e.g. one video track and two audio tracks  for a standard
> camcorder clip, two audio tracks for a standard audio clip, eccetera
> eccetera...). I think it is quite a basic concept during any Load
> operation.
>
> ... or is all this just a sunstroke effect? :-)
>
>
> Ciao!
> Raffaella
>
> 7.6 Manipulating tracks
> http://cvs.cinelerra.org/docs/cinelerra_cv_manual_en.html#SEC108
>
> Improving terminology
> http://cvs.cinelerra.org/docs/wiki/doku.php?id=improving_terminology
>
>
> ___
> Cinelerra mailing list
> Cinelerra@skolelinux.no
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>



-- 
Regards,
Martin
([EMAIL PROTECTED])
IT: http://methodsupport.com Personal: http://thereisnoend.org

[CinCVS] Concatenate tracks

[Raffaella Traniello]

Hi all!

Due probably to a sunstroke in this Italian summer, I decided to try the
'Concatenate tracks' operation from the 'Tracks' menu.

Since I was not familiar with it, I read the manual:
"Concatenate tracks is more complicated. It takes every playable track
and concatenates it to the end of the first armed tracks. If there are
two armed tracks followed by two playable tracks, the concatenate
operation puts the two playable tracks after the two armed tracks. If
there are three playable tracks instead, two tracks are put after the
armed tracks and a third track is put on the end of the first armed
track. The destination track wraps around until all the playable tracks
are concatenated."

It took me a *long* time to figure it out. (Please be surprised) ;-)

I'm still quite perplexed. I wonder:

- if I miss something
- when I'm going to need this operation, in which context
- if this operation actually affects tracks or rather assets (especially
looking at its behaviour as insertion strategy)
- if this is just a very particular kind of copy-and-paste operation
- if this menu entry would be more appropriate in the Edit Menu
- if the name 'Concatenate tracks' is misleading
- if a plain 'Concatenate' could be a better name for this operation
- if the Manual has been correctly modified

So far I had never encountered in the Manual the concept of what I
called 'set of tracks', meaning the group of tracks that contains an
asset (e.g. one video track and two audio tracks  for a standard
camcorder clip, two audio tracks for a standard audio clip, eccetera
eccetera...). I think it is quite a basic concept during any Load
operation. 

... or is all this just a sunstroke effect? :-)


Ciao!
Raffaella

7.6 Manipulating tracks
http://cvs.cinelerra.org/docs/cinelerra_cv_manual_en.html#SEC108

Improving terminology
http://cvs.cinelerra.org/docs/wiki/doku.php?id=improving_terminology


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?

[Gordon JC Pearce]

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]

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?

[Joey Richards]

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?

[Raffaella Traniello]

On Wed, 2007-08-15 at 00:21 +0200, Herman Robak wrote:
> So we will keep hearing complaints about the colours and the icons 
> until they become more in style with the flavour of the month.

That's what themes are for. Icons should change with the themes.

Ciao 
Raffaella






___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?

[Mark Carter]

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?

[Mark Carter]

> 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?

[Stefan de Konink]

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?

[Gordon JC Pearce]

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