I'd like to really call this design the first generation of rocket, I'd also like any suggestions for a more soapy name for the gui, when you first talked about dia I had memories of a terrible module where we had to use it but I can see your point about using it to mean our ends.
It's at least worth a try and we can plan for it, in terms of the second generation of rocket is when a lot more interaction will be required from the daemon. Ie the big overhaul of the telnet interface will probably come under that, so that for example you can create dynamic 'bubbles' of script on the fly to be run by the daemon. So let's say I queue a track in a mixer, I want to also be able to use an add operation onto that track so that I play a dry jingle during the intro. On 25/03/2008, David Baelde <[EMAIL PROTECTED]> wrote: > Sounds (or rather looks) sweet! > > Just a remark about the "GUI to generate a liq script": I had a > low-cost idea about that, which I may not have advertised enough. The > idea is to use dia. This tool is pretty open: you can add new widgets, > embedded in what they call a "sheet". All this is a matter of a couple > XML files, notably embedding SVG. Then, the user would assemble > liquidsoap widgets, and save. The save format is XML, from which it'll > be easy to generate a script file. So all we have to do is the core of > the tool, only textual, and let all the graphical interaction to dia. > > It won't give the best tool possible, but that would be pretty good > for the cost. What would not be perfect ? I don't think that dia can > enforce acyclicity, so we would have to discard diagrams when trying > to convert them to actual liq scripts. Also, I'm not sure that dia has > a notion of different "types" of slots: it might not be able to > differentiate inputs and outputs. Again, that would have to be checked > at script-generation time. These two constraints are not that bad, > since a user would intuitively understand them. Actually, dia sheets > exist without much problems for UML and electronic circuits, which > have the same kind of constraints. They are almost geometrically > enforced by putting the inputs on the left (or top) and outputs on the > right (or bottom) and having wires that can't easily be twisted too > much. > > Such a sheet would not allow the graphical composition of most complex > scripts with timeouts, custom transitions and so on. But it would be > perfect for lots of simple and intermediate examples, where the > intuition of a graph is enough. Initial nodes could be playlist, > single, input.http... Simple nodes with 1 input, 1 output would be all > audio filters. More complex things: add would have arbitrarily many > inputs, and one output. For switch and fallback, I think fallback > should have arbitrary arity in input, and the general switch should be > restricted to exactly one input and a scheduling predicate. I didn't > think about random yet. > > I only quickly looked at the possibilities, and don't plan to have > much time for pushing the idea soon. If anybody is interested to try, > I'd be delighted. > > Cheers, > > David > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Savonet-devl mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/savonet-devl > -- Peter Brooks
