On Wed, Mar 31, 2010 at 7:10 AM, Alberto Villa <avi...@freebsd.org> wrote: > > On Wednesday 31 March 2010 00:00:05 John T. Mertz wrote: > > I tried dolphin as you suggested but was only able to turn columns > > on/off, but I could not reorder them. > > that's strange, i'm able to do that
Maybe it is the version I am running? I only have dolphin installed because I installed KDE on top of Ubuntu 9.10, which installed Dolphin with it. But it's no matter since you know what I'm talking about. > > > For example, the default display might have these columns: > > Clip Name | IN | OUT | Start | End | Duration | Description > > > > But I might rearrange it to display in this order: > > Clip Name | Description | Duration | Start | End | IN | OUT > > what do you mean by IN and OUT? project clips in kdenlive don't have in and > out points... each item represents a whole clip 'IN' is called "Set Zone Start" in kdenlive 'OUT' is "Set Zone End" in kdenlive IN/OUT is standard terminology used by all NLE software. As a side note, kdenlive should really change from using "Zone Start/End" to the widely used standard "IN" and "OUT". The IN/OUT points on each clip are saved after you set them. Having the IN/OUT displayed in columns in the bin is useful because you can see where IN/OUT points are set on a clip (if they are set at all) without loading it into the clip monitor. > the same for Start and End: what are they? > this is just curiosity, it doesn't impact on this matter > Pretty much all video cameras embed a timecode track along with the video track. 'Start' and 'End' are the Start timecode and End timecode of the clip as defined by the clip's timecode track. I don't know if clip timecode is made available by any video playback/editing applications in Linux. I can't say I've ever seen a proper representation of timecode when playing any type of video format on linux. The start/end timecode provides the editor with a linear sequence of shots when editing, since the timecode for each clip progresses in a linear fashion. When each clip is recorded, its starting timecode value is (typically) the frame after the End Timecode value of the previous clip. Take, for example, a tape where the Start timecode of the tape is set to 01:00:00:00. Let's say you shoot three clips on the tape of varying durations. The timecode for each clip would be something like this: Clip1 StartTC 01:00:00:00 -> EndTC 01:01:34:23 Clip2 StartTC 01:01:34:24 -> EndTC 01:05:26:12 Clip3 StartTC 01:05:26:13 -> End TC 01:11:56:08 As you can see, it is easy to tell the order of the clips because the Start timecode increases with each new clip. A lot of professional videographers also use timecode to differentiate between different tapes. For example, they will set the camera to start recording on tape 1 with the timecode of 01:00:00:00, then tape 2 will start at 02:00:00:00, then tape 3 at 03:00:00:00 and so on. When they go to editing and capture all their media, they can easily determine which tape each clip came from based on the timecode. Start Timecode is usually retrieved from the timecode track of the captured clip. End Timecode, on the other hand, is usually calculated as the Start Timecode + Duration of the clip. This is because it is possible for clips to sometimes contain timecode breaks (for example, in one frame the timecode is 01:33:24:13, then the next frame following it the timecode might jump to 05:23:14:02). So most editing applications do not bother with displaying timecode breaks; rather, they just ignore them and calculate everything based on the Start TC. FYI. There are other uses for timecode as well, but I won't get into them all here. In any case, it is an important feature that kdenlive should (eventually) support if it wants to gain any traction in the prosumer video editing market. I have no idea how much metadata from captured clips is made available to the application, if any. > > Then, usually the user can save a custom Bin View so that depending on > > what they are working on, they can load different bin views which > > would reload the column display and order that was saved (although a > > single, customizable bin view would be an excellent start). > > ...and that could be made a little more powerful by allowing also other > things, e.g. icons size, icon view vs. detailed view... > Yes! I fully agree :o) Icon view, Icon size, detailed view is all important! Depending on your editing style or if you are looking for a certain clip, different views serve different purposes. > actually, i don't dislike this layout, it's very compact. but, following my > suggestion above, why not making different layouts available? > > anyway, could you please test the attached patch? it should unlock the > columns (and adding a voice to the header popup menu, but that's not the > point). it appears that i'm not able to make it work here, but according to > the documentation (i've spent some time on the qt website and through the > kdenlive source) and considering that it wouldn't be the first time that > something builds wrongly on freebsd - and, perhaps, ccache it's doing its own, > too - this doesn't work for me (while a stupid 4-lines examples does) > -- I will give it a try when I have a chance. Thanks! -JTM ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
