[Kdenlive-devel] Progress updates (was Re: GUI)

Rolf Dubitzky dubitzky at pktw06.phy.tu-dresden.de
Thu Jan 9 13:07:36 UTC 2003


On Thursday 09 January 2003 01:44 pm, Jason Wood wrote:
> However, I am not sure if perhaps <playing> is too specific a command. For
> example, we will need another command for <rendering> at least, but I am
> not sure if we will ever expect piave to play and render at the same time -
> I am suspecting that we won't. So perhaps a more general <position
> time=""/> command would be better? I am unsure.

Hmm.. I think it's better if the command is selfcontained. For the rendering 
we'll add another progress command.

> > and after the scene is played, I'll send:
> >
> >  <reply command="play" status="stopped" time="123.456"/>
>
> Here, I think it is more clear-cut. If you can consider that piave can be
> "playing", it can be "rendering", and it can be "stopped", I think a more
> general   <currentStatus status="stopped"/> might make sense.
>
> But maybe not, since I cannot think of a reason why piave might start
> playing or rendering without kdenlive telling it to.
>
> Perhaps the best reason for having a seperate statusChanged command is that
> the communication on the client side becomes cleaner - Instead of having to
> code "this is a reply to a play command, telling me it has finished", and
> "this is a reply to a render command, telling me it has finished", I would
> just have to code "Piave has finished whatever it was doing".
>
> What do you think?

Ok, I am not too happy wit this whole cummunication thing anyway, so I want to 
spend as few time on it as possible. I thought including a little redundancy 
would help, but if you want to rely on that you know what state piave is in, 
and what the "stop" is referring to, I am fine. On the other hand, the only 
case where this whole thing will make sense is when you have multiple hosts, 
and then you might get different answers from different hosts, well ... this 
is far away and not possible with the current system anyway.

> > Also play will start playing at a start point and till a stop:
> >
> >  <play speed="1.0" start="12.34" stop="23.45"/>
>
> Ok, a few default values that I think make sense :
>
> - If no start time is specified, piave should play from it's current seek
> position.

Or from 0.00. I don't care.

> - If no stop time is specified, piave should play until the end of it's
> scenelist.

ok.

> And keep in mind these use-cases that we might want to add later (I don't
> think they matter yet, but making sure that the VEML can handle them now
> means less work later):
>
> * The user wishes to play in a loop the entire scenelist, starting from the
> beginning.

ok. easy.

> * The user wishes to play in a loop the entire scenelist, but starts
> playing somewhere in the middle of the loop.

also easy.

> * The user wishes to play some section of the scenelist, starting from an
> arbitrary location (which may start before the looped section)
> For example on that last point : You have some intro footage before the
> main loop of footage. You want to check that the intro links seamlessly
> into the loop, and that the loop is seamless within itself. You haven't yet
> set this up on the timeline (I'm not sure how the looping of clips will
> work on the timeline yet, but it is planned functionality)

not as easy but straight forward. just send the apropriate play command and I 
implement the correct reactions.

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************






More information about the Kdenlive mailing list