Re: [Savonet-users] transition on input.harbor

[James M. <jam...@so...>]

Any update on this??
Thanks!!

On Sat, Mar 10, 2012 at 7:46 PM, Romain Beauxis <to...@ra...>wrote:

> Hey,
>
> 2012/3/9 David Baelde <dav...@gm...>:
> > I'd like to clarify one thing: there is never any (clock) problem with
> > switch-based transitions. It's only cross-transitions (between tracks
> > of the same source) that you should avoid with real time sources (we
> > decided against this so far, but strict clock annotations would
> > prevent such uses).
> >
> > Regarding the initial problem, I'm not sure what it was, maybe bad
> > remaining time estimations. I'm more puzzled by the intermediate
> > report of liquidsoap going into a loop with a sequence transitions.
>
> It would be nice to investigate on those too indeed.
>
> > Finally, the override parameter did not make sense in
> > fade.initial/final(), only in fade.in/out() <http://fade.in/out%28%29>.
> It is there to change the
> > fading duration from one track to the next. This is useless for
> > track.initial/final() because they fade only once, not for every
> > track. (Strictly speaking, it could still be nice to use a duration
> > extracted from the track, and technically there may be a way that even
> > initial/final extract it before starting their work, but I'm not
> > sure.) Your use of references for setting fading durations seems like
> > the right approach to me.
>
> Thanks. It makes sense to not have metadata override for
> fade.intial/fade.final. However, I think that the problem here is that
> those fade operators actually are overriden by those metadata..
>
> Romain
>



-- 
James Moon
 Software Developer, Sourcefabric
jam...@so...

www.sourcefabric.com | *www.sourcefabric.org*

720 Bathurst St. Suite 203
M5S 2R4, Toronto, ON, Canada