Hi, Just a few quick notes..
Ah ha! Implementation, It's nothing that I've spent a great deal of time on since I'm more concerned at the moment of getting some good gui components together.
I will insist on the implementation and I believe it is important to keep that in mind a bit. Liquidsoap has a very specific design which allowed for great flexibility for the user and great modularity for the devs. However, this has a price: the power of our scripts means that their behaviour is not easy to predict without running it -- that may remind you of the halting problem.
ideal feature would be able to pipe out the output stream to the DJ's desk, so they know whats going out.
If the output is streaming to icecast, then is feasible to get the server/mount information for it and stream the data from icecast. But there will be a lag. A lower latency solution could be possible, but only for low-latency outputs (our experimental rtp or its successor) which have explicitely been added in the liquidsoap script. If the node is not in the script, the feature won't be there. Also, it is not trivial to know that two outputs are actually streaming the same content.
Amber - Available but Blank
Currently, you can know whether or not a stream is blank, but not from the output nodes. These don't compute this data, and won't know it if it's computed by one of our *blank() nodes. Of course we can perform changes (like adding a server command to some of the *blank() operators so that they advertise the current blank/not-blank status of the stream) but keep in mind that some things will remain difficult in our model (even if you have blank computation nodes, it won't be trivial to know that they work on the stream which is output by a given output node).
The other main part of the status is 'What's next?', this can then let
I'm worried by what you mean here: do you intend to display information about the next song to be played ? It is currently difficult to know without inspecting the script: you have to examine which nodes are on the road from the output to the sources, and the switches on this road might have a behaviour which is difficult to guess in general. However, in many cases, you know that what's next should be the next file in a playlist, which you can get from liquidsoap. But if there is a jingle insertion based on random(), it becomes difficult to predict when it will be triggered. I hope that I didn't discourage you with all these remarks. I just wanted to make sure that you know enough of the tool that you are interfacing with. Cheers! -- David
