Re: Lumiera work-flow

_______________________________________________
Lumiera mailing list
Lumiera@...
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera

Re: Lumiera work-flow

tonsofpcs schrieb:
> Long time listener, first time caller!
Welcome to Lumiera!

> Anyway, after reading Nikola's post from 19 January, I wanted to add my 
> thoughts. Having ideas for the projects eventual goal is great, but be aware
> that you are trying to develop a workflow and interface that will work for 
> the simple user and the professional.
...
> I propose that instead of creating a simple workflow desirabilities document
> as you have begun, create a simple set of guidelines for requirements before
> the system is usable and the minimum workflow and interface requirements ...

While I agree with you on the goal, I actually think that it will help
us to start out with a single consistent workflow description as Nicola
started it. Because I think it's much more easy to reason and discuss
such a closed and consistent document, than it is to discuss open-ended
feature lists. Rather, I think we should then discuss this workflow and
build up those feature lists on the results of the discussion, which
includes ordering the features into urgent .... nice-to-have.

> Also, with the goal being a new editing system, I think the current 
> concentration should be on the editing backend -- where the magic happens,
Fully agreed, and actually that is what is happening right now.
The Lumiera project deliberately started to build up from the
technological core.

But this inadvertently bears the problem, that we might overlook the
final usage perspective. Thus, doing such a workflow discussion,
like as it was a parallel thread of thoughts and discussions,
seems a good approach for me.

Cheers,
Hermann Vosseler
(aka "Ichthyo")

Lumiera workflow and project targets and the like

Hi all.
I am a Fedora user since about RedHat4.
I originally stumbled across Lumiera on irc.
And then joined the mailing list to follow progress and perhaps later on
try to help out with some documentation.

I am not a programmer so I am not much use to you guys on a nuts and
bolts development front.
But could I say that from an end user point of view. It is almost
impossible to install "lumiera cinelerra" "heroine cinelerra" or "cvs
cinelerra" from source.

But the problem lies not so much with the "cinelerra stuff but with the
third party add-on stuff that is included.

Is there some way of making cinelerra less dependent on the included
bundles of third party stuff. by making the configure do more checks on
already installed software.And exclude anything that is installed from
the Makefile but link to the existing installed software. eg: I already
have the latest and greatest ffmpeg, mp3, quicktime etc, etc. And yet
cinelerra instists on installing it's own version in spite of and
sometimes to the detriment.

cinelerra in it's current form is reasonably stable and even use-able.
but you have to be a programer to install it (on Fedora anyway).

What I guess I am trying to say is Grab the latest stable snapshot and
iron out the wrinkles so that non programing dummies (like me) can
install it and use it. When we can use it we will flood you with ideas
and helpfull feature requests.

One other small glitch that is a big cause of crashes on Fedora in all
of the cinellera flavours is the dv1394 implementation. Fedora has now
stopped using the "/dev/dv1394" device but I can't quite figure out what
it is that they do use. I am sure that configure could be made check
this or over come it with flags for distros that covers those little
anomalies --with-redhat or --with-ubuntoo --with-debian --with-suse
which would have a list of the differences in these flavours and use
those settings to configure a sane makefile for that distro.( I thought
thats what configure was for anyway?)

If you are the first to make it sane for idiots like me to install, you
will gain a bigger cult following than any other piece of software in
the world.

Thats JMHO, Sometimes developers worry to much about the deeply
technical aspects of the software instead of getting it useable.

Regards,

Dave

Re: Lumiera work-flow

_______________________________________________
Lumiera mailing list
Lumiera@...
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera

Re: Lumiera workflow and project targets and the like

David Makin schrieb:
> I am a Fedora user since about RedHat4. I originally stumbled across Lumiera
> on irc. And then joined the mailing list to follow progress and perhaps later
> on try to help out with some documentation.
> 
> I am not a programmer so I am not much use to you guys on a nuts and bolts
> development front. But could I say that from an end user point of view. It is
> almost impossible to install "lumiera cinelerra" "heroine cinelerra" or "cvs 
> cinelerra" from source. But the problem lies not so much with the "cinelerra
> stuff but with the third party add-on stuff that is included.

Hi Dave,

generally I agree with you. I've spent quite some time getting
Cinelerra to compile -- and I am a developer.

Regarding Lumiera, I should point out that it is a separate project.
It is rooted in Cinelerra, yes, but we will do some things differently.
Also, the source code bases of both project have not much in common,
if at all. Initially, we wanted to rework parts of the Cinelerra source,
but ended up in building it new, but based on similar concepts.

Currently, for Lumiera there is nothing what an end user could install
and want to try out.

What you describe is the generally desirable state-of affairs for
package installation. Each program should just define its minimum
requirements and then "just work" for newer library versions.

But, while you can reach this goal for a simple text editor to quite
some extent, this is near to impossible, given the current state of
media applications. The libraries for manipulating media are by far
not mature enough to settle down upon. Many of them are quite bleeding
edge, and the stable versions are so outdated, with respect to the
supported media kinds and hardware, that no much people care to
maintain them. Media production is a niche, after all, and there
is a notorious lack of developer manpower in this area.

I can assure you that we are aware of the problem, and try to do
the best we can for Lumiera. But, I know this is nothing to help
with the current situation for Cinelerra, though.

Regards,
Hermann

Re: Lumiera work-flow

Hadi Khalifa schrieb:
> My Name Hadi A. Khalifa,

> Thank you for including me in your mailing list of the General Discussion
> about Lumiera, and I am very happy to be a part of the group.

> Fifth: I need some body to help me with the basic structure of the project
> when I run into some thing which I do not understand when reading the
> tutorial , I would apreciate it if some body recommend for me the best
> tutorial to get start helping with some tasks of programming  or in another
> words  do you have some guide lines for new commers for this project

Hello Hadi,

first of all: welcome to the Lumiera project!

Probably you've noticed that Lumiera is a comparatively young project;
while meanwhile there is quite a bunch of code and a lot of technical
specifications and documentation, all of this information is a bit
scattered and it's not easy to find the important parts.

Basically, this mailing list is a good place to ask questions. It is
intended for developers *and* prospective users, so both detailed
technical discussions, as well as questions regarding UI, workflow,
handling, possible strategies of the project as a whole are welcome
and encouraged.

Besides, for direct help with build problems or other specific questions,
or for just talking to us (core developers), you may want to join on IRC
#lumiera at freenode.net

From your description, I take it that you are at least in parts interested
in the programming and may want to help there. If so, a good near term goal
could be to familiarise yourself with the GIT version management system,
and to try to check out a copy of the current tree, exploring it a bit
and getting it to build and run on your system. There is a page describing
the necessary steps here:
http://www.pipapo.org/pipawiki/Lumiera/NewbiesTutorials

Probably, you've already seen the page  http://lumiera.org/development.html
The main entry points to the developer documentation are listed there at
the bottom. You'll find lots of informations there, so, just to pick some:

The "design process" with some proposals/drafts and decided items is here:
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess

Within the source tree, there is an embedded "TiddlyWiki" with very specific
technical documentation. I's also accessible online. For example

A large-scale Architecture overview is here
http://lumiera.org/wiki/index.html#ArchitectureOverview

And lots of detailed informations about the engine/session part is here
http://lumiera.org/wiki/renderengine.html

In the hope this helps you getting started...
Regards,
Hermann Vosseler
(aka "Ichthyo")

Re: Lumiera workflow and project targets and the like

Herman,
Thanks for that informative reply.
It is reassuring to know that you guys are mindfull of these problems.
And I look forward to beta testing in the near future.

Regards,
Dave

Lumiera Gui

_______________________________________________
Lumiera mailing list
Lumiera@...
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera

Re: Lumiera Gui

On Mon, 2009-02-02 at 14:34 +0100, palmito04 wrote:
> Hello.
> 
> My Inkscape is working for you  I have finished sketches for
> Lumiera gui&workflow and I have started writing gtkrc themes, infact I
> think Lumiera need custom colors, for example dark colors theme like
> Adobe Suite, probabilly a option tab is the way, something like this:
> Lumiera->Edit->Preference->ThemeTab->System theme/theme1/theme2/
> etc... I'm writing a dark theme and cinelerra (for nostalgic) theme
> based on Murrine Engine, if you are interesting I can post theme in
> beta version (dark theme is 90% complete and most usable on gnome). I
> need your comment for gui&workflow.
> 
> PS: open svg files with inscape otherwise you can not read all notes

Hi! Thanks for your design ideas. I'm responsible for the UI, so it's
really good to get different people's ideas to shape my thinking. I'm
particularly interested in your cut and trim idea - I think that would
work well. I think some of the need to be discussed a bit more, but many
of them are already planned, and some are even already implemented.

If you're interested in getting your ideas into Lumiera, I'd advise
breaking them down into simple elements that we can talk about one by
one on the mailing list or on IRC - the more participation the better. 

On the subject of gtkrc themes - I advise holding off for a little
while. Lumiera actually already has a dark theme - you may have seen the
screenshots. The theme values are very incomplete, and they're subject
to change, so if were to write one it may have to be completely
rewritten in a few months. Also, there's no way to choose themes yet.
When we get that done, it may be easier to experiment with different
styles.

All the best, and thanks for your SVGs
Joel

_______________________________________________
Lumiera mailing list
Lumiera@...
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera

Re: Lumiera work-flow

On Sun, Feb 01, 2009 at 08:17:02PM +0100, Ichthyostega wrote:
> tonsofpcs schrieb:
> > Long time listener, first time caller!
> Welcome to Lumiera!
> 
> > Anyway, after reading Nikola's post from 19 January, I wanted to add my 
> > thoughts. Having ideas for the projects eventual goal is great, but be aware
> > that you are trying to develop a workflow and interface that will work for 
> > the simple user and the professional.
> ...
> > I propose that instead of creating a simple workflow desirabilities document
> > as you have begun, create a simple set of guidelines for requirements before
> > the system is usable and the minimum workflow and interface requirements ...
> 
> While I agree with you on the goal, I actually think that it will help
> us to start out with a single consistent workflow description as Nicola
> started it. Because I think it's much more easy to reason and discuss
> such a closed and consistent document, than it is to discuss open-ended
> feature lists. Rather, I think we should then discuss this workflow and
> build up those feature lists on the results of the discussion, which
> includes ordering the features into urgent .... nice-to-have.
> 
> > Also, with the goal being a new editing system, I think the current 
> > concentration should be on the editing backend -- where the magic happens,
> Fully agreed, and actually that is what is happening right now.
> The Lumiera project deliberately started to build up from the
> technological core.

For that technological core, I believe you are using traditional 
programming langiages like C or C++ for low-level efficiancy at the cost 
of additional effort in debugging, and at the cost of potential unfound 
bugs that crash the editor.

Might it be worth suggesting that the UI(s) be built in an easier-to-use 
type-safe scripting language (such as python or some other) so that it's 
easier for users to change the UI to suit different workflow patterns 
without risking the integrity of the inner core of the system?

(Maybe Ruby or lua or some other so-called "scripting" language would be 
better; I don't know either well)

It's probably too late to suggest that the efficiency-critical 
core of Lumiera be written in a type-safe systems language (like Modula 
3) that greatly reduces the risks of obscure bugs and simplifies 
trasking them down.  Nor do I know whether the presence of a garbage 
collector in Modula 3 would compromise the real-time aspects of the 
application.  I do know Modula 3 supports multithreaded code.

-- hendrik