 Grâce a MyrScript, le langage intégré à Harmony Assistant et basé sur le Lua (voir les chapitres précédents), le créateur de script peut agir sur n'importe lequel des objets du logiciel, et sur cet objet, accéder à tous ses paramètres.
MyrScript propose également des objets qui ne sont pas des objets musicaux, et en particulier la possibilité de créer des boîtes de dialogues pour interfacer les scripts. Ceci passe par l'Interface Composer qui permet de définir des boîtes de dialogue. Chaque objet de l'interface ainsi défini contient ses propres méthodes de traitement.
Avant de lancer le script, toutes les méthodes sont précompilées, et lorsque l'une d'entre elle est invoquée, le code associé est exécuté. Ceci n'est possible que grâce à l'extrème rapidité de Lua.
Enfin, afin de faciliter le développement, nous avons intégré un débogueur pas à pas avec affichage des variables locales, globales et de leurs membres éventuels. Un mode spécial de fonctionnement du Lua, permet d'invoquer une routine C à chaque ligne du programme. Quand on vous dit que c'est bien pensé !
MyrScript est fourni avec un manuel conséquent. A ce sujet nous avons utilisé une astuce amusante. Plutôt que de le mettre à jour manuellement, ce sont les commentaires de nos propres sources C qui sont extraits et constituent les différents chapitres.
De notre coté, après presque quatre ans d'utilisation, nous ne pouvons que nous féliciter d'avoir fait le choix de Lua. Les rares "plantages" survenus étaient tous de notre fait, et c'est vraiment rassurant pour un programmeur de travailler sur des bases saines et fiables. Un grand nombre de fonctionnalités "pointues" sont ainsi développées à la demande et fournies à l'utilisateur très rapidement, sans avoir à attendre une mise à jour du programme.
La facilité d'utilisation de ce langage nous permet même de nous en servir en interne comme plate-forme d'expérimentation sur les traitements de sons numériques, de données statistiques, ou pour réaliser des petits programmes "jetables" pour un usage ponctuel.
|
|
|
| by Didier Guillion |  |
| |
|
 En 2002, nous avons décidé de tenter de réanimer une idée que nous avions mis "au frigo" depuis pas mal de temps, intégrer un langage de script à Harmony Assistant. Il y a quelques années, nous avions résolu un problème similaire en offrant la possibilité d'enregistrer tous les événements clavier, souris, menu pour pouvoir les "rejouer" par la suite. Le système avait un gros avantage, n'importe qui pouvait l'utiliser sans apprentissage, on lançait "enregistrement" et le programme s'occupait de tout. Mais aussi un inconvénient de taille, comment choisir un symbole donné sur une partition par exemple ? Non, il nous fallait quelque chose de plus puissant. Nous avons commencé a prospecter l'existant, Java était plaisant car très proche de la structuration du C mais difficile à intégrer à notre propre interfaçage. Python, plus souple, nécessitait l'installation de librairies lourdes pour son exécution.
Puis, par hasard nous avons rencontré Lua. Lua veut dire "Lune" en Portugais.
Développé par une équipe d' Universitaires Brésiliens, Lua est écrit en C, open source et librement utilisable. Nous avions déjà eu l'occasion d'expérimenter d'autres projets venant d'universités, et nous partions sur a priori très défavorable. La suite devait nous montrer que nous nous trompions lourdement dans le cas du Lua...
Non seulement Lua est écrit en C, mais en C plus que standard. Créer un projet sur Windows ou Mac OS a été rapide et en quelques heures les librairies Lua étaient compilées sans erreur ni warning.
Les documentations sont extrèmement claires, c'est l'avantage des manuels écrits par des non anglophones, aucun effet litteraire ou de style, rien que de l'information brute et un vocabulaire simple.
La communauté des utilisateurs de Lua est très réduite mais active. Une ou deux de nos questions sur les droits d'utilisation ont reçu une réponse rapide des auteurs mêmes de Lua. Par la suite, Lua s'est révélé tellement solide, rapide et efficace, que nous n'avons plus eu de question à poser.
La seule critique que nous formulons après plusieurs années d'utilisation est que l'évolution du langage en v5 est passée par des changements de syntaxe trop importants, qui auraient nécessité une refonte des scripts existants. Nous n'avons jamais pu utiliser les dernières versions des librairies : impossible de demander à nos utilisateurs de reprendre leurs sources. Pourquoi les auteurs de Lua n'ont-ils pas simplement ajouté de nouveaux concepts au langage sans modifier l'existant ? Dommage, très dommage.
Nous disposions donc d'un "moteur" efficace et rapide, il nous restait plus qu'a retrousser nos manches et interfacer nos objets musicaux à Lua.
|
|
|
| by Didier Guillion | |
| |
|
 Chez Myriad, nous divisons notre temps de développement de manière à peu près égale en maintenance des produits, évolution des produits existants et recherche de nouveaux concepts ou logiciels. Evolution et recherche alternent dans l'année, la maintenance étant constante et constituée principalement d'aide aux utilisateurs. Un projet dure entre 4 et 6 mois, passée cette limite, nous reconsidérons avec attention sa faisabilité. Les projets de recherche pure sont certainement les plus passionnants. Souvent aussi les plus frustrants car une fois sur deux cela n'aboutit à rien. Dans ce cas nous archivons tout de même l'idée pour plus tard. La décision de ne pas passer du stade d'étude, qui en général a pris énormément de temps de part les recherches bibliographiques, analyses et constructions de maquettes que cela demande, en réalisation d'un produit véritable est difficile à prendre.
Mais si nous n'avons ni les compétences, ni le temps ou que le concept n'intéresserait qu'un petit nombre de personnes, pas de pitié, on archive et on passe à autre chose. Certains projets sont dans nos cartons depuis plusieurs années, notamment un simulateur de machine volante qui nous tenait beaucoup à coeur.
Un critère d'abandon qui est déjà intervenu est ce que l'on peut appeller la "question obligée". Si l'utilisation du logiciel ne peut se faire que dans un cadre précis et dans des conditions précises, même si le logiciel détecte ces conditions et previent l'utilisateur, même si cela est expliqué dans le manuel, nous allons devoir répondre des milliers de fois à la même question. Et ça, c'est vraiment usant.
Un exemple type de projet resté dormant puis réanimé et maintenant très actif est MyrScript. |
|
|
| by Didier Guillion | |
| |
|
 Ceux qui me connaissent savent mon aversion profonde pour ce bidule du siècle dernier, ce monstre noirâtre et stridulent qui vous réveille à trois heures du matin parce que certaines personnes sont fâchées avec les décalages horaires, j'ai nommé le téléphone. Pourtant, pourtant, ce jour là, le téléphone sonne. Je lève le nez de mon ordinateur, sachant que tout à l'heure je ne retrouverai pas le fil et la solution au problème que S*** M*** m'a soumi. Lol.
A l'autre bout une dame.
- Je vous appelle d'Italie.
Bon, un point pour cette personne, elle fait l'effort de parler en Français. Et un Français parfait en plus.
- J'ai un problème de notation grégorienne. (Là, elle m'explique un problème compliqué de suppression de punctum dans un neume)
- Euh... Pourriez vous m'envoyer un email ?
- C'est difficile. Je suis Soeur M*** du couvent de L*** et seule la mère supérieure a accès à l'Internet.
- Euh... Un courrier postal peut être ?
- Ca va être difficile également. Il y a deux mètres de neige ici. Cela fait trois semaines que le facteur n'est pas passé. Il nous reste juste l'électricité et le téléphone. Nous sommes coupées du monde vous savez...
Bon, ok, d'accord, je l'ai aidée à résoudre son problème. Mais, vous aurez du mal à trouver meilleure explication que cette soeur Carmélite, bloquée dans son couvent en altitude... |
|
|
| by Didier Guillion | |
|
| |
|
|
