Partition (fictive) réalisée sous "My Sketch Paper" iPad (réduction 50%).
Voulant communiquer à des proches une idée d'arrangement sur un morceau, je trouvais qu'il était plus simple de l'écrire et leur envoyer la partition, que de la jouer (ce qui aurait pris plusieurs minutes sans compter le mix).
Plutôt que de photographier une épreuve manuscrite, je vais faire un tour des logiciels pour tablettes dédiés à l'écriture de partitions, et ne trouvant rien de très probant, je décide de la réaliser directement, avec un logiciel de dessin.
Voilà à peu près ce que ça peut donner, sans vraiment se concentrer :
L'idée devient très rapidement qu'avec un logiciel adéquat, on pourrait en quelques secondes dessiner une partition simple, la modifier, la vérifier (placement des barres de mesures, ...), éventuellement l'écouter, ou la convertir en symboles graphiques.
Voulant mettre à profit mon expérience sur Palm OS -très performant en reconnaissance d'écriture-, je m'oriente vers un projet qui tient compte des gestes, c'est à dire de la manière dont sont dessinés les éléments, et pas seulement de leur aspect graphique.
- On peut dessiner à main levée dans la vue, en temps réel. J'aurais pu utiliser OpenGL pour un trait plus esthétique, mais pas dans l'immédiat.
- Le dessins générés lors d'un trait continu sont à chaque fois convertis en images et intégrés à une vue superposée à la vue principale.
- découpage d'un tracé en boites élémentaires : la boite qui suit le curseur ne prend en
compte que les dernier points ; 3 méthodes testées prenant en compte
le nombre de points et la taille réelle (somme des tailles de segments).
- affichage d'une ombre durant le tracé.
- les boites peuvent être inclinées et non plus seulement horizontales/verticales ; test avec 45°.
- choix dynamique de la boite orientée : selon quelle est horizontale/verticale
ou penchée, la boite à afficher change au cours du tracé. Le choix est fait
selon l'épaisseur de la boite (l'affichage n'en tient pas compte).
- compatibilité iPad : taille de la vue, taille boite augmentée (100 points),
tests : la fluidité est maintenue.
- timer pour effacer l'ombre
- distinction du sens de la boite en plus de son orientation, par exemple 0° ->
0°/90°/180°/270° (horizontale vers la droite, verticale vers le haut,
horizontale vers la gauche, verticale vers le bas).
- révision de la gestion des boites : on ne peut plus utiliser des
angles quelconques mais seulement BoxHV+Box45 (actuellement), ou
BoxHV+Box30+Box60 (en cours)
- étude sur le merge des boites : si une boite est identique (en type et
direction) à la précédente on la concatène. Une boite pouvant être "indécise",
i.e. dont la direction n'est pas clairement définie (exemple si elle est à 22,5° elle peut être concaténée à une
horizontale, mais aussi à une de 45° qui peut suivre) on trouve 9 cas possible
de concaténation. Ceci n'a d'intérêt que pour le tracé (DEBUG) et ne concerne
pas la reconnaissance, à moins de vouloir absolument découper les éléments de
tracé. Mis de côté.
- gestion d'une liste de directions (successivement distinctes).
- refactoring du code (préparation à l'utilisation sous forme de
librairies) :
séparation du code public (headers) et privé (headers privés et code)
- activation des boites 30°/60° (12 directions)
- ajout du stroke "Point", reconnu uniquement à la fin du
tracé ; application à la sélection d'objets.
- les vues créées sont typées,
ce qui permet affecter une action différente selon qu'il existe déjà un objet au
départ ou à la fin d'un nouveau tracé, ou traversé par ce dernier.
- modification de la gestion des strokes successifs,
la première solution utilisant une fonction de hashage devant maintenir un
tableau de 25^n valeurs (soit 15625 pour 3 strokes...), j'utilise maintenant une liste
chainée. La reconnaissance est toujours en temps réel, pas de ralentissement notable.
Voir exemple en 0.13.
- comparaison des strokes effectués avec ceux entrées dans la liste,
- exécution automatique d'actions
: en cours (nécessite de tester les points ou les lignes selon les vues déjà
tracées)
- fix sur la transparence des vues générées
,
- exécution automatique d'actions : redéfinition de l'API, on ajoute des actions aux
tracés et non l'inverse, ce qui permet d'avoir plusieurs actions différentes
pour un même tracé selon le contexte (voir exemple en 0.13).
- les tracés non reconnus sont
immédiatement supprimés (la vue n'est pas créée)
- gestion de l'arborescence des vues (suivant Action définie) avec déplacement
d'une Vue existante dans une autre
- la gestion de la Sélection tient compte de l'arborescence (parent d'abord,
...)
- affichage
en pointillé du contour d'une vue lorsqu'elle est sélectionnée, avec
animation,
- finalisation de la compilation sous forme de librairie, la version myScore
utilise maintenant la lib.
- implémentation d'une debugView apparaissant sous chaque vue créée,
- génération d'une doc par Doxygen,
- résolution de l'ambiguïté sur les tracés court
(en particulier les cercles !) : le tracé tremble toujours, certains
points devraient être éliminés, seulement, pas
toujours !
- (affichage en clair du nom de l'action en debug)
- Modification du calcul de l'orientation des Box (comparaisons des caractéristiques
selon chaque modèle d'orientation),
- notion de "graffiti", c'est à dire un tracé
quelconque dans un certain contexte ; en cours,
- notion de "tendance" : l'orientation de la boite dépend du sens du tracé
en favorisant le point final ; abandonné,
- gestion des boites "indécises" considérées comme temporaires,
validées/concaténées/supprimées selon les tracés suivants,
- tuning des réglages (détermination des boites "ignorées" et "indécises").
- optimisation des recherches de position de tracés par rapport à ceux existant,
- implémentation de la notion de "gribouilli" ("squiggle" ?) = succession en nombre
indéterminé de tracés d'orientations quelconques,
- application : mise en œuvre du stroke "gribouilli" :
transformation de blanches en noires,
- application : implantation des "drapeaux" ("flags") de notes,
- modification possible (à travers l'API) de l'épaisseur d'un tracé reconnu (utilisé dans la vidéo 0.11)
- nouvelle fonction (API) de définition massive des StrokeLists
; application : 9 possibilités pour dessiner les drapeaux
- Aide avec liste défilante, tracés à exécuter pour : Lignes de
Portée, Portée, Ronde,
- silences : Pause, Demi-Pause, Soupir (style ancien), Demi-Soupir,
- possibilité de "remplir" les Pauses et Demi-Pauses (squiggle)
- Aide, écrans pour : Blanche, Noire, Croche,
- Aide, écrans pour : Pause, Demi-Pause, Soupir, Demi-Soupir,
- rajout d'une condition (niveau API) sur le parent du stroke existant ;
application : on ne peut tracer des drapeaux de croche que sur les hampes de
noires, et non de blanches (discussion relative à l'architecture : c'est la
hampe qui change ou la note ?)
- modification de l'architecture des objets crées, pour compatibilité future
avec MusicXML. Ce format est reconnu par Cubase, Finale, Guitare Pro, LilyPond,
Logic Pro, Max, Muse Score, Rosegarden, Sibelius, ... (174 entrées sur
http://www.musicxml.com/software/)
- fix sur la gestion des chaînes de caractères pour Logs (déplacement des fonctions vers WM_GSRecogniserLib)
- help : la dernière page vue est sauvegardé
- help : affichage obligatoire si l'application n'a jamais été lancée
- fix important sur les segments courts qui étaient ignorés
- modification des icônes (...)()
- ajout de strokeLists pour la ronde (aide en ligne non updatée)
- Deployment Target devient iOS 6.0 pour la soumission à l'AppleStore (la version minimum d'iOS pour faire fonctionner l'application)
- tests 64 bits
- soumission ; (estimated size : 34,3 Mo)
- définition des diverses images (splash screens, icônes),
- soumission à iTunesConnect ("estimated size" : 34,3 Mo)
"one unresolved issue"
Reasons
2.12: Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected
We found that your app only provides a very limited set of features. It only includes the ability to trace musical notes. [...]
-> l'application a été refusée ("rejected"), car "elle ne fait rien d'autre que permettre de tracer des notes musicales".
La réponse est très décevante, mais juste finalement. Ils ont raison : que la mise en œuvre applicative de l'API tienne en moins de 150 lignes, l'essentiel du process étant effectué par cette dernière (qui constitue elle, 30 fichiers et un nombre encore plus élevé de classes), ne peut entrer en ligne de compte à ce niveau.
Mon objectif était devenu plus de valider l'API par une application démo, que faire une application vraiment utile.
EDIT:
La publicité actuellement mise en avant par Apple (pour l'iPad et l'App Store) expose le directeur musical Esa-Pekka Salonen et les applications qu'il utilise pour ses compositions. Il a contribué à leur développement (selon l'article), et de la manière dont elles sont mise en avant, il faut avouer que la mienne manque d'envergure.
Lorsque des logiciels utilisent des banques de sons "interprétés par le London Symphony Orchestra aux studios Abbey Road" il est difficile de rivaliser.
L'idée de la méthode d'élaboration des partitions me semble toujours originale et pratique, je valide donc d'améliorer la partie application, et de la rendre plus professionnelle, sur 3 axes : le rendu graphique, la sauvegarde, l'annulation des opérations. L'export XML et l'écoute des morceaux seront pour plus tard.
Les commentaires présents dans cette page sont ceux utilisés dans GIT, épurés des détails techniques.
La suite (version 1.1 -> 2.0)
Wan More, mon site
Professionnel ; myScore n'est pas encore disponible au téléchargement.
