Hi devs, It looks like I don't want to sleep tonight, which leaves plenty of time for writing down a few things on liquidsoap, relating discussions that we had this week-end. I'll try to sort that out for the record, and maybe present my view on the recent and upcoming evolutions..
On Saturday, we had two "meetings". Clement, Romain, Samuel, Stephane, Vincent and myself first met in order to discuss our future goals. It makes no doubt that we want to handle more stream formats. The long term idea would be to handle video too, but even before that, we need to really handle more audio formats (mono, stereo, dolby-thingy, etc.) Also, I believe that localizing the format on sources will make the code much cleaner. The first thing to do here is to add (bounded) polymorphism to our script language. This is a nice thing in itself and it should allow us to simplify a few operators and support limited overloading by the way. We also agreed that there didn't seem to be any reasonable way to statically enforce the infallibility conditions on sources. It seemed simpler to remove that constraint and have the outputs support failure. It might also be a step towards "finite" usages of liquidsoap: run only for outputting one (or N) tracks. And the newcomers will be happy to see the section on infallibility disappear from the doc. During this first discussion Sam pushed for more dynamic features in the language. In the end, his wish turned out to be "turn everything into a stream". This is similar to what is done in Chuck (http://chuck.cs.princeton.edu/) or Esterel (http://www-sop.inria.fr/meije/esterel/esterel-eng.html). The constant 42 would actually represent a stream of integers 42, the sqrt() function would be a stream transformer, etc. From the implementation point of view, it means that all these streams and functions would have to register and handle caching and synchronizations in the same way that sources do currently. It raises a bunch of tricky questions. It seems like an elegant unification of concepts, but I doubt that we could change sources into actual streams of samples. Even without thinking about the efficiency, we'd loose the notion of track, and the possibility of unavailabile sources.. and by the way, what the meaning of the stream "rms(s)" when the source "s" is not available? Do we have to handle failures for any kind of stream ? Should we still have functions, or rather streams of functions ? What's the meaning of commands like system(), log().. ? Romain did not have much time left for discussing about the next release. Basically, the doc is still not ready for the release (LiqSettings is outdated), and the wiki2tex script doesn't support images. The good news is that I changed my mind about the release: there is a long way before getting the new features discussed here, so I believe again that we should release now our frozen branch. This should be done within a week, hopefully, and I'll focus on that too. Later, still on saturday, we visited the studio of F3, a french netradio -- one of the largest, actually. We met a few people there who were interested in liquidsoap. The discussion was very different. It was about AAC output, and even funkier formats targetting mobile phones; and about audio processing algorithms. Concerning the first point, it is quite clear that Samuel can get us easily any feature present in open-source software, but we won't do more than that. Concerning audio processing, it turned out that the operators currently available don't match the professional needs. We're lucky to have Vincent on board, who seems very acknowlegeable in that domain. Together with Samuel they might be able to enrich our collection of sound processing operators. Enough facts, here are the opinions. First of all, I am really happy to see new developers get involved, enthusiastic netradio professionals, and new users. I'll really try to make the tool easier to get started with, as most newcomers complain about the complexity of liquidsoap. But I must say that I'm not very excited when I hear people who want to use liquidsoap as a transcoder, or as ices-on-steroids (playlist + crossfading + basic sound-processing). Of course that's what most users will do. What I mean here is that (1) I'd like to focus on fun stuff: crazy transitions, effects, powerful automated streams.. unfortunately, I don't have much opportunities to do that since I left Geek Radio in Lyon; (2) It's a bit sad that probably no other dev that me uses/knows/suspects/is-interested-in the power of what is already available in liquidsoap. No bad feeling here obviously, just a thought on the situation. This leads me to come back briefly to Samuel's wish for "streams everywhere in the language" -- the technical word might be a "synchronous reactive language", according to Esterel's site. I do think that it is an interesting approach, worth a lot of thinking. It certainly has some applications, seeing the work done on Chuck, or Samuel's dream examples. But it's obviously a huge bet and a radical change. There's no point discussing this too much, since none of us wants to spend 100% of his time during 2 month for fully re-thinking the core of liquidsoap anyway. I'd just want to insist on the fact that there is most likely a solution to any reasonable problem with the current design, and I'd like to explore more the possibilities of what we have before designing anything else. It was not easy to reach this efficient, flexible and stable state. An example of reasonable (but already bloody exciting) problem is having a cross-fade which manages to avoid discontinuities in the BPM. Currently, the smart crossfade has a RMS computation hard-coded in it. The only thing to do would be to move that out, for example by adding a rms-analysis track to the source thanks to a rms() operator. That's a sketchy description, but I'm confident that we don't need streams everywhere for that purpose. Finally, I didn't talk on the recent progresses on low latency, thanks to Samuel's work on ALSA. It is now established that liquidsoap is good for more than just streaming to Icecast and can actually do quasi-realtime stuff. There are still lots of things to do in order to exploit that aspect: Jack, Rtp, embedded minimal icecast-compatible server, etc. These are all "superficial" (but not easy) changes since they don't imply any core re-design, but they'd all lead to exciting new applications. That's it. Now you can see that even when I don't code that much I think a lot about our project and I can talk a lot about it too :) -- David
