Hi Normando,
In a sense you can already do this, and in another sense you will
never be able to do it... Liquidsoap is really something interactive,
this is what gives you so much liberty, but everything has a price: We
let you write any predicate in a switch, but as a result we can't do
anything else than running this predicate. In particular, we can't
guess when the predicate will be true or not. There are many more
examples like that.
So, we have to run the stream to know what it does. But this is good
enough in many situations. It is possible to run your stream really
fast: first remove the synchronization on your clocks (in old
liquidsoap, set("root.sync",false), and in new ones, wrap outputs in
clock(sync=false,...)) and second, change your outputs for
output.dummy so that you avoid encoding. Now you have a stream that
goes as fast as your CPU can, and that you be plenty enough for
testing. A few pitfalls: obviously, it won't work if your script
relies on a soundcard input or output, or an external stream
(input.harbor/http).
Finally, a problem that might matter for you: several components in
the script (including external scripts) may rely on the "real" time
(i.e. the time given by your computer's clock) and that time won't be
accelerated when we accelerate liquidsoap's clocks. I don't think
there is a unique answer to that difficulty, but solutions could
involve computing a simulated time based on the date of liquidsoap's
startup and the current time in liquidsoap's clock (which you can get
using get_clock_status).
On Tue, Dec 14, 2010 at 11:02 PM, Normando Hall <[email protected]> wrote:
> 10:00:00 - song1 (duration 2:01)
> 10:02:01 - song3 (duration...)
For getting the actual output in the form that you want, simply use a
couple on_metadata. You can use a global "debug" variable in your
script to enable disable easily all those mechanisms.
I don't really know how to conclude: All this probably looks like too
much pain for a simple test. In particular, it would be nice to have a
simple solution to the problem of accelerating the "real" time, or at
least tools to deal with it. On the other hand, I'm not sure how
useful it'd be to work on improving testing because it'll never work
for bigger systems, and on simple cases like the one you mention it
has only a limited interest: hopefully, you'll quickly come to trust
what you write using playlists and switches (transitions are another
story, but require a different testing approach in my opinion).
Cheers,
--
David
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
