Hi guys, 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. Finally, the override parameter did not make sense in fade.initial/final(), only in fade.in/out(). 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. What exactly are you trying to achieve with these annotations? Cheers, -- David ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
