[Lumiera] BJMR's GUI mockup/brainstorm

Ichthyostega prg at ichthyostega.de
Thu Jul 15 23:43:27 CEST 2010

Hash: SHA1

Hendrik Boom schrieb:
> I don't edit video, but my son Geoffrey has been doing it for almost two 
> years.  I showed him the mockups, and solicited his comments.  Here they are.

Hello Geoffrey,

thanks for taking a look and commenting.
Probably the main benefit of discussing such mockups is to help bringing
together the functionality (which is just emerging) with a consistent
"handling model" in the GUI, which we need to shape and define as we go.

> 1. all the tracks appear as the same size. this is good, because it's 
> appealing to the eye

good point. As we're going to have lots of possibilities to collapse and
expand things, we might want to aim at one special setting, where the
timeline contents are presented very reduced, clean and compact, as
a help when working with very large sessions.

> 2. The videos on the tracks should have thumbnails from the video itself.
Indeed, that's self evident.

While we're at this, I'd like to propose that we don't hard-wire this
clip presentation, but build it in a modular way, by having a "renderer",
which could be picked semi-automatically based on the kind of clip.

Especially, there are situations when you don't want any thumbnails.
Besides, we had the proposal to allow for an automatic visualisation based
on some properties of the clip (e.g. loud and noisy audio, vs. silent and
steady, athmo). We should also dispose of the silly habit of just showing
a waveform for each audio channel... do we want to end up with 5, 7, 9 or
26 audio waveforms?

Another possibility which fits in with having modular handling of the clip's
presentation is not to have a video *thumbnails strip*, but just to show
one distinctive *pivot frame* of a clip. It would be the editor's job to
/select/ that pivot frame, probably already while pre-selecting the
material, thereby creating kind of a "mental abbreviation" of a
whole scene.

> 3. this is the main important point i want to make. in this mockup, the video
> and audio seems to be put there in a total random order. it looks SUPER 
> confusing. the way sony vegas organizes the video files....

I really want to contradict you here. I see it as a primary concern
of any editor to keep an session ordered and systematic in some way
But this should be *the editors way*. Not the program should organise.

Thus, my aim is that Lumiera imposes no limitations here. Actually,
I'm going through some additional complexities below the hood to make
this happen. Especially, I *do not want hard wired audio tracks*
Or any hard wired typing of behaviour bound to the tracks.

Basically, when an clip contains multiple media streams, they are all
contained in this clip as a container. The system is able to figure
out the basic routing automatically. If the editor needs to treat
the directly attached audio separately, it can be split off into
a separate clip and placed appropriately (either independently or
still relative to the original clip)

> ... it puts all the video together in one group, and all the audio together, 
> this works very well because it doesn't look like a scrambled up mess.

It might look "organised", but actually starts getting into the way the
moment your session becomes more involved, e.g. on a music video. Especially
when your session doesn't fit on one screen vertically. IMHO when you're working
on an edit, tweaking and fine tuning it, it's much more important to have
related things close together, than to have things "ordered" by an abstract,
logical concept (like the stream type video or audio)

Hermann V.

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Lumiera mailing list