Col-Tracker, part IV

La première partie de cette série est disponible ici.

Ecrivons un peu de code

Les trois premières parties de cette série décrivent ce que j’ai fait en 2013, mais j’avais été pris par d’autres projets, et tout est resté en l’état pendant 2 ans. J’ai eu beaucoup de mal à me replonger dans le projet car je ne me souvenais plus des détails ; c’est une des raisons pour lesquelles j’ai commencé à écrire ce blog, afin d’avoir une documentation technique à peu près à jour si je devais suspendre le projet de nouveau (en plus de garder la motivation en donnant un peu plus de visibilité au projet).

Nous voilà donc revenu au présent. Je suis motivé à bloc, et j’espère bien finir ce projet (ou au moins avancer suffisaient pour qu’il soit utilisable).

Pour l’instant j’ai la vue principale du projet, mais rien ne fonctionne vraiment à part le bouton pour montrer/masquer l’applet Flash.

Je vais commencer par permettre l’édition des instruments, patterns et du Mod lui-même (dans un premier temps, on ne pourra éditer que leurs propriétés (nom, nombre de notes, durée, vitesse, etc…) car un éditeur permettant de saisir des notes dans une pattern par exemple demandera un peu plus de travail.

J’ai décidé d’utiliser la librairie Javascript Lineage pour avoir un modèle objet de base (classes, polymorphisme, etc…) sans trop de problèmes [Note de 2020: Si cette librairie était très utile en 2015, les versions modernes de Javascript supportent enfin une implémentation utilisable du modèle objet « classique », donc elle n’est plus nécessaire de nos jours. Si vous voulez programmer « orienté objet » en Javascript, utilisez simplement les fonctions intégrées au langage].

La première étape a été de créer une classe de base pour les objets « bindables« . Ce que je veux dire par « bindable » est qu’il est possible d’assigner un contrôle (champ de saisie, case à cocher, etc…) à chaque propriété de l’objet :

• Quand on « bind » une instance de la classe, tous les contrôles affichent la valeur correspondante à ses propriétés
• Quand l’utilisateur modifie ces valeurs en utilisant les contrôles, les propriétés correspondantes de l’instance sont modifiées

Puisque j’aurai sans doute besoin de sérialiser ces objets à un moment ou à un autre, j’ai ajouté deux méthodes toBytes() et fromByte() pour sérialiser et désérialiser les instances de ces objets.
J’ai passé un petit moment à essayer d’implémenter une solution « super-optimisée » avant de réaliser qu’utiliser JSON me faciliterait la vie, donc l’implémentation par défaut de ces deux méthodes se contente d’utiliser JSON (on pourra toujours surcharger cette implémentation dans certaines classes si nécessaire).

Ca se présente plutôt bien pour l’instant, mais il manque une couche supplémentaire à mon « framework »…

Un manager pour les lier tous[*]

Maintenant que j’arrive simplement à « binder » une instance d’objet à des contrôles, je me suis rendu compte que dans la pratique j’avais surtout des listes d’objets, et que je devais changer l’instance « bindée » chaque fois que l’utilisateur sélectionne un nouvel objet.

Je pourrais faire ça à la main, mais pourquoi ne pas aller plus loin et implémenter une classe « BindableManager » qui se chargerait de ça ?

Finalement ça c’est avéré plutôt simple, et j’ai maintenant un manager pour chaque liste d’objet qui permet d’associer un tableau d’objets « bindables » à un contrôle de liste, et qui met à jour les contrôles chaque fois que l’utilisateur change l’objet sélectionné.

Le « BindableManager » se charge également de modifier le tableau d’objets quand l’utilisateur modifie certaines propriétés, et met à jour le contrôle de liste quand le nom de l’objet à été édité.

J’ai fais une petite concession pour simplifier le code : chaque liste contient exactement 256 objets. Je ne pense pas que limiter un morceau de musique à 256 patterns (et 256 instruments) soit un gros handicap, et une fois le morceau exporté vers la Colecovision seuls les objets réellement utilisés seront inclus donc ce n’est pas un problème.

Un bonus inattendu à été la possibilité d’implémenter un copier/couper/coller (ainsi qu’un « reset » pour réinitialiser une instance) simplement en utilisant la sérialisation.

Bref, le projet a plutôt bien avancé après cette première séance de codage.

La cinquième partie de cette série est disponible ici.

[*] La version anglaise de ce titre « A manager to bind them all » sonnait beaucoup mieux (surtout pour les fans de Tolkien ;o) )