Alors que nous poursuivons la mise en place de la base de données de Kooplet, nous avons commencé à examiner les système de développement pour Flash.
Le but final serait de réécrire en Flash le module de recherche de séquence musicale, afin de permettre à un maximum de personnes de pouvoir utiliser le moteur, sans avoir besoin d'installer notre plug-in.
|
|
|
| by Olivier Guillion |  |
| |
|
Le gestionnaire de base de données est maintenant entièrement réécrit. Les recherches rapides dans la base ont été inclues dans le gestionnaire, accélérant celles-ci d'un facteur de 10 à 100.
Ce module intègre pour cela des calculs de hash-tables et divers index, gérés automatiquement, ce qui simplifie grandement le programme spécifique à Kooplet. Par contre, cela demande nettement plus de traitements lors du stockage des musiques dans la base.
Nous avons effectué quelques tests sur une base réduite à quelques milliers de fichiers, et les résultats semblent concluants.
Il faut maintenant créer ces index pour les 186000 fichiers déjà traités. Les premiers essais nous donnent à penser que ce traitement devrait prendre plus de 24h non stop.
Nous essayons d'accélérer les calculs au maximum avant de lancer cela, histoire de ne pas monopoliser trop longtemps l'ordinateur sur lequel notre version locale de Kooplet est hébergée.
|
|
|
| by Olivier Guillion | |
|
| |
|
Ayant reçu très peu de retours sur la nouyelle version d'Harmony/Melody, nous avons pu nous remettre à travailler sur Kooplet.
Au programme: refonte totale des bases de données et des index rapides pour la recherche. Nous créons un module additionnel de gestion de base de données qui pourra ensuite nous servir dans tous les scripts qui en auront besoin. C'est du Perl "pur", donc, même si c'est probablement un peu moins performant qu'une solution toute faite, la portabilité est maximale, et nous contrôlerons l'intégralité de la chaîne logicielle, ce qui est utile en cas de bug ou de corruption de fichier.
Lorsque ce sera opérationnel, la recherche devrait être grandement accélérée.
|
|
|
| by Olivier Guillion | |
| |
|
Un crash a été corrigé dans le changement de volume de la table de mixage réduite
Nous en avons profité pour corriger d'autres petits problèmes liés à la table de mixage.
Egalement:
- Correction de l'import CMF
- Correction dans l'édition individuelle des notes
Enfin, nous rencontrons un problème très bas niveau : nous avons considéré, depuis quelques versions, que tous les PCs étaient dotés de processeurs incluant le jeu d'instructions MMX.
MMX est une extension destiné originellement au multimédia, et qui permet de la manipulation rapide de données en masse.
Nous l'avons donc utilisé pour des opérations de mouvement de mémoire.
Il semblerait que certains utilisateurs ne possèdent pas de processeur avec un jeu d'instruction compatible, cela ayant pour résultat un crash au démarrage de nos applications (pas seulement Harmony/Melody). Nous avons donc modifié notre code afin de le rendre plus propre, avec un test de la fonctionnalité avant de l'utiliser. Lorsque le processeur n'est pas compatible MMX, l'ancien code est utilisé, plus lent.
Malheureusement, nous n'avons pas pu trouver pour l'instant de moyen de tester cela, toutes nos machines étant compatibles MMX. Il faudra donc trouver un utilisateur rencontrant le problème et suffisamment aguerri pour tester une version beta privée. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons, lors du changement de compilateur, rencontré des problèmes de mauvais fonctionnement interne des routines de compression de données.
Problème d'abord dans la gestion du format MusicXML compacté (Mxl), rapidement corrigé, mais cela a alors déterioré le compactage des données lors de la gestion des aspects personnalisés de l'espace MUSL.
Nous l'avons également corrigé, et après un cafouillage dans la sortie de la nouvelle version, tout semblait fonctionner à nouveau.
Mais il semble que la compression/décompression était également utilisée à deux autres endroits:
- Le chargement de l'ancien format propriétaire de fichiers MusicXML compressé (.xmz)
- Les fonctions PackFile/UnpackFile de MyrScript. Là impossible de savoir avec certitude combien de scripts les utilisent.
Ce sera donc corrigé dans la prochaine version d'Harmony, probablement en même temps que la sortie des nouvelles versions du player et du plug-in... |
|
|
| by Olivier Guillion | |
| |
|
- Une erreur de structure de fichier dans les définitions par l'utilisateur de tablatures pour harmonica empêchait la lecture d'anciens fichiers. Le problème a été corrigé, et une compatibilité rétablie entre les versions.
- La définition d'harmonica sans aucun trou (aussi appelé "bout de bois"  ) ne fait plus planter l'affichage des tablatures
- Accélération de l'affichage des notes liées sur plusieurs mesures, du calcul de positionnement de ces notes en mode gravure, et de l'affichage des liés en général.
- Correction du script d'import NoteWorthy
- Recalage du marquage de la note en édition de note sur les portées avec parole. |
|
|
| by Olivier Guillion | |
| |
|
- Il est maintenant possible de définir la manière dont sont découpés graphiquement les silences liés.
- Correction de l'affichage des ruptures.
- L'épaisseur minimale des coulés à l'écran a été réduite, afin d'avoir un rendu plus fin
- Correction d'un problème d'affichage sur les accords de notes liées de durées différentes
- Correction de problèmes de durées de notes dans Virtual Singer, dans des cas assez rares
- Correction d'un crash dans l'essai de la grille d'accord, lorsqu'aucune portée n'est présente dans le document
Bon week-end! |
|
|
| by Olivier Guillion | |
| |
|
Alors que le concours 23 vient d'être terminé, et que les morceaux sont envoyés au membres du jury, nous réfléchissons au sujet du 24ème.
Nous préférons de manière générale imposer une contrainte claire, qui permet de savoir immédiatement si le morceau a bien été composé pour l'occasion. Cela évite ensuite, lors de l'écoute, de se demander "en quoi ce morceau correspond-il au sujet ?"
Ainsi, pour ce prochain concours, nous allons certainement fournir une portée de basse, écrite sur environ 90 mesures (environ 3 mn).
Cette portée devrait demeurer telle quelle (et être jouée et audible) dans le morceau soumis par le participant. Aucune mesure ne pourrait être ajoutée ou retirée, ce qui donnerait des morceaux de durées sensiblement équivalentes.
Par contre, il serait possible de transposer le morceau, de changer l'instrument de basse, d'y poser des effets, et d'ajouter à la partition autant de portées supplémentaires que désiré.
Il serait également possible de modifier le tempo dans des bornes clairement annoncées par le règlement. La grille d'accord d'origine serait également fournie à titre indicatif pour aider les compositeurs.
Le style serait libre, bien que la ligne de basse soit plutôt moderne, mais cela pourrait justement constituer un "challenge" intéressant.
|
|
|
| by Olivier Guillion | |
|
| |
|
|
