martinclic a écrit 34 commentaires

Sauf que l'approche ne serait pas la même.
Je vois bien qu'effectivement mozilla veut privilégier les web apps et standardiser des API JavaScript, mais ce ne serait pas stupide de permettre une entrée "propre" pour bidouiller, au moins pour expérimenter, sur Firefox OS.
Sur Firefox, pas mal de choses sont tentées d'abord par extensions, et parfois intégré par la suite.

En fouillant, cette réponse sur les newsgroups semble dire que c'est peut être envisageable.

Does the Firefox OS browser support extensions?

No, or, not yet.

Je doute très fortement. Emscripten, çà voudrait dire transformer libfluidsynth en pure JavaScript, alors que là on bénéficie justement que cette lib bas niveau soit en C, avec par exemple une horloge au poil pour le sequencer.

La bonne piste, ce serait vraiment une entrée avec les privilèges chrome et xpcom dans Firefox OS, comme les extensions.

Ah, pas bête comme idée l'enregistrement du clavier! Faut que je réfléchisse comment faire, à voir ;) .

C'est une bonne question, mais j'ai pas vraiment la réponse…

Un appli purement HTML, c'est non, il faudrait une API proposant un Synth et un Sequencer similaire à ce que j'ai fait avec FluidSynth via js-ctype, et elle n'existe pas.

Un moyen pour justement implémenter cette partie dans Firefox OS,et donc avoir un accès plus profond, comme les extensions sur Firefox, j'ai pas l'impression que çà existe. Mais peut être que je me trompe, j'aimerai bien, çà serait chouette ;) .

Après, l'interface pourrait effectivement être réécrit en HTML, mais XUL c'est quand même bien pratique (XBL, L10N,…).

Alors, çà sert principalement à ce que je m'amuse à coder ;) .
Le clavier est un jouet, mais il peut être utile dans de rare cas pour un musicien.
La boite à rythme à l'air de plaire autour de moi aux musiciens, plus simple qu'un éditeur Midi complet.
Le lecteur Midi, tel quel, n'est peut être pas très utile, mais son code me servira peut être pour d'autres trucs.

Et le choix du XUL, la raison principale c'est que j'aime bien le XUL et que je connais (même si ce plus trop à la mode). Mais Qt ou python serait un bon choix aussi.

Combien de temps pour coder ça ?

j'ai codé çà en dilettante, pour jouer sur mon temps libre, donc sur plusieurs mois. Mais les prototypes des applis ont été rapides, quelques heures (un peu plus pour le lecteur de fichier Midi)

Qu'est-ce qui a été facile ? Difficile ?

Rien de vraiment difficile.
La documentation sur js-ctypes est un peu spartiate, il faut donc faire quelques essais.
Et par exemple se rendre compte que certaines méthodes de FluidSynth qui agissent sur d'autre threads ne sont pas utilisables ici.

Le piano a été trivial à prototyper.
La boite à rythme est un peu plus riche, et était presque une étape pour créer le lecteur de fichier Midi.
Le lecteur Midi, justement, est un peu plus compliqué. Il faut trouver de la doc sur le format Midi, créer de quoi lire ces fichiers binaires, et imaginer comment les lire par petits bouts.

L'interface utilisateur prend du temps aussi, essayer qu'elle soit efficace et jolie, faire de jolis boutons, fournir une aide, traduire… Çà prend presque plus de temps que le reste.

Le piano marche-tu aussi en bépo ? :)

oui, il devrait ;) . Il y a actuellement 2 agencements disponibles, azerty et qwerty, mais il y a un petit éditeur pour pouvoir créer son agencement personnel.

ah non, je ne suis pas l'auteur de ces libs et de la soundfont, donc je ne peux pas évidemment pas modifier leurs licences ;) .
Et ajouter une exception à ma licence ne permettra pas d'incorporer du code GPL 2.

le dépôt debian.weboob.org unstable n'est pas mis à jour, il n'est plus utilisé ?
C'était bien pratique…

Avec une licence MPL, si tu réutilises/modifies le code d'un seul fichier, tu es tenu de diffuser les sources de CE fichier modifié.

Alors qu'avec un fichier en GPL, tu es tenu de diffuser le code de tout le programme.
Avec LGPL, tu es tenu de diffuser le code modifié de toute la bibliothèque, mais pas forcément du reste de ton programme.