On Wed, Mar 31, 2010 at 7:17 AM, Alberto Villa <avi...@freebsd.org> wrote: > imho - just imho, as a user - if i'm working with frames: > 1. i set N frames and i want them to be N forever. i don't want the program to > change them for me. if i want 2 seconds, i would work with timecode > 2. it's my responsibility to take care of this > > if something has to be done, i vote for adding a notice on profile changing. > there is already one if i remember correctly (that isn't really a suggested > operation): conditionally adding some text to that one would be trivial
You brought up a point which I hoped would be quietly swept under the rug :) I both agree and disagree with this. Typically, I don't want something I set to change automagically. In this case, however, I am curious whether the benefits of storing such a setting in a way that can be automatically adjusted for different frame rates outweighs the fact that the user would have to set the default setting again within the new project settings in order to achieve the desired results IF they care about the frame count more than the real time consumed by the default duration. IMO, I think most users will be more concerned with the real time than the frame count when switching between project formats. Personally I think the benefits outweigh the negatives. In the case of video, timecode and/or frame count is a count of time, relative to the time base of the video format. 50 frames in PAL has a longer duration, in real time, than 50 frames of NTSC video. If the 50 frames is stored in fractional seconds, then it will always be translated as 50 frames in PAL video, so in your typical working scenario, you will always have the 50 frame (2 second) duration that you want. If you switch to 24P or 60i, then the duration will remain 2 seconds and the frame count will adjust accordingly. Generally speaking, I agree with you and if I am working in a single project frame rate, then I want my 50 frames of video to always be exactly 50 frames. But when I look at the bigger picture, really what is more important to me is that in a PAL project my 50 frames be equivalent to 2 seconds of video. If I switch to NTSC at 30 fps, then I have to go and change the setting to 60 frames to get the same duration as I had in my PAL project. IMHO I would prefer my default value of 50 frames to equal 2 seconds in the PAL project, and to also equal 2 seconds in the NTSC project, even though the frame count will be different. Also, you can get in to trouble by just storing frames as the default duration. For example, in its default configuration, kdenlive ships with a default duration of I believe 5 seconds for the default Title duration. If this were stored in frames, then it would be 125 frames @ 25fps. However, if the user (such as myself) normally edits in NTSC, then I will probably switch to a default project setting with 30 or 60 fps video. At 30fps, the default 125 frame duration becomes 4.17 seconds, and at 60fps it becomes a mere 2.08 seconds. To the user, this will look like a bizarre default duration to have in a video application. If kdenlive stores either timecode OR frames, then it has to manage getting timecode for either type of value when the default setting is retrieved, which is easily doable but would perhaps make it more complicated than it is worth. Maybe one or two other people could chime in here with their opinions? 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
