dbaelde a écrit 11 commentaires

Arf, pas besoin d'aller sur le site web, yavait un peu d'info dans la depeche sous mon nez: darkice. C'est tout, un darkice qui fait carte son -> icecast?

Salut, et bravo pour l'intiative, je te souhaite que ça marche!

Je me demandais quels logiciels tu utilises dans ta streambox. Je m'attendais à voir des choses comme rivendell, jack, peut etre ices, ou pourquoi pas liquidsoap (dont je fais partie des développeurs). Mais aucune info sur le site web. Tu nous éclaires? C'est quand meme pas du tout maison, j'imagine.

Le sujet m'intéresse, étant confronté au problème avec les logiciels que je développe, mais il me semble que le vrai problème c'est qui écrit la doc, et comment. La question de savoir dans quel format est une bête question technique que la plupart des développeurs savent déja régler: on peut écrire en docbook, html, tex, wiki, et convertir dans tous les sens: ce n'est pas toujours parfait et on peut y perdre du temps, mais ça me parait pas crucial.

Par contre, ce qui est dur, c'est de pousser les développeurs à documenter leur production: quand il y a une nouvelle feature ou une modification, il faut le répercuter sur la doc; de temps en temps il pondre ou mettre à jour des tutoriels. Quelles sont vos expériences?

Dans un petit projet (bedwyr) ça marche pas mal d'écrire une doc entre développeurs. Dans mon cas, c'était un PDF généré à partir de tex, écrit une fois pour toutes car le projet ne bouge plus trop.

J'ai plus de mal avec un gros projet (liquidsoap). On a d'abord essayé le wiki pour faire participer les utilisateurs, avec la crainte d'avoir des pages mal finies et une vue d'ensemble hétéroclite... mais de toute façon il n'y a que les devs qui contribuaient. De temps en temps on me disait que la doc était trop austère, qu'il fallait plus de tutoriels intuitifs. A un moment, on en a eu marre d'administrer le wiki (spam notamment, mais aussi maj) et on s'est aussi dit que ce serait bien d'archiver voire versionner autrement qu'avec l'export PDF. Donc on a carrément mis dans notre SVN les fichiers source wiki, avec notre petite moulinette d'export HTML et PDF. Du coup, ça rend plus difficiles les contributions externes. Et par ailleurs les devs sont pas très actifs sur la doc non plus... A côté de ça on a une mailing liste sur laquelle certains problèmes passent souvent, et on a toujours pas été foutus de créer une FAQ dans la doc ou à côté. (Pour info la communauté est relativement petite, un noyau dur d'une dizaine de personnes, et des électrons libres de passage).

Quelle est votre expérience? qui écrit de la bonne doc, développeurs? utilisateurs? en mode wiki ouvert ou juste par certains contributeurs sélectionnés? des idées sur le lien entre le support (mailing liste, irc..) et la doc?

Salut,

Après un monsieur Oxyradio, la réponse d'un monsieur liquidsoap. Comme tu dis, tu peux essayer de mettre un liquidsoap derrière icecast. Ca permet de faire beaucoup de choses, traitement de son, transitions, manipulation de metadata, insertion des lives, etc.

Si tu as une idée claire de la structure de ta programmation, tu peux la coder directement (et définitivement) dans ton script liquidsoap, genre le matin on fait ceci, le soir cela, et de telle heure à telle heure on a une queue de requetes à la demande. Souvent, on veut faire des choses plus compliquées que cela (sélection de morceau en fonction de quotas de non-répétition, interfaçage avec une base de données), et dans ces cas là nous conseillons en effet de se tourner vers des scripts externes pour piloter liquidsoap.

Pour ne pas rester que sur liquidsoap, note que si tu optes pour le script externe et que tu n'as pas d'autre besoin (e.g., décrochage live, traitement du son) tu peux aussi utiliser ices (ou ezstream) avec un script externe. Menfin, si t'as un liquidsoap compilé (ou installé via debian/ubuntu) c'est pas plus compliqué à utiliser...

Je ne connais pas d'outil de gestion de grille de programmation open-source convivial. Pour l'instant, chez nous, chaque utilisateur développe une solution perso plus ou moins complexe, adaptée à ses besoins. Une ou deux fois des utilisateurs nous ont annoncé qu'ils allaient faire de leur système perso un projet disponible pour tous, mais toujours aucun produit final en vue. Si quelqun de compétent cherche un projet utile à démarrer... D'une certaine façon il y avait mediabox404, qui couplait un ices patché avec une base de donnée de morceaux et une grille de prog en php, mais il est mort. Selon les goûts, si leur php est propre, une façon de démarrer pourrait etre de rendre leur systeme indépendant du streamer (ices ou liquidsoap).

En tout cas, n'hésite pas à te tourner vers savonet-users@lists.sf.net pour plus de questions (en anglais si possible) sur liquidsoap. Ya aussi la liste d'users icecast, peut etre que quelqun pourra te dégoter un outil dont on aurait pas encore entendu parler.

Mouais.

Je trouve ça déplacé de parler de "notre belle langue" dans ce contexte. En soi, cela n'a rien à faire ici: Un langage de prog est plus simple à apprendre s'il est plus proche de la langue maternelle, admettons, mais de là à y mettre des phrases et de le faire ressembler à du langage naturel, non. En BASIC on ne dit pas "you go to line 13". Et puis, avant de défendre notre belle langue, il faudrait y travailler un minimum: le site web de linotte est truffé de fautes de grammaire et d'orthographe phénoménales -- tout comme les commentaires qui le félicitent ici.

D'un point de vue pratique, je soupçonne aussi que la grammaire de linotte soit très mal foutue: même si elle a une spec stable, ce dont je doute, je mets ma main à couper qu'elle n'est pas intuitive, que ses règles ne sont pas simplement assimilables. Les exemples font peur, quelle lourdeur.

Dans l'apprentissage de l'algo, il y a certes deux composantes: (1) le concept d'algorithme, i.e. la formalisation de la pensée, et (2) l'écriture en syntaxe concrète de l'algorithme. Je suis d'accord qu'en théorie les deux sont séparés. Mais en pratique, j'ai quand même l'impression qu'une syntaxe concrète simple aide à formaliser. Il faut comprendre qu'on ne parle pas à un être humain, on donne une recette précise à ue machine. Idéalement, en apprenant la grammaire d'un langage de programmation, on pourrait voir se détacher les concepts algorithmiques de base.

Super news, très mignon tout ça. Mais "Asus veux" ça fait quand même mal :( C'est la troisième personne là.

Hihi..

En l'occurence le compilo Caml est bootstrapé depuis le début (dès Caml Light). Le runtime est écrit en C, mais la complexité bytecode Caml n'a rien à voir avec Python et même RPython.

L'avantage principal de cette approche est la maintenabilité -- écrire un compilo en Caml est inifiniment plus agréable qu'en C à mon gout. Accessoirement, ça assure que les gens qui écrivent le compilo programment dans le langage de destination, et s'impliquent donc sur sa qualité...

Pour finir, je suis déçu de lire que RPython est inutilisable. Quand j'ai appris l'existence de RPython je me suis dit que les Pythoneux découvraient enfin les horreurs cachées de leur langage et les écartaient en créant un sous-ensemble propre, RPython. Visiblement ce n'est pas le cas.

Ouais je suis tombé sur chuck. Ca a son côté sexy avec ses "chucks" dans tous les sens, et les interfaces graphiques de Audicle. Après j'ai aussi l'impression qu'ils utilisent le mot chuck à la va-vite pour plein de concepts pas du tout nouveaux.

En tout cas il me semble que c'est pas le même but que liquidsoap. Ca travaille surtout à bas niveau, complètement orienté vers la composition simple de flux, avec applications au live coding & co. Liquidsoap permet de travailler sur le flux même, mais a aussi une notion, plus "haut-niveau", de piste dans un flux, et permet de travailler sur des meta-données insérées dans le flux. Enfin, un flux peut se tarir puis redevenir disponible. Bref, tous ces trucs qui nous permettent d'agencer différentes sources de musique dans un script liq, passer de l'une à l'autre en fin de piste, réécrire les meta-données, etc.

Petites précisions sur jack. En fait tout dépend du besoin exact. S'il ne s'agit que d'avoir une sortie jack, ça parait jouable pas trop difficilement, en utilisant libjackasyn que je viens de découvrir. S'il faut faire des entrées sorties, ça a l'air encore plus ou moins possible, sauf qu'il y aurait une petite latence, probablement pas gênant dans la plupart des utilisations.

Bref, pourquoi penses-tu à jack exactement ?

Réponse simple: non... pas encore. On nous on déja demandé du jack, on a un embryon de code sur le SVN, mais c'est très loin de marcher. Le truc dur c'est de binder la libjack pour OCaml, le modèle d'exécution est très spécial. Je serais ravi de recevoir des contributions dans ce sens (de l'aide sur le RTP serait utile aussi), mais je me rends bien compte que peu de gens sont à même d'interfacer C et Caml.

Pour les bases de données. Il y a quelques temps j'avais implémenté dans liquidsoap le protocole DJ (protocole au même titre que HTTP, FTP, ..) utilisant une connection à une table mysql au format particulier. Ocaml-mysql était demi-bugué, et c'était trop spécifique de toute façon, j'ai donc abandonné. Ce que je conseillerait maintenant est de faire un petit script dans le langage de ton choix pour parler à ta bdd, et interfacer liquidsoap avec ce script. Ils font ça chez radiopi. Si tu veux des détails vois le cookbook sur notre wiki ou maile nous à <savonet-users@lists.sf.net>.

Pour le reste, je suis déja tombé sur Rivendell, qui a l'air très complet. Je n'ai jamais étudié sa conception, ni même essayé. J'ai l'impression que liquidsoap est plus simple, probablement plus facile à étendre, mais étant le développeur j'ai clairement une vision biaisée. En tout cas je suis dispo pour toute question.

Je suis agréablement surpris par ce post, c'est rare que les amoureux de la programmation soient visés -- mais peut-être que je cherche pas au bon endroit pour ça.

Je me demande quand même combien de gens ont besoin d'écrire des algos bit à bit en C.. j'ai passé un certain nombre d'années à coder en C, ça m'est arrivé très rarement. Il y a des gens qui ne peuvent pas utiliser la libm pour le log ou la valeur absolue ?