On Thu, 19 Jan 2006 23:42:34 +0100, Andraz Tori <[EMAIL PROTECTED]> wrote:

On čet, 2006-01-19 at 22:57 +0100, Herman Robak wrote:

- He wants as much as possible to appear in a suitable way for PAL
resolution.  For the _PAL_ tracks that he has already loaded, it makes
sense to show them in _PAL_ resolution, that is in the project canvas
size.  No black bars.  No need to fiddle with right-click menus on
each and every track afterwards.
  That is what most users likely want in that scenario.  Can you come
up with common counter-examples?

Yeah, track size is more or less independant of the project size, there
are many uses where you want track size completely different than
project size - especially when doing compositing.

 Yes, that is true.  I am not suggesting stretching here (Cinelerra
does not do that automatically anyway, does it?), just that the
track is not masked to the previous project size.

 And that brings us to the failing of the track size model, I think:
If the track size has not been touched by the user, the track size
should be the size of the asset (the source video) or the size of
project, whichever is the smaller.  No size should be stored until
the user actively sets it.  Until then, it should be read from the
source, or from the project size.  For all tracks whose sources
were larger than the current project size, the track size would
automatically change when a new project size was set.

I believe that proposal is much closer to "do what I mean" than
the current behaviour.


Therefore you can not know what the user wants.

 But you can know what _most_ users want.  And I think that they
don't want the PAL track to be masked down to 480 lines after
they changed the project size to 576 lines.

--
Herman Robak

_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to