Certains utilisateurs jouent sur un clavier MIDI maître (n'émettant pas de son) et comptent sur Harmony pour entendre ce qu'ils jouent.
S'ils veulent changer de son, ils doivent utiliser les boutons et curseurs de leur clavier pour sélectionner le son à employer. Des commandes MIDI sont envoyées au programme, qui change le son en fonction.
Mais voila : sur certains claviers maîtres, les boutons et curseurs en question n'existent pas, et leurs heureux possesseurs se retrouvent condamnés à jouer avec un son de piano.
Nous avions écrit un script (MIDI > Echo Program Change) mais celui-ci ne pouvait modifier l'instrument que d'une des sorties MIDI du logiciel.
Or l'écho du clavier peut également se faire vers le synthé à faible latence (Windows) ou Quicktime (Mac).
Nous avons donc permis d'accéder à l'écho MIDI en MyrScript, et avons écrit un script pour permettre de fixer l'instrument utilisé par cet écho. Il sera disponible dans la prochaine version. |
|
|
| by Olivier Guillion |  |
|
| |
|
Dans PDFtoMusic :
Correction du calcul de la taille des appoggiatures.
Deux problèmes assez sérieux ont été signalés et corrigés dans Harmony/Melody, nous sommes en train de publier une nouvelle version.
|
|
|
| by Didier Guillion |  |
| |
|
C'était prévisible, et malgré tous nos efforts pour y échapper cette fois-ci, c'est encore arrivé. Une correction mineure que nous avions apporté à l'import MIDI fait planter le programme assez fréquemment lors de ce type d'import.
Cela nous oblige donc à préparer une version x.6.3f, qui ne diffèrera de la version x.6.3e que par cette correction. La nouvelle version devrait être disponible demain.
En attendant, pour pouvoir importer sereinement les fichiers MIDI (ou Karaoke) vous pouvez sélectionner l'option "Configuration > Préférences générales", onglet "Import MIDI", et désactiver les 5 cases de la rubrique "Calculer les courbes de paramètes pour les événements".
|
|
|
| by Olivier Guillion | |
| |
|
Pour finir la semaine,nous publions la sous-sous version "e" d'Harmony Assistant et Melody Assistant sur notre site Web.
Avec un peu de chance ce sera la dernière...
Bon week-end ! |
|
|
| by Didier Guillion | |
|
| |
|
Il y a près d'un an, le 16 août 2012, après la sortie définitive de la version 9.6.2m, nous avons décidé de modifier la gestion des portées batterie grille. Nous ne nous souvenons plus qui est à l'origine de ces changements, s'ils avaient été demandés par un utilisateur, ou si nous en avions pris seuls l'initiative.
Voici le raisonnement que nous semblons avoir tenu à l'époque : en mode gravure, il n'y a plus de correspondance fixe entre la position en temps, et la position graphique en pixel dans la mesure. Les portées batterie grille suivaient ces distortions, ce qui impliquaient que deux cases, de la même durée en temps, n'étaient pas nécessairement de la même largeur à l'écran. Pour faciliter l'écriture des rythmes, il vaudrait mieux conserver une échelle fixe entre le temps et la position graphique, et donc ignorer le mode gravure sur ces portées, de manière à ce que toutes les cases de batterie soient identiques dans la mesure.
Et nous avons donc implémenté cela, dès le 16 août, dans les premières versions beta 9.6.3.
Mais cela ne fonctionnait pas. D'abord, toutes les fonctions (pose et effacement de note, etc) n'en tenaient pas compte et étaient donc décalées.
Ensuite, les portées classiques, elles, suivaient le mode gravure, et pas les portées batterie grille. Il était donc impossible de savoir exactement ce qu'englobait une zone de sélection, puisque sa limite ne correspondait alors plus à la même position en temps sur toutes les portées.
L'année entière de session de beta-test n'a malheureusement pas permis de repérer ces défauts.
Nous avons donc effectué un rétropédalage rapide, et sommes revenus à l'ancienne gestion, de manière à pouvoir proposer une version 9.6.3e dans laquelle cette fonctionnalité soit à nouveau utilisable. |
|
|
| by Olivier Guillion | |
| |
|
Recalage de certains éléments graphiques dans les tablatures pour guitare.
Correction du magnétisme des palettes.
PDFtoMusic :
Meilleure discrimination des tenuti.
Afin d'essayer de limiter les questions des utilisateurs quand un PDF ne peut être traité, la page du manuel d'explication peut s'ouvrir après le message.
Recalage de l'interface en Néerlandais.
|
|
|
| by Didier Guillion | |
| |
|
La version 1.4.1 de PDFtoMusic / PDFtoMusic Pro vient d'être mise à disposition.
Dans cette version, en plus de ce qui a été annoncé au fur et à mesure sur ce blog :
- Correction de crash lors du jeu après un chargement par recherche textuelle Kooplet
- Remise en service du traitement des portées dont les lignes sont tracées avec des caractères
- Correction de crashs divers à la fin du traitement du document
|
|
|
| by Olivier Guillion | |
| |
|
Correction de certains scripts.
M Watzer, gagnant du dernier concours a accepté de répondre à quelques questions. L'entretien a été mis en forme et publié.
Il y avait un problème sur la version PPC de PDFtoMusic PRO, cela a été corrigé et une nouvelle archive postée. |
|
|
| by Didier Guillion | |
| |
|
- Correction de crash lors de l'édition de l'espace MUSL, lorque l'espace n'était constitué que de dossiers (aucun fichier)
- Le script "Instructeur de piano" a été amélioré : sa fenêtre peut maintenant être réduite pour laisser plus de place à la partition
- Le script "Apprendre les notes du piano" a été amélioré : il affiche le titre du document dans sa barre de titre, et il permet de ne pas afficher la zone de sélection sur la partition
- Sur PDFtoMusic, une nouvelle base de données de reconnaissance des caractères musicaux permet de corriger les problèmes de reconnaissance de certaines partitions. Elle est disponible ici et doit être copiée dans le répertoire "OCRData" du dossier d'installation de PDFtoMusic / PDFtoMusic Pro
- Sur PDFtoMusic toujours, cette base de données sera dorénavant mieux versionnée : lorsqu'on remplacera la base, sa version sera automatiquement mise à jour dans la boîte "A propos" du programme.
Bon week-end à tous ! |
|
|
| by Olivier Guillion | |
| |
|
Correction de l'import NoteWorthy
Amélioration du déplacement des objets associés à la portée.
Correction d'un problème de décalage en copier/coller de portées batteries standards.
PDFtoMusic : localisation d'un problème de reconnaissance de caractère et correction. |
|
|
| by Didier Guillion | |
| |
|
- Suite à une discussion intéressante mais un peu (trop) animée sur le forum, et quelques indications ici même, le point  a été fait sur la gestion des notes pointées en unisson.
La règle est donc :
1- Pour éviter la ligne de portée, le point tend à se décaler vers l'interligne supérieure quel que soit le sens de la tige de la note
2- deux notes pointées de même durée en unisson ne font apparaître qu'un seul point
3- les règles précédentes s'appliquent sauf lorsqu'on désire que cela soit fait autrement.
La règle 1 était déjà gérée
La règle 2 sera appliquée dès la prochaine sous-version
Pour la règle 3, le réglage de décalage du point sera disponible dans la prochaine version du programme qui nécessitera un changement de format de fichier.
- Correction de crash possible lors de l'utilisation de notes sans tête
- Correction du placement de notes hors portée (shift - clic avec le crayon) lorsqu'il y avait plus de deux portées dans la partition
Enfin, si vous ne l'avez pas encore lu sur la page d'accueil ou dans le forum, le 28ème concours vient de débuter, sur le thème : "le duo". Une contrainte technique donc, mais qui devrait laisser une assez grande liberté dans la composition. |
|
|
| by Olivier Guillion | |
|
| |
|
Le module de déplacement des objets associés aux portées (textes, graphismes, diagrammes d'accord, etc) a été repris.
Maintenant lorsque l'on bouge un objet un indicateur visuel montre la portée de destination :
Dans certains cas, et en particulier lors du changement de la hauteur de la portée, ces objets pouvait se retrouver en dehors de l'aire de la portée et n'étaient plus saisissables. Ils le sont maintenant.
|
|
|
| by Didier Guillion | |
| |
|
Sur le forum, un utilisateur a ouvert la discussion sur la représentation des notes pointées à l'unisson, lorsqu'elles sont écrites sur deux vous différentes.
Ces notes sont écrites comme ayant une seule tête, une tige haute et une tige basse. Le programme, actuellement, affiche les pointés de chaque note, et ces pointés sont confondus.
Sauf si les notes sont des croches (ou doubles...) non ligaturées. Pour éviter le crochet de la note écrite tige haute, le programme décale le pointé vers la droite. Cela résulte en deux points écrits côte à côte, ce qui ressemble à un double pointé. Ce n'est visiblement pas bon.
Mais que faire alors ?
Une fois de plus, il est urgent de ne surtout pas se presser. Au-delà des affirmations péremptoires sur ce qu'il faut absolument faire, et ce qui n'est pas du tout correct, il semblerait que plusieurs notations soient admises, l'une avec un seul point, l'autre avec deux points écrits l'un au-dessus de l'autre. Peu importe laquelle est académiquement valable et laquelle ne l'est pas. Il nous suffit de savoir que les deux méthodes sont utilisées pour que nous ayons à les implémenter.
Pour la première, pas de gros problème. Si les points s'affichent sur la même ligne, alors le programme les affiche à la même position, les deux points ainsi confondus n'en faisant plus qu'un.
Pour la seconde, une autre règle (encore à confirmer) dit que lorsqu'une note pointée est écrite sur une ligne (sa tête est traversée par la ligne de la portée), le point se décale vers le haut lorsque la tige est vers le haut,
et vers le bas lorsque la tige est vers le bas.
Si cette règle est vraie, deux notes en unisson sur une ligne auraient leur point écrit sur les interlignes supérieures et inférieures, donc bien séparées.
Resterait le problème des unissons sur une interligne (entre deux lignes de la portée), qu'il faudrait alors représenter ainsi :
Dans tous les cas, gérer ces nouveaux décalages de pointé, si on ne veut pas que l'aspect des partitions déjà écrites change, nécessiterait alors un changement de format de fichier. Cela devra donc attendre une nouvelle version majeure, et on pourra alors en profiter pour permettre également de rendre le pointé invisible, ou de le décaler horizontalement et verticalement au gré de l'utilisateur. |
|
|
| by Olivier Guillion | |
|
| |
|
Correction de la mise en couleur de la note lors du posé de coulé, du marteau, etc.
Amélioration de l'aspect de la palette Edition.
Correction du chargement des fichiers TAB textes.
Correction du chargement des fichiers Tabledit
Bon week-end ! |
|
|
| by Didier Guillion | |
|
| |
|
Un propriétaire de site nous a fait part de sa préoccupation de voir Kooplet permettre le téléchargement direct de partitions sans passer obligatoirement par les pages de son site.
Une partie de ses revenus étant tirés des bandeaux publicitaires apparaissant sur ses pages, il s'inquiétait que certains utilisateurs puissent ne jamais les visiter.
Nous avons donc réfléchi au problème, et en sommes arrivés à cette solution :
- Sur demande du propriétaire, le site peut être marqué dans les bases de données de Kooplet comme n'acceptant pas les téléchargements directs.
- Dans la version Web de Kooplet, l'icône de téléchargement des fichiers de ce site sera grisé et non cliquable. Le lien direct dans le détail du fichier disparaîtra. En terme de lien, ne demeurera que celui vers la page du site original depuis laquelle on peut télécharger le fichier.
- Dans la version de Kooplet incluse dans nos programmes, si l'utilisateur demande d'éditer un fichier appartenant à un tel site, il devra valider une boîte d'alerte le prévenant que le propriétaire du site impose de visiter la page qui contient le lien.
Si l'utilisateur refuse, l'alerte se ferme et rien n'est téléchargé.
Si l'utilisateur accepte, le fichier est téléchargé automatiquement et édité comme avant, mais en plus une fenêtre de navigateur s'ouvre, montrant la page du site demandée.
Il y a donc toujours un téléchargement direct, mais accompagné de la présentation de la page Web d'origine.
Nous attendons de savoir si cette solution convient à la personne qui nous en a fait la demande. Si cela n'était pas suffisant, nous supprimerions alors ce site de la base de données de Kooplet (environ 70000 partitions). |
|
|
| by Olivier Guillion | |
| |
|
Diverses corrections dans les scripts.
Correction d'un crash lors de l'application des nuances sur un groupe de portées.
Correction du jeu du mordant lors de l'écho en survolant la note.
Dans les premières versions d'Harmony, il n'était pas possible de changer de métrique au sein d'une partition. Aux alentours de 1996 nous avons donc "rusé" en offrant la possibilité d'avoir plusieurs partitions au sein d'un même document. Puis, Harmony a évolué et le changement de métrique a été implémenté. Nous avons gardé la possibilité d'avoir un document multi-partitions pendant une quinzaine d'année. Dans la dernière version, persuadé que plus personne n'utilisait ceci depuis belle lurette, nous avons désactivé l'option. Nous avions tort, certaines personnes utilisait encore ceci, nous l'avons donc réactivé pour la prochaine version. |
|
|
| by Didier Guillion | |
| |
|
Nous avons mis à jour nos deux produits gratuits Myriad Music Plugin (v 5.6.3d) et Melody Player (v 6.3.3d). Ils sont disponibles au téléchargement en version Windows, Mac OS et Linux.
Ces nouvelles versions corrigent quelques problèmes qui n'ont pas encore été corrigés dans Harmony/Melody, notamment une erreur d'interprétation de certaines parties conditionnelles.
|
|
|
| by Olivier Guillion | |
|
| |
|
Correction de l'affichage des tirets entre les syllabes à la fin des mesures.
MAC : Amélioration de l'affichage des onglets.
Correction de l'affichage de la position dans la musique quand on change la taille de la fenêtre.
Correction d'un problème de magnétisme des palettes en bord d'écran. |
|
|
| by Didier Guillion | |
| |
|
Sur notre machine sous Windows 8, l'écho MIDI (qui permet de faire entendre les notes jouées sur un clavier MIDI muet sur une sortie MIDI "sonore") ne fonctionne plus. Nous avons essayé de faire sortir le son d'abord sur le synthé logiciel Microsoft, puis sur un matériel MIDI, chou blanc.
Il semblerait que la fonction multimedia de Windows "MidiConnect" ne fonctionne plus. Elle est pourtant censée gérer l'écho automatiquement. Nous avons donc été obligés, afin de contourner cette défaillance, de gérer nous-même l'écho en renvoyant tout ce que nous recevons vers la sortie MIDI définie.
Comme annoncé sur le forum, il restait encore quelques problèmes de duplication de code source MyrScript lors de l'édition des scripts. Ils ont été corrigés.
Nous avions trouvé (et apprécié) Valgrind/Memcheck sur Linux, nous avons trouvé un équivalent sur Windows : Dr. Memory (qui fonctionne d'ailleurs également sur Linux). Il semble fonctionner correctement, mais nous a fourni des résultats moins intéressants. Mais ceci est peut-être dû à ce que les problèmes mémoire les plus importants avaient déjà été corrigés précédemment, lors de nos analyses par Valgrind.
Enfin, pour le week-end, soutenons moralement Sylvain, utilisateur de nos produits de longue date, et habitué du forum, qui en ce moment pédale, aidé du soleil, pour rejoindre le Kazakhstan depuis la France sur son trike solaire.
On peut le suivre sur son blog. Il a déjà traversé l'Italie, la Slovénie, la Croatie, la Serbie, et vient d'entrer en Roumanie, comme on peut le voir sur la carte des positions GPS
Bon vent à lui (ou plutôt, pas de vent mais beaucoup de soleil) et bon week-end à tous ! |
|
|
| by Olivier Guillion | |
| |
|
Il y avait un problème de localisation des métriques qui pouvait entraîner des erreurs sur certains fichiers, cela a été corrigé.
Correction d'un problème de mémoire dans la gestion des chemins.
Meilleure gestion de la localisation des coulés. |
|
|
| by Didier Guillion | |
| |
|
Nous sommes en train de mettre les version 9.6.3d / 7.6.3d à disposition sur le site.
Des corrections ont principalement été apportées à la stabilité, et à d'autres points plus mineurs comme l'édition MyrScript ou les courbes de paramètres.
Il est fortement conseillé d'utiliser cette version plutôt que la version 9.6.3c / 7.6.3c, dès que nous aurons réussi à l'envoyer sans erreur par FTP. A propos, si quelqu'un connaît un client FTP qui serait un remplaçant efficace à FileZilla, nous sommes preneurs...
La version Linux suivra très bientôt. Elle est prête, il nous reste encore à la tester, et à vérifier que nous n'oublions rien dans les packages. |
|
|
| by Olivier Guillion | |
|
| |
|
Lors du chargement de MusicXML, s'il y avait plusieurs lignes de paroles et pas de nombre de répétitions spécifié, les lignes supplementaires étaient supprimées, c'est corrigé.
Une nouvelle méthode MyrScript permet de demander la détermination de la langue la plus probable pour une portée donnée. Cette méthode est maintenant utilisée dans les importateurs de fichiers : Finale, Encore, etc.
PDFtoMusic :
Correction de l'application d'un changement de tonalité forcé par l'utilisateur.
Lorsqu'il y avait une barre de répétition en début de ligne et un changement de tonalité, celui ci était incorrect, c'est corrigé.
|
|
|
| by Didier Guillion | |
| |
|
Sur Windows, une erreur dans une tentative d'accélération de certaines fonctions de bas niveau entraîne des instabilités importantes sur la version 9.6.3c.
Un symptôme est l'impossibilité d'ouvrir la fenêtre des didacticiels. La fonction fautive a été trouvée et les accélérations (qui pourtant nous paraissaient être une bonne idée au départ) supprimées.
Ceci va nous obliger à sortir une version 9.6.3d assez rapidement.
Sur Linux, l'origine de nos problèmes a été localisée et corrigée. Nous devrions donc pouvoir sortir la version Linux de la 9.6.3d, en attendant la réécriture en profondeur de nos librairies de compatibilité pour cette plateforme.
Toujours sur Linux (mais cela va bénéficier aux autres versions), un problème grave de conception des outils de développement nous a contraint à installer toute une liste de plugins et d'extensions dans notre compilateur. Dans le lot, nous avons découvert un outil qui fonctionne étonnamment bien (ce n'est pas si courant, donc ça mérite d'être signalé): Valgrind.
Il va nous permettre de corriger tout un tas de petites irrégularités dans la gestion mémoire, qui peuvent entraîner des instabilités.
Toujours dans la démarche de rendre le code plus propre, nous cherchons à corriger l'intégralité des "warnings" de compilation, c'est-à-dire des irrégularités d'écriture en C qui ne sont pas des erreurs à proprement parler. Sur les 700000 lignes que compte le projet d'Harmony Assistant, il y avait 370 "warnings". Nous sommes tombés à 28 et nous continuons à corriger les derniers qui restent. |
|
|
| by Olivier Guillion | |
| |
|
|
