Hi Marcin, On Mon, Jan 24, 2011 at 10:52 PM, [email protected] <[email protected]> wrote: > I think it should be implemented in the same way as in many other > consument media players, where you can just choose a position within a > stream.
I have never used a tool with such a feature. Plus, a media player is different from a radio playout system. We need a more detailed proposal to start thinking about what's implementable in liquidsoap. And that discussion (proposal, etc) should take place on the ticket that I mentionned the other day, or at least on the list, where I bring it back now. I hope you won't mind. > I know that seeking like that could be not too precise, especially in > VBR files, but in fact, it does not has to be! I mean that if you > create a GUI tool to set the cue points based on the same > seeking/decoding library as is used to broadcast, even if what user > saves during cue point setup has got some lag (compared to real cue > position), the same lag would be reproduced during playback [...] This is irrelevant. I already mentionned that tools exist for cutting mp3/ogg precisely and without decoding. There is no point to recode those tools inside liquidsoap. The only reason not to use those tools is if we do a cutting operator that works directly on decoded streams, but then precision is not an issue in the same way (the only problem is remaining time estimation, but it can be solved by relying on a "duration" metadata). (It occurs to me that it may be useful to remind that liquidsoap's operators only process raw/decoded streams, and that it can't be changed for two reasons: it'd take a lot of time, and it'd only work in very limited cases.) > I can[not] really help in implementing that - OCaml seems too weird for me. > ;) And I don't recognize it's internal logic that could prevent > solution like that. Well, using such exotic technology doesn't help > liquidsoap to grow... > [...] > To be honest, I think that high-level API should be written in > something less exotic than OCaml. Liquidsoap is coded in OCaml, but liquidsoap's script language is not OCaml, it's just liquidsoap's language. Even if this scripting language is too exotic for you, there's always the possibility to call external scripts written in the language of your choice: that's the UNIX philosophy of having several simple programs cooperate to achieve complex tasks. I'm still happy with the choice of OCaml. Although OCaml has limited the number of core contributions, we should not forget that there are many ways to contribute: you can create wrapper tools around liquidsoap (see rocket, washtub, etc) or compile a nice collection of scripts (liquidsoap or other languages) that makes it easy for people to create more things around liquidsoap. Also, documentation and support on the mailing list doesn't have to be done by the devs (almost) alone. It is our goal to promote such actions, by giving visibility and changing liquidsoap as needed, but we people have to jump in and start doing more stuff! > On the other hand, if there is any solution, even workaround based on > cutting the file during request preparation stage, it definitely > should be added to the documentation. Yup, that's the plan I'm considering. I'm waiting for feedback from Peter, and then me & Romain will address that technical issue I was talking about (no point detailing it here) after which we can add the script to liquidsoap and document its use. > My general impression is that liquidsoap authors made great work, but > still can't decide if it's a swiss army knife for audio/video > processing or ready-to-go framework to setup the radio. It's mostly a swiss army knife, or rather a swiss-army nice framework (programming language) to which we add radio-related features. The ready-to-go thing is not our main focus: we won't do graphical or web interfaces, etc. Again, this can be done as a project on top of liquidsoap. If you meant a more modest ready-to-go, like enriching the liquidsoap builtin features, operators, and libraries (utils.liq, externals.liq & co) and the documentation of their use, I think that it's doable, and that it should be done within liquidsoap, but that's also something where non-OCaml-developers or even non-coders can help -- and we'd welcome people to the team for such things. > On the other hand, you advertise it as a software ready to build a > netradio, and you provide dozen of effects ready to use etc. It is ready to build simple netradios, and it provides pretty good ways to build the most complex ones (the only alternative that I know would be to code your own software in a "regular" programming language which would be a painful waste of time). We like to cite Kay: "Simple things should be simple, complex things should be possible." You can't expect all things to be simple. That being said, we spend a lot of time adding popular features, and that's what we are discussing here. > But when it comes to the reality, you always get to the point where there's > something that you cannot without advanced programming. And you left > with liquidsoap scripts surrounded by dozen of other scripts, that is > hard to maintain etc. My secret goal: force all of you guys to learn programming :) > In my opinion, kind of separation of library and framework could > really help the project to evolve. I'm not sure about your "library" and "framework" terminology, but I agree that the project needs more contributions to evolve, either in the form of liquidsoap scripts (library, documented examples) or external tools (graphical/web UI, simplified interfaces). > Framework should have higher-level API, encapsulate raw liquidsoap, > and should solve all the tasks like > - cue point setting, > - more advanced scheduling (currently if you want to have professional > scheduling, you still have to use separate scheduler and use > liquidsoap to playback playlist - which means using 10% of it's powr, > or you have to write your own scripts - which could be not too easy), > - audio routing, > - standard API (maybe HTTP + REST?) for integration with other systems. > - etc. I'm not sure what you mean by "audio routing" but all other points have been discussed, at least among developers. There is still nothing widely available for those things for several reasons. * Concerning scheduling, it's simple to hook any external tool with liquidsoap, but there are not many open-source external schedulers around: one problem is that one scheduler doesn't fit everybody's needs; another problem is that people develop a scheduler for their need and don't share the code. * The telnet commands have an ad-hoc syntax, and it doesn't help to integrate with other tools. Yet it remains quite simple and people have managed to write web interfaces without complaining much. Still, Romain and I have discussed several times how to structure things in a better way, and there are various plans. Also note that Romain added some features recently to define HTTP services directly in liquidsoap. I hope that I've clarified a couple of things, but I'm afraid our time would be better spent devising a polished solution to the problem under consideration. Cheers, -- David ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
