Hi,
I hope we understand and fix that bug soon. For now, I can answer your
other question.
On 4/30/06, Xavier Cazin <[EMAIL PROTECTED]> wrote:
By the way, if I understand well, this trick wouldn't work if you have
in your "clock" playlist both sounds lasting less and sounds lasting
more than the delay you're asking for.
Indeed, there would be a problem with long tracks, since the schedule
node would declare itself as not being ready anymore when "0m & 0-5s"
is false -- you might actually be lucky and avoid that problem if the
operator on top of schedule keeps asking for frames without noticing
the status change, it can happen, I don't know if I should tighten the
policy here, but that's not the question.
Another problem with that trick is when the delay between two
scheduling periods is less than the duration of the period itself. But
that's probably less frequently annoying.
For instance, I would like to
be able to play announcements of our next live sessions, every two
hours. Depending of the session, the ad would last anything between 10
seconds and 30 seconds. Also, some days, we want to air interviews of
arbitrary people answering an arbitrary question. Here too, we don't
want to constrain the duration in advance. Could you suggest another
trick that would work in this cases?
We should definitely find something better than this trick, for
scripts using add(..clock) as well as needs like yours. I don't think
you can do with the current set of operators.
It is possible to write a function which takes a source S and returns
a source playing only the first track of S: once = fun (s) ->
sequence([s,fallback([])]). But once(clock) would have to be
regenerated to be able to play another track, which schedule doesn't
do. A possible extension would thus be to make a more dynamic
operator, which would create its source child when selecting a branch:
dynamic_select([("0m&0-5s", fun () -> once(clock))]). It could be
done, but that's not very satisfying, and the implementation would
imply code duplication.
Another solution: add a not_twice parameter to schedule (I don't think
other switch operators need it) which forbids the selection of the
same branch twice. It sounds better.
What do you think ? Other ideas ?
--
David
