Hi,
Following Romain's recent message, here are my plans for the future. I
don't know exactly what should be in the next release: I'm not very
disciplined in that domain...
But first: welcome to Olivier Delande in the Savonet project! He's
working on a complete ocaml-taglib binding, instead of only a binding of
libtag_c. He picked quite a difficult task to start with, but it looks
like he's progressing well.
* Language
I'll start with my speciality: our script language. It will soon get
richer types, which will finally bring new features:
- References, for various usages (sample processing functions with a
state, implementing playlist() variations purely using scripts, or just
for convenience in scripts like liq123, streamliqueur, etc.)
- Checking for exclusivity for cross(): the sub-graph corresponding to
the input source of a cross() or smartcross() operator should not be
accessed by anything else than that operator. Otherwise the temporary
acceleration (violation of the flow of time) that the operator forces
around track limits will make things go wrong. Graphically, there should
be a box around that sub-graph. A similar check will apply to the new
time_warp().
- Introducing a format parameter for sources. At first it will allow
us to control heterogeneous audio formats (mono,stero,5.1...) in the
same graph. Then will come video :p
- Recursive functions if they are needed. But there's probably no way
we can get recursive sources, and I'm afraid that adding recursive
functions will make users think they can build recursive sources.
[The following are probably long-term features..]
- Type inference is still very weak. We need to study a variant of the
language (the "bullet" version in the JFLA paper): we could get full
inference of principal types if we make the partial applications
explicit. How does that sound to you?
- I'm still unsure about how to add exceptions (as strings, as
variants ?). I'm not sure how much we need them, except for getting back
the polymorphism in functions like List.nth, List.hd, etc.
- Some variants would be great, e.g. for the "mode" parameter of
playlist(), but also for making lists be what they really are (i.e. Nil
| Cons of 'a * 'a list) and rewrite all these list builtins in the
script language, using recursive functions and pattern matching. But I
don't know if they should be straight variants, or polymorphic ones.
Please don't hesitate to ask any question and discuss things if you feel
interested. I'll develop any item on demand.
* Hardware Interaction
I think that it'd be great to take seriously new applications of
liquidsoap. Already, it has been used in unexpected ways, notably by
Romain. The serious limitation here is the lack of real-time I/O, local
or remote: Jack finally seems to start working, but RTP is still not
functional. Of course it's still not certain that we can achieve
quasi-real-time, but some past unstable experiments make me trust that
we can do lots of fun stuff.
In that domain, I hope to help with the time_warp() operator that will
allow to have parts of the graph managed by other threads, with an
asynchronous (buffered) interface between the two. In many cases, that
should be useful to avoid bad timing interferences between
input/outputs. It will take some work to get that right, but it also
means cleanup of the core architecture, so I'm happy.
* User Interaction
With more interactive operators should come more interaction with users.
We still need to get THE UI design for liquidsoap. Together with the
development of new interaction interfaces, I expect to see many new
operators which require more controls, like richer mixing tables,
samplers, more effects, etc.
Peter recently started an interesting discussion on re-using widgets
from other projects, unfortunately the thread quickly died. Anyway, he's
still developing Rocket. I must admit I don't know well the current
status of his tool. But I feel and fear that it wasn't designed for
being usable with any instance of liquidsoap. I'd be keen to see a
generic flexible tool for building sets of controllers from basic blocks
-- just as liquidsoap configurations are made of basic blocks. (In the
spirit of liGuidsoap, but stable, complete and nicer.) If I set a script
with two inputs, a couple effects and some outputs, I need an UI for
tuning the effects' parameters, monitoring the stream at various points,
and start/stopping the input/outputs. If my script is just one input,
one audio filter and one output, I'd like to quickly get an interface
for controlling the filter's parameters.
As Peter asked at the beginning, Liquidsoap will need a better server
interface in order to ease the development of external UIs. One could
start drafting some requirements here. In my mind, it would work best to
co-develop a better server interface and a better UI framework.
These were just thoughts about what I'm doing currently, what I plan to
do, or simply what I'd love to play with. As usual, I will mostly do
just what I enjoy doing, only when I feel like coding. That's the way I
keep it fun. And I wish the same to everybody. Let's have fun building
even more surprising tools!
Cheers,
David
