No subject


Thu Jul 8 23:16:46 CEST 2010


4. There should be an option to enable/disable audio sample level zoom
*>* and timecode.  There is usually no need for 'Sample Level Editing'
*>* (I'll call this SLE from now on) including sample level zoom and/or
*>* audio timecode display while cutting the video.  This is typically not
*>* necessary until the picture cut is finished, at which point audio
*>* editing would begin.  It would be highly beneficial to allow the user
*>* to turn SLE off and on so that this feature does not interfere while
*>* the editor is cutting the picture.
*>*
*>* Adobe Premiere Pro handles SLE in this fashion and it is very
*>* intuitive.  When SLE is disabled, zooming to 100% on the timeline
*>* brings the user to a video frame level zoom, the timecode displays in
*>* the typical "HH:MM:SS:FF" format, and the timeline indicator snaps to
*>* the head of each video frame and cannot be scrubbed freely between
*>* frames.  When SLE is enabled, the user can then zoom in to audio
*>* sample level, timecode is displayed with fractional seconds (similar
*>* to the current timecode display in the Lumiera GUI, although I believe
*>* APP displays it as "HH:MM:SS:FF.000" while Lumiera displays
*>* "HH:MM:SS.000"), and the timeline indicator can be scrubbed freely at
*>* the audio sample level.

*I believe the above is directly relevant to the TC widget, with our
additional comments.


B.J.M.R.


On Thu, Jul 8, 2010 at 2:16 PM, Brian Rytel <tesla.pictures at gmail.com>wrote:

> @Stefan, just checked ardour
>
> Having to click to TC widget 4 times to enter a TC location is maddening.
> Is there a way to have it take all the numbers entered and simply move them
> "over" to the next highest field?
>
> My non-programmers concept:
>
> 00:00:00:(00) <- I click here
> and input 1004
> the input dialog knows only (2) digits per dialog (as it does now),
> but rather than limiting further entry, it would pass (10) to the next
> dialog?
> You could daisy-chain this action for all digits, rather than write a new
> widget.
>
> I don't know how easy/logical that is in code, let me know...I should also
> note my described method is a convention in all professional NLEs, and
> should be considered carefully.
>
> While I don't intend to contradict any current design concepts, CT
> described the TC widget as primarily a display.
> In use, the TC counter(s) (as there are generally several) are there
> equally for entry & display, and have to effectively do both.
>
> B.J.M.R.
>
>
>
> On Thu, Jul 8, 2010 at 1:55 PM, Brian Rytel <tesla.pictures at gmail.com>wrote:
>
>> My above post is the "software-independent" way of describing this.
>>
>> However, none of this is all that directly related to the widget, which is
>> a front-end.
>>
>> I need to pop open ardour to see it's TC handling, give me a second.
>> B.J.M.R.
>>
>>
>>
>> On Thu, Jul 8, 2010 at 1:53 PM, Brian Rytel <tesla.pictures at gmail.com>wrote:
>>
>>> It should be clear that the following are separate functions and have to
>>> handled as such:
>>>
>>> Timestamp: The indicator (generally at the beginning) embedded into media
>>> to align with some outside media, ie: audio, simultaneous video, or a
>>> timecode param set for a production/project
>>>
>>> Framestamp: similar to above but per frame. If I'm not mistaken, I have
>>> seen these reference an absolute (clock), a relative (media file) and
>>> timecode.
>>>
>>> Framerate: The # of frames per second.
>>>
>>> Timecode: The constant 'time counter' for a timeline/sequence, or
>>> relevant to an individual clip. Timecode IS NOT FRAME-RATE! While it is
>>> generally related to frame rate, there is nothing stopping a produciton from
>>> putting 24fps footage on 30DF timecode, and it is done with some frequency
>>> (for various reasons). This means that timecode runs essentially arbitrary
>>> to the clips it serves. The hard part of course being that it must convert
>>> the entered ## to display a frame from the timeline.
>>>
>>> Example: NTSC standard-def footage is interlaced, which means you do not
>>> have 30fps but rather 60 half-frames/second. But the TC counter counts only
>>> to 30, in whole frame increments, while the footage is divided into
>>> 60-half-frame increments.
>>>
>>> Typing in 00:00:1:16 into a TC widget must translate that into the
>>> courser moving to 1 and 32/60 (because it's a 3fps TC) which actually leaves
>>> a problem because 32/60 of a sec is only one interlaced field, so using one
>>> deinterlace method or another the playback engine has to grab either another
>>> field (preferred), or it has to double the current field (not preferred).
>>> Further more, this has draw up the same fields/frames everytime the same TC
>>> is entered.
>>>
>>> I should note their are SMPTE standards for how to do all this.
>>>
>>>
>>> B.J.M.R.
>>>
>>>
>>>
>>> On Thu, Jul 8, 2010 at 10:05 AM, Burkhard Plaum <
>>> plaum at ipf.uni-stuttgart.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> Christian Thaeter schrieb:
>>>> [...]
>>>>
>>>>  yes indeed ... this was talking about (almost) constant framerates.
>>>>> Having a timestamp on each single frame is something different and
>>>>> might
>>>>> be supported in some different way (we where thinking about this
>>>>> before).
>>>>>
>>>>
>>>> Why not support them in the same way? All you need are functions for
>>>> converting framecounts to timestamps and back.
>>>>
>>>> I basically have this in gavl like explained here:
>>>>
>>>> http://hirntier.blogspot.com/2009/09/frame-tables.html
>>>>
>>>> It's generic code which works for arbitrarily variable framerates
>>>> and automatically reduces to trivial multiplications for constant
>>>> framerates.
>>>>
>>>>
>>>>  I actually leave this out from this discussion.
>>>>>
>>>>
>>>>  But more important here is, how would you represent this weird
>>>>> non-constant framerate things in the timeline widget? shall that only
>>>>> present frame number or absolute time and invalidate any representation
>>>>> which depends on a well defined framerate. Or try to map that back to
>>>>> some target framerate?
>>>>>
>>>>
>>>> Timeline in the GUI should of course be linear and if you zoom deep
>>>> enough to
>>>> see the thumbnails for single frames, they will be non-equidistant.
>>>>
>>>> Burkhard
>>>>
>>>> _______________________________________________
>>>> Lumiera mailing list
>>>> Lumiera at lists.lumiera.org
>>>> http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
>>>> http://lumiera.org/donations.html
>>>>
>>>
>>>
>>
>

--e0cb4e88745380891c048ae6e2da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<pre>From <a href=3D"http://lists.lumiera.org/pipermail/lumiera/2009-May/00=
0938.html">http://lists.lumiera.org/pipermail/lumiera/2009-May/000938.html<=
/a><i><br><br>4. There should be an option to enable/disable audio sample l=
evel zoom<br>
</i>&gt;<i> and timecode.  There is usually no need for &#39;Sample Level E=
diting&#39;<br></i>&gt;<i> (I&#39;ll call this SLE from now on) including s=
ample level zoom and/or<br></i>&gt;<i> audio timecode display while cutting=
 the video.  This is typically not<br>
</i>&gt;<i> necessary until the picture cut is finished, at which point aud=
io<br></i>&gt;<i> editing would begin.  It would be highly beneficial to al=
low the user<br></i>&gt;<i> to turn SLE off and on so that this feature doe=
s not interfere while<br>
</i>&gt;<i> the editor is cutting the picture.<br></i>&gt;<i> <br></i>&gt;<=
i> Adobe Premiere Pro handles SLE in this fashion and it is very<br></i>&gt=
;<i> intuitive.  When SLE is disabled, zooming to 100% on the timeline<br>
</i>&gt;<i> brings the user to a video frame level zoom, the timecode displ=
ays in<br></i>&gt;<i> the typical &quot;HH:MM:SS:FF&quot; format, and the t=
imeline indicator snaps to<br></i>&gt;<i> the head of each video frame and =
cannot be scrubbed freely between<br>
</i>&gt;<i> frames.  When SLE is enabled, the user can then zoom in to audi=
o<br></i>&gt;<i> sample level, timecode is displayed with fractional second=
s (similar<br></i>&gt;<i> to the current timecode display in the Lumiera GU=
I, although I believe<br>
</i>&gt;<i> APP displays it as &quot;HH:MM:SS:FF.000&quot; while Lumiera di=
splays<br></i>&gt;<i> &quot;HH:MM:SS.000&quot;), and the timeline indicator=
 can be scrubbed freely at<br></i>&gt;<i> the audio sample level.<br><br>
</i><font face=3D"arial,helvetica,sans-serif"><font size=3D"2">I believe th=
e above is directly relevant to the TC widget, with our additional comments=
.</font></font><br></pre><br clear=3D"all">B.J.M.R.<br>
<br><br><div class=3D"gmail_quote">On Thu, Jul 8, 2010 at 2:16 PM, Brian Ry=
tel <span dir=3D"ltr">&lt;<a href=3D"mailto:tesla.pictures at gmail.com">tesla=
.pictures at gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204=
, 204); padding-left: 1ex;">
@Stefan, just checked ardour<br><br>Having to click to TC widget 4 times to=
 enter a TC location is maddening. Is there a way to have it take all the n=
umbers entered and simply move them &quot;over&quot; to the next highest fi=
eld? <br>

<br>My non-programmers concept:<br><br>00:00:00:(00) &lt;- I click here<br>=
and input 1004<br>the input dialog knows only (2) digits per dialog (as it =
does now), <br>but rather than limiting further entry, it would pass (10) t=
o the next dialog?<br>

You could daisy-chain this action for all digits, rather than write a new w=
idget.<br><br>I don&#39;t know how easy/logical that is in code, let me kno=
w...I should also note my described method is a convention in all professio=
nal NLEs, and should be considered carefully.<br>

<br>While I don&#39;t intend to contradict any current design concepts, CT =
described the TC widget as primarily a display.<br>In use, the TC counter(s=
) (as there are generally several) are there equally for entry &amp; displa=
y, and have to effectively do both.<br>

<br clear=3D"all">B.J.M.R.<div><div></div><div class=3D"h5"><br>
<br><br><div class=3D"gmail_quote">On Thu, Jul 8, 2010 at 1:55 PM, Brian Ry=
tel <span dir=3D"ltr">&lt;<a href=3D"mailto:tesla.pictures at gmail.com" targe=
t=3D"_blank">tesla.pictures at gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;">

My above post is the &quot;software-independent&quot; way of describing thi=
s.<br><br>However, none of this is all that directly related to the widget,=
 which is a front-end.<br><br>I need to pop open ardour to see it&#39;s TC =
handling, give me a second.<br clear=3D"all">


B.J.M.R.<div><div></div><div><br>
<br><br><div class=3D"gmail_quote">On Thu, Jul 8, 2010 at 1:53 PM, Brian Ry=
tel <span dir=3D"ltr">&lt;<a href=3D"mailto:tesla.pictures at gmail.com" targe=
t=3D"_blank">tesla.pictures at gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;">


It should be clear that the following are separate functions and have to ha=
ndled as such:<br><br>Timestamp: The indicator (generally at the beginning)=
 embedded into media to align with some outside media, ie: audio, simultane=
ous video, or a timecode param set for a production/project<br>



<br>Framestamp: similar to above but per frame. If I&#39;m not mistaken, I =
have seen these reference an absolute (clock), a relative (media file) and =
timecode.<br><br>Framerate: The # of frames per second.<br><br>Timecode: Th=
e constant &#39;time counter&#39; for a timeline/sequence, or relevant to a=
n individual clip. Timecode IS NOT FRAME-RATE! While it is generally relate=
d to frame rate, there is nothing stopping a produciton from putting 24fps =
footage on 30DF timecode, and it is done with some frequency (for various r=
easons). This means that timecode runs essentially arbitrary to the clips i=
t serves. The hard part of course being that it must convert the entered ##=
 to display a frame from the timeline.<br>



<br>Example: NTSC standard-def footage is interlaced, which means you do no=
t have 30fps but rather 60 half-frames/second. But the TC counter counts on=
ly to 30, in whole frame increments, while the footage is divided into 60-h=
alf-frame increments.<br>



<br>Typing in 00:00:1:16 into a TC widget must translate that into the cour=
ser moving to 1 and 32/60 (because it&#39;s a 3fps TC) which actually leave=
s a problem because 32/60 of a sec is only one interlaced field, so using o=
ne deinterlace method or another the playback engine has to grab either ano=
ther field (preferred), or it has to double the current field (not preferre=
d). Further more, this has draw up the same fields/frames everytime the sam=
e TC is entered.<br>



<br>I should note their are SMPTE standards for how to do all this.<br><br>=
<br clear=3D"all">B.J.M.R.<div><div></div><div><br>
<br><br><div class=3D"gmail_quote">On Thu, Jul 8, 2010 at 10:05 AM, Burkhar=
d Plaum <span dir=3D"ltr">&lt;<a href=3D"mailto:plaum at ipf.uni-stuttgart.de"=
 target=3D"_blank">plaum at ipf.uni-stuttgart.de</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



Hi,<br>
<br>
Christian Thaeter schrieb:<br>
[...]<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
yes indeed ... this was talking about (almost) constant framerates.<br>
Having a timestamp on each single frame is something different and might<br=
>
be supported in some different way (we where thinking about this<br>
before). <br>
</blockquote>
<br></div>
Why not support them in the same way? All you need are functions for<br>
converting framecounts to timestamps and back.<br>
<br>
I basically have this in gavl like explained here:<br>
<br>
<a href=3D"http://hirntier.blogspot.com/2009/09/frame-tables.html" target=
=3D"_blank">http://hirntier.blogspot.com/2009/09/frame-tables.html</a><br>
<br>
It&#39;s generic code which works for arbitrarily variable framerates<br>
and automatically reduces to trivial multiplications for constant<br>
framerates.<div><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I actually leave this out from this discussion.<br>
</blockquote>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
But more important here is, how would you represent this weird<br>
non-constant framerate things in the timeline widget? shall that only<br>
present frame number or absolute time and invalidate any representation<br>
which depends on a well defined framerate. Or try to map that back to<br>
some target framerate?<br>
</blockquote>
<br></div>
Timeline in the GUI should of course be linear and if you zoom deep enough =
to<br>
see the thumbnails for single frames, they will be non-equidistant.<br><fon=
t color=3D"#888888">
<br>
Burkhard</font><div><div></div><div><br>
_______________________________________________<br>
Lumiera mailing list<br>
<a href=3D"mailto:Lumiera at lists.lumiera.org" target=3D"_blank">Lumiera at list=
s.lumiera.org</a><br>
<a href=3D"http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera" targe=
t=3D"_blank">http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera</a><=
br>
<a href=3D"http://lumiera.org/donations.html" target=3D"_blank">http://lumi=
era.org/donations.html</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>

--e0cb4e88745380891c048ae6e2da--


More information about the Lumiera mailing list