headers
Thorsten Wilms | 1 Nov 10:58
Picon
Favicon

Re: Finding good terms...: the EDL

On Thu, 2008-10-30 at 22:46 +0100, Ichthyostega wrote:

>  * the *Session* is the collection of all things the user is working on,
>    it contains all informations, state and objects to be edited. From a
>    users POV, the Session is synonymous to the current Project. It can
>    be saved and loaded.

While "Session" is used by other applications in this way, I think if
you forget about those examples, the word suggests that it is about
something that happens in one go. So I think "Project" is the better
term.

>  * we used the term *Timeline* mostly in an informal manner, but
>    seemingly rather to denote the /timeline view/ in the GUI, i.e.
>    a collection of objects which can be manipulated, and which are
>    arranged on tracks and along a time beam with the possiblility to
>    "play"/"render" the result. Note the consequences of this definition:
>    - we can create multiple views of the same timeline
>    - we can create several independent timelines within the same project

Whenever a view or viewer-window is meant, one should say so.

> Obviously, this thing labeled "EDL" is no longer "our Edit Deicsion
> List"; rather such has to be created by a special export function.
> Relating it to physics, there can be only one single timeline because
> there is only one time. The same is true for the final movie, but
> creating such a coherent timing and rhythm is just what's at the core
> of the work we call "editing", and if you are into SciFi or relativity,
> you know there can be multiple timelines. ;-)
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
Thorsten Wilms | 1 Nov 11:19
Picon
Favicon

Re: Finding good terms...: markers, ranges and selections

On Thu, 2008-10-30 at 22:47 +0100, Ichthyostega wrote:

>  * while typically being used to tag or describe another thing,
>    a *label* can also stick to a certain time position on the
>    timeline ruler. Cinelerra uses the term this way, and
>    up to now I stuck to this usage within the codebase, i.e.
>    there is a class "Label"

I think Label should only be used for a snippet of information that you
attach to an object.

>  * probably it should be better called a *marker*, because it
>    is used to mark a point for later reference.

Label + position = marker?

>  * when working with media, there is the common need to mark
>    a time range, i.e. a *range marker*. These should be
>    persistent and groupable.

Markers that are not Range Markers can be called Location Markers.

>  * usually, there are some special range selections which
>    typically are treated separately, like the *loop range*,
>    the *punch range*, the *clip range* (as defined by in/out
>    point) and some sort of output or *render range*

While being able to create such special ranges directly can speed things
up, I think it should generally be possible to turn any range into a
loop or punch range (or loop AND punch range).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thorsten Wilms | 1 Nov 12:10
Picon
Favicon

Re: Usage scenarios

On Fri, 2008-10-31 at 07:17 +0100, Ichthyostega wrote:

> http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UseCases

I wanted to add this to the wiki:

Scenario (8) : Teamwork

Several people work on a project.

    * A longer sequence might be split up into parts, each one edited by
another person. The parts will be collected and assembled by the chief
editor. Edits to the parts will still be possible, but a system of
permissions allows to lock down access to the material.
    * Arrangements based on the same resources can be branched, tagged
and merged.
    * Edits are logged with usernames
    * Markers can be shown/hidden on a per creator base.
    * Team members need ways to share and store notes and suggestion for
each other work. Annotations can be added to clips, markers or
arrangements
    * A pen tool could allow to scribble on top of frames or
arrangements. An expressive and fast way to leave suggestions about
deletions, movements and all other kinds of edits.

Even though I notice it became a bit of a feature list.
I always run into a ConvertError and can't be bothered to report a bug
right now for such a straightforward task.

--

--
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kurt Georg Hooss | 1 Nov 14:42
Picon

Re: Finding terms: Marks


i would appreciate a distinction between (at least) two kinds of marks:
marks that stick to one clip / take / edit (and move with it)
and marks that stick to the timeline, independent of media material.

see what i mean?
don't quite know how to term these, though.
georg

--

-- 
Dr.Kurt Georg Hooss
Schoepfung & Wandel wissenschaftliche Medienberatung
Breite Strasse 6-8, D-23552 Luebeck
Fon +49-(0)451-3003-474 (Fax -333)
www.kurts-film.de
Permalink | Reply | 1 comment |
headers
Ichthyostega | 1 Nov 20:25
Picon

Re: Finding good terms...: the EDL


> On Thu, 2008-10-30 at 22:46 +0100, Ichthyostega wrote:
>> Obviously, this thing labeled "EDL" is no longer "our Edit Deicsion
>>  List"; rather such has to be created by a special export function.
...
>> 
>> Maybe "Sequence" would be a good term? What is your opinion?

Thorsten Wilms schrieb:
> There can only be one final resulting timeline for one export stream,
>  but I see no problem with calling several parts timelines.
> 
> I suggest to use "Sequence" for a chain of clips (or possibly just 
> one clip) one a single track.
> 
> The combination of Sequences on several tracks could be called an 
> Arrangement. With nesting, you could talk about Sub-Arrangements to 
> make clear that you are not referring to the top level, which would 
> be the Root or Main Arrangement.

oh thanks, this comment had an really enlightening effect for me!

Consider the following. What we called "EDL" up to now in our
design/draft, is a collection of objects placed to a tree of tracks
(and these tracks are a merely organisational vehicle)

What you call here "Arrangement" would be the closest match. It would
be also very close to the proposed Container Concept, i.e. a lightweight
compound of pre-arranged objects
(Continue reading)

Permalink | Reply | 9 comments |
headers
Kurt Georg Hooss | 2 Nov 03:04
Picon

Re: Finding good terms...: the EDL


o.k. i like the reasoning.
however as an outsider to coding, i am not so sure
wether this thing now called EDL is still a list of edit decisions...

in cinelerra, sure the xml code is pretty much exactly that.
it would make sense to me that each timeline is described
by its corresponding EDL, maybe xml or some other format.

and if there is a master timeline then there would be a master EDL.
some of the edit decisions taken in the list could then be
references to #include other (sub-) timelines. did i get your idea?

> I suggest to use "Sequence" for a chain of clips (or possibly just
> one clip) one a single track.
>
> The combination of Sequences on several tracks could be called an
> Arrangement.

hm... what about camera takes
consisting of one video and two audio tracks?
are these sequences or arrangements?
usually they don't need to be arranged.

On Saturday 01 November 2008 20:25:41 Ichthyostega wrote:
> > On Thu, 2008-10-30 at 22:46 +0100, Ichthyostega wrote:
> >> Obviously, this thing labeled "EDL" is no longer "our Edit Deicsion
> >>  List"; rather such has to be created by a special export function.
>
> ...
(Continue reading)

Permalink | Reply | 8 comments |
headers
Raffaella Traniello | 2 Nov 11:22
Picon

Re: Finding good terms...: the EDL

On Sun, 2008-11-02 at 03:04 +0100, Kurt Georg Hooss wrote:

> hm... what about camera takes
> consisting of one video and two audio tracks?
> are these sequences or arrangements?
> usually they don't need to be arranged.

In my workflow I arrange them very often.
I'd call them 'default arrangements'.

Ciao!
Raffa

PS: I'm in love with this thread. Language is built on ideas. The
inconsistency language is a heavy weakness in Cinelerra .
I believe in Lumiera because I see you always nurture the foundation
first (not only the code foundation but also the ideas, the language,
the development model).
Long life to Lumiera! :-)
Permalink | Reply | 4 comments |
headers
Kurt Georg Hooss | 2 Nov 23:01
Picon

Re: Finding good terms...: the EDL


thanks raffa, for comment and confirmation.

...well OK it makes sense to call it "arrangement"
after it has been re-arranged... but if we talk about
default-synchronous raw material captured from camera...

it is most natural to term one such piece of data as a "take"
(even if, of course, one could formally insist on its being pre-arranged
by camera or software, be it while filming or through capture).

even after re-arranging (i.e. separating audio from video),
still, in most cases, stereo audio will be kept intact
with two tracks making up one audio take.

for coding, strict language is crucial. however as an editor,
i would rather live with the ambiguity of the term "take" denoting
either just one stream on one track, or several synchronous streams.

that would leave us free to have clips containing several takes
and also other clips, as has been suggested.
a minimal clip could contain just one image frame.

georg

On Sunday 02 November 2008 11:22:25 you wrote:
> On Sun, 2008-11-02 at 03:04 +0100, Kurt Georg Hooss wrote:
> > hm... what about camera takes
> > consisting of one video and two audio tracks?
> > are these sequences or arrangements?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Thaeter | 2 Nov 23:08

Re: Usage scenarios

Thorsten Wilms wrote:
> On Fri, 2008-10-31 at 07:17 +0100, Ichthyostega wrote:
> 
>> http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UseCases
> 
> I wanted to add this to the wiki:
> 
> Scenario (8) : Teamwork
> 
> Several people work on a project.
> 
>     * A longer sequence might be split up into parts, each one edited by
> another person. The parts will be collected and assembled by the chief
> editor. Edits to the parts will still be possible, but a system of
> permissions allows to lock down access to the material.

I'd like to see that implemented as selecting parts and turning them to
subprojects which can be passed around. Permissions should be the unix
permissions, maybe we offer some way to manage them but it makes no
sense to reinvent such a system nor would it be very secure with people
have local access to the machine (in contrast to web apps).

>     * Arrangements based on the same resources can be branched, tagged
> and merged.
maybe plaintext (or XML) export? then using any revision control system
like git.

I am reluctant to invent features from which I know others can do them
better than we could ever do. Sometimes just a UI to access them would
be the better way.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ichthyostega | 2 Nov 23:33
Picon

Re: Usage scenarios


> Thorsten Wilms wrote:
>> * Arrangements based on the same resources can be branched, tagged
>>  and merged.
Christian Thaeter schrieb:
> maybe plaintext (or XML) export? then using any revision control 
> system like git. I am reluctant to invent features from which I know 
> others can do them better than we could ever do. Sometimes just a UI 
> to access them would be the better way.

Agreed. If we aren't careful we duplicate many services which are
already present (and working reliable) on the OS level. Thus, maybe
for such "distributed projects", a mechanism to export parts and to
re-integrate them together with a some "rights descriptor" would be a
solution.

>> * Team members need ways to share and store notes and suggestion 
>> for each other work. Annotations can be added to clips, markers or
>>  arrangements
> 
> Some time ago I proposed a first class text track, for annotations, 
> as teleprompter or as source for titeling/subtitleing.
> 
> Many other objects will get a generic 'metadata' system which lets 
> one attach data to every frame. This can easily handle text notes 
> too.

I am thinking in a similar direction. My stream type system was done
with this usecase in mind: it should be possible to add a text
(document) media type via plug-in.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane