Nous avons envoyé un e-mail à tous les utilisateurs de PDFtoMusic Pro (pour l'instant, la seule version en RC1) pour leur proposer de participer aux test des versions RC avant la sortie de la version définitive. Cette demande a rencontré jusqu'ici un écho favorable, plusieurs d'entre eux nous ayant déjà proposé leur assistance. La disparité des contenus des fichiers PDF rend vraiment nécessaire des tests intensifs des préversions de ce logiciel. Nous étendrons le groupe des testeurs à PDFtoMusic non-pro dès qu'une préversion récente aura été publiée pour ce produit. Pour la petite histoire, sur certains lecteurs d'e-mails, un clic sur le lien que nous avions fourni n'amenait pas au bon endroit. Plutôt que de renvoyer un message correctif à tout le monde, nous avons "hacké" le logiciel du forum pour faire fonctionner les adresses incorrectes. L'avantage de contrôler les logiciels de A à Z coté serveur... |
|
|
by Olivier Guillion | | |
| |
|
Nous commençons à recevoir quelques retours sur la rc1. Un nom d'accord n'était pas reconnu : Faug. (Fa augmenté) il est apparu que l'analyse le découpait en Fa (latin) suivi de "ug" qui n'a pas de signification. Ceci a été corrigé. Cela devait également bloquer sur Domit5. Les tous petits liés entre deux notes très proches pouvaient être pris pour des fermata. Cela a été corrigé. A la lecture de toutes les améliorations accumulées depuis ces derniers mois nous avons décidé de passer en version 1.5.0 et non en 1.4.3. |
|
|
by Didier Guillion | | | |
|
On en voit la fin ! Une version "Release Candidate" de PDFtoMusic Pro vient d'être annoncée sur le forum. C'est donc l'une des toutes dernières étapes avant la version publique. Pour agrandir le groupe des beta-testeurs, nous envisageons de contacter par e-mail tous les utilisateurs enregistrés afin de leur proposer de nous aider, s'ils le souhaitent. Nous sommes très prudents en ce qui concerne les envois "massifs" de courriels, car nous sommes les premiers à nous insurger contre le spam ou les annonces commerciales trop insistantes. Aussi nous allons encore réfléchir un peu, et nous assurer que cela ne dérange personne avant de procéder à un tel envoi. Mais là, ce n'est pas de la pub, mais de l'info |
|
|
by Olivier Guillion | | | |
|
Il y avait un problème d'application de trémolo sur les notes à double tiges. C'est corrigé. Amélioration de la reconnaissance des dièses tracés avec des lignes. Gestion de l'accord énigmatique x2 (C2, G2...) qui sera traité comme un xadd9. |
|
|
by Didier Guillion | | | |
|
Les points suivants ont été améliorés - Les ornements "numéro de corde" (chiffre dans un cercle) étaient automatiquement noirs. La couleur choisie pour le texte est maintenant prise en compte - Tests et corrections diverses sur la saisie numérique au microphone - Correction des fonctions MyrScript d'accès direct aux données numériques (indexation de DigitalData) - Correction de problèmes en sauvegarde WAV Monophonique - Correction du script "Vocoder" Un utilisateur nous a signalé un défaut de fonctionnement du plug-in avec Firefox sur Windows 8. Cela semble lié à un problème de prise en compte du répertoire des fichiers temporaires. Nous n'avons pas été capables de reproduire ce problème, ce qui laisse à penser qu'il peut s'agir d'une mauvaise configuration du navigateur sur le poste de l'utilisateur en question. Si nous ne parvenons pas à trouver la cause de ce défaut, nous lancerons un appel sur le forum pour savoir si cela se produit chez d'autres. |
|
|
by Olivier Guillion | | | |
|
Des corrections ont été appliquées dans la localisation des ligatures fines. Dans certains cas les nuances pouvaient être associées à la mauvaise portée : on recherchait la portée la plus proche. Maintenant, lors d'une première passe, on recherche la note la plus proche et la portée est celle de la note. Ceci corrigé pas mal d'erreurs. Bon week-end ! |
|
|
by Didier Guillion | | | |
|
- Une erreur a été corrigée dans le traitement des textes. Ceci pouvait générer un crash dans la version beta - La concaténation des lettres pour former des mots pouvait ne pas fonctionner correctement lorsque les caractères étaient en Unicode. Ceci a été corrigé. - Le drapeau servant à choisir la langue du chanteur n'apparaissait pas dans le cas de partitions où le chant ne démarrait pas dans le premier système (intro avec portées chant masquées). Ceci a été amélioré. |
|
|
by Olivier Guillion | | | |
|
Parfois, l'aire d'application des tuplets est tracé avec des lignes horizontales non terminées par des lignes verticales. Or, ces lignes verticales servent à déterminer quel est le sens d'application du tuplet. Maintenant, en l'absence de ligne on regarde si le nombre est au dessus ou en dessous de la ligne horizontale pour déterminer la portée de destination. Certains PDFs utilisaient de toutes petits lignes verticales qui étaient éliminées par le dépoussiéreur. Le seuil a été abaissé afin de les conserver. |
|
|
by Didier Guillion | | | |
|
La première opération que réalise PDFtoMusic pour analyser un nouveau document, c'est de le charger et le décoder. Les objets sont extraits du PDF, décompactés, et rangés en mémoire. Le tracé graphique de toutes pages est préparé, et cela a lieu avant même que PDFtoMusic vérifie s'il voit des portées et des notes dans tout cela. Mais voila : décompacter toutes les pages, s'il s'agit d'images issues d'un scanner, cela prend de la place, beaucoup de place. Pour une résolution de 600dpi, chaque page prendra au bas mot 80Mo. 20 pages, et on dépasse allègrement le Giga-octet de mémoire. Autant dire que la zone mémoire pouvant être gérée par l'application se retrouve alors saturée, interdisant toute manipulation ultérieure de mémoire. Lorsqu'on est au fin fond des analyses de la page PDF, cela devient difficile de sortir proprement de là et de poursuivre un fonctionnement normal de l'application. Cela se solde quasi-immanquablement par un crash. Ceci se produit uniquement lorsqu'on tente de traiter des collections de pages scannées, qui ne pourront de toute façon pas être gérées par PDFtoMusic. Nous avons donc amélioré toutes nos fonctions de manipulation mémoire, afin de leur faire tenir le compte de la quantité de mémoire utilisée. Ainsi nous pouvons à tout moment savoir si la mémoire disponible baisse dangereusement. Nous avons mis une limite à partir de laquelle le processus de chargement du PDF est abandonné et un message d'erreur affiché. Ainsi, les fichiers PDF très volumineux, contenant de nombreuses pages scannées en haute précision ne feront plus planter l'application. Un message clair apparaîtra, et le fichier PDF ne sera simplement pas chargé. |
|
|
by Olivier Guillion | | | |
|
Dans certains cas, le trémolo sur la tige pouvait être traité comme une ligature et affecter la durée de la note. C'est corrigé. Il y avait un problème dans l'application des tuplets, c'est corrigé. |
|
|
by Didier Guillion | | | |
|
Pour finir la semaine, nous avons : - réglé quelques problèmes de volume en sortie sonore haute qualité - corrigé plusieurs problèmes dans le sélecteur de modèle lors de la création d'un nouveau document - Ajouté et géré le bouton de réglage de la position avant-arrière des sons (fader) dans les deux tables de mixage : Nous avons résolu pour l'instant le problème de l'intitulé de ce curseur en le symbolisant par des flèches vers le haut et vers le bas. Bon week-end à tous ! |
|
|
by Olivier Guillion | | |
| |
|
Nous travaillons toujours sur les exports audionumériques de haute qualité. Voila où nous en sommes : Format brut (brt) : ce format étant simplement consitué des données sans descriptif du contenu, on peut y écrire n'importe quel type de données audio. Format WAV : La version étendue a été finalisée. On peut y stocker des données audio jusqu'à 96 kHz, 32 bits, 8 canaux (7.1), c'est-à-dire le maximum que peut gérer la nouvelle sortie audio d'Harmony Assistant Format AIFF : Nous avons suivi les documentations décrivant ce format, et avons pu stocker des données jusqu'à 96kHz. Par contre, les échantillons de 32 bits sont théoriquement possibles, ainsi que la quadriphonie (4.0), mais les essais de fichiers se soldent par une erreur dans Windows Media Player. Est-ce une erreur de notre part ou un problème dans ce logiciel ? Nous devons faire des essais sur Mac pour nous en assurer. Format MP3 : trop compliqué pour gérer les formats de haute qualité. Les défauts de compression rendent de toute façon les formats en haute fréquence ou nombre de bits élevés assez peu utiles. Nous convertissons donc en 44 kHz, 16 bits, et au maximum en stéréo (2.0) avant de compresser. Format OGG : pas encore traité, mais il est probable que nous devions procéder comme pour le MP3. En résumé, le format WAV permettra de stocker n'importe quel type de données audio. Pour preuve, l'exemple suivant, contenant des sons en 96 kHz, 32 bits, 6 canaux (5.1). C'est du lourd. Une seconde de son occupant 2.2 Mo, le fichier ci-dessous fait donc la bagatelle de 13,4 Mo ! Si vous l'écoutez sur un simple casque ou deux haut-parleur, votre système devrait vous faire entendre les sons censés être dans votre dos avec un volume réduit. Son WAV 96kHz, 32 bits, 5.1 Avec un peu de chance, vous devriez entendre une gamme, avec chaque note provenant d'une position spatiale différente, selon le schéma suivant : Cet export WAV nous a permis de visualiser les données audio canal par canal, et de corriger des erreurs de répartition spatiale de la nouvelle sortie sonore d'Harmony difficilement repérables à l'oreille (les sons arrière "bavaient" sur l'avant). |
|
|
by Olivier Guillion | | |
| |
|
Nous commençons à avoir les premiers retours sur la version beta. C'est globalement positif mais certains détails sont encore à régler. Certains de ces retours se faisant sur des orchestration complètes de musique de film, l'analyse est délicate. Le symbole de trémolo simple (barre en travers de la tige de la note) pouvait être pris pour le symbole de répétition interne de mesure, c'est corrigé. Le même symbole pouvait être traité à la fois comme un trémolo et une tête de note "flash" (en barre), c'est corrigé. |
|
|
by Didier Guillion | | | |
|
À plusieurs endroits dans le programme (environ 5 ou 6), nous utilisons le format de fichier audio "WAV" pour écrire ou lire des données sonores. Ce format est relativement simple, aussi la gestion du format a été réécrite à chaque fois. Mais maintenant, une variante du format, permettant de stocker des échantillons sonores multicanaux (5.1), ou des fréquences d'échantillonnage ou des tailles d'échantillons élevées doit être prise en compte. Plutôt que de réécrire cette prise en charge du nouveau format 5 ou 6 fois, nous normalisons en ce moment les accès aux fichiers WAV. Ainsi, il sera possible d'exporter les données audio de la partition au format natif de la sortie numérique fixé par l'utilisateur, jusqu'à 96kHz, 32 bits, en 8 canaux. Dès que ce sera terminé, nous vous proposerons ici quelques extraits simples créés avec Harmony, que vous pourrez essayer sur votre système audio, et en surround si vous êtes équipé. |
|
|
by Olivier Guillion | | | |
|
Correction du calcul de l'attribution des pointés aux notes. Correction d'un problème lors du jeu d'une liste de mesures imposées. Correction d'un problème d'attribution d'accroche. |
|
|
by Didier Guillion | | | |
|
Depuis quelques jours, nous avons vu apparaître de nouveaux utilisateurs sur le forum, aux profils trop similaires pour être honnêtes. Un pseudo constitué d'un simple prénom (souvent féminin), et une adresse électronique chez un fournisseur peu regardant (hotmail, yahoo, live.com, outlook.com, etc). Nous en avons supprimé plusieurs dizaines en 5 jours. Une vérification dans nos fichiers-journaux nous ont montré des milliers de tentatives de création de profil de ce type ces derniers mois. Tous, jusqu'ici, s'étaient heurtés à notre "captcha", l'image contenant 5 lettres que l'utilisateur doit entrer : Mais, nouveauté, certains essais, environ un sur 100, sont maintenant couronnés de succès. S'agit-il d'un robot qui a perfectionné son algorithme de reconnaissance optique ? Le Journal du Net propose très sérieusement un comparatif de ces "outils", ne relevant jamais le caractère nuisible et à la limite de la légalité de ce genre de pratique. Une preuve de plus que lorsqu'il s'agit d'économie, même numérique, la morale s'efface devant le profit, et empoisonner la vie de milliers de personnes ne semble soulever aucune objection, sous prétexte qu'aucune loi ne le punit encore. Écoeurant. Peut-être s'agit-il d'opérateurs humains ? Des sociétés se sont montées, spécialisées dans le cassage de captcha. En pratique, vous envoyez l'image à un service employant des personnes qui résolvent la question et renvoient les codes qu'ils ont déchiffré. C'est 12 dollars pour 10000 captchas résolus. Alors nous envisageons les diverses possibilités. Demander à l'utilisateur de répondre à une question liée à notre activité ? Mais en quelle langue ? Il nous semble qu'un captcha animé, programmé en HTML5, permettrait à la fois d'éviter le décryptage par un robot, et l'utilisation de service à distance, qui ne peut pas réagir en temps réel à l'animation. Nous y réfléchissons sérieusement. En attendant, nous interdisons les inscriptions sur le forum utilisant une adresse e-mail d'un service anonyme. Nous avons constitué à cet effet une liste d'une bonne centaine de services de ce type. Cela devrait déjà limiter les dégâts, en attendant le captcha ultime. Bon week-end ! |
|
|
by Olivier Guillion | | | |
|
Une notion de MusicXML avait été mis en attente : le rehearsal. C'est un texte destiné aux répétitions. Le terme répétition devant être pris ici comme "entrainement d'un orchestre". La confusion avec les symboles de répétition est grande et de fait cette notion s'appelle "Repère" dans Harmony. Nous avons implémenté la sauvegarde des repères en MusicXML ainsi que leur chargement. Dans PDFtoMusic, ces textes (souvent encadrés) étaient traités comme des textes libres. Maintenant l'utilisateur peut les forcer en "repère". Il faudrait que PDFtoMusic soit capable de les localiser automatiquement mais cela va être chaud ! |
|
|
by Didier Guillion | | | |
|
Comme annoncé précédemment, les nouvelles possibilités des pistes numériques (fréquence d'échantillonnage et/ou taille d'échantillon élevées) nécessitent de reprendre, ou tout au moins de vérifier tous les scripts MyrScript qui travaillent sur les données de ces pistes. Parmi les scripts fournis par défaut, il s'agit de tous ceux situés dans la section "Son numérique" du menu des scripts. Nous nous sommes attelés à cette tâche, mais les scripts sont nombreux et assez complexes. Ci-dessous, la liste des vérifications ou corrections à appliquer aux scripts. Si vous avez écrit de tels scripts pour votre usage personnel, pensez à vérifier tout cela. Dorénavant : Les pistes numériques ne sont plus nécessairement en 16 bits à 44 kHz. L'échantillon peut être de 8, 16, 24 ou 32 bits, et la fréquence d'échantillonnage peut aller de 11 à 96 kHz. Les sons numériques des instruments peuvent également dépasser 16 bits (24 ou 32) et la fréquence d'échantillonnage peut être supérieure à 44kHz (48 ou 96) Par conséquent : Lors de la manipulation de pistes numériques en MyrScript, il est conseillé d'utiliser les valeurs normées (NormalizedDigitalData) plutôt que les valeurs natives (NativeDigitalData) pour traiter toutes les tailles possibles d'échantillon avec les mêmes fonctions. Les rawtables qui reçoivent les valeurs doivent donc impérativement être en virgule flottante (RAW_TABLE_FLOAT) et non entières (RAW_TABLE_LONG) Il faut vérifier que lors du stockage d'une valeur, elle n'est plus transformée en entier. Typiquement, un arrondi pouvait être effectué sur les valeurs natives par floor(val+0.5). Ceci doit être supprimé. Les valeurs vont donc de -1 à +1 au lieu de -32768 à 32767. Les calculs doivent en tenir compte La fréquence d'échantillonnage n'est plus nécessairement à 44 kHz. Il faut en tenir compte dans les tailles de bloc destinées aux calculs de transformées de Fourier (FFTBlock), ainsi que dans l'analyse et l'interprétation du spectre résultat. De même, le calcul des bornes de sélection sur une piste numérique doit être vérifié. Cela pouvait être quelque chose comme : t1=score.TimeBeginSelection t2=score.TimeEndSelection startIndex=1+score.PlayedTimeToMs(t1)*44.1 endIndex=1+score.PlayedTimeToMs(t2)*44.1 Cela devient (si data désigne les données de la piste numérique): t1=score.TimeBeginSelection t2=score.TimeEndSelection startIndex=1+score.PlayedTimeToMs(t1)*data.SampleRate/1000 endIndex=1+score.PlayedTimeToMs(t2)*data.SampleRate/1000 Toutes ces informations seront postées sur le forum MyrScript lors de la sortie de la prochaine version beta. |
|
|
by Olivier Guillion | | | |
|
La librairie musicale a enfin été liée avec succès à PDFtoMusic. Une retouche a été faite dans l'analyse des chemins en double. Une beta version de PDFtoMusic (beta 7) a été publiée. |
|
|
by Didier Guillion | | | |
|
Nous préparons une version beta de PDFtoMusic (Pro, dans un premier temps), très attendue par certains beta-testeurs. Karma ou hasard, cette version beta ne semble pas y mettre du sien. Cela fait plusieurs fois que nous la préparons, mais qu'un problème de dernière minute retarde sa sortie. Cette fois, il s'agit d'un problème de jeu de la musique. Rappelons que PDFtoMusic utilise, pour jouer le morceau, une large partie des fonctions audio d'Harmony Assistant, et que ces dernières ont été récemment reprises afin de gérer les modes de haute qualité. La version beta de PDFtoMusic inclut donc une version beta des fonctions audio, ce qui multiplie les possibilités de problème. Nous travaillons là-dessus, et espérons pouvoir sortir cette version betarlésienne dès demain. |
|
|
by Olivier Guillion | | | |
|
Pour finir la semaine : Dans Harmony L'inversion du crochet du tuplet ne fonctionnait pas lors du changement de l'apparence de plusieurs symboles à la fois, c'est corrigé. Correction d'un problème d'affichage dans la boite de changement de l'apparence. Dans PDFtoMusic, le nouvel algorithme de raboutage des coulés a été testé avec succès. Bon week-end ! |
|
|
by Didier Guillion | | | |
|
Nous allons voir au travers d'un exemple assez significatif comment PDFtoMusic progresse petit à petit et comment les algorithmes de compréhension de la notation musicale s'affinent. L'exemple suivant nous a été proposé par un utilisateur : On voit que le coulé a bien été reconnu en début de deuxième ligne (en vert) mais ignoré en fin de première ligne. Pourquoi ? PDFtoMusic essaie d'abord d'associer un coulé à une note de début et à une note de fin selon les critères de distance définis dans le mode expert. Si ces deux notes sont localisées, les notes sont marquées comme début et fin et on considère que le traitement est terminé pour ce coulé. S'il manque le début ou la fin, on considère que le coulé franchit vraisemblablement une fin de ligne ou une fin de page et qu'il est "cassé". Il est donc collecté pour un traitement ultérieur qui essaiera de rabouter tous ces coulés brisés. Dans ce cas précis, le premier coulé est cassé : la note de fin est trop éloignée de la fin du coulé mais le deuxième coulé est parfait : note de début et note de fin sont correctes. On ne cherchera jamais à corriger un coulé brisé avec un coulé complet, le premier coulé est perdu. D'un point de vue notation, il aurait peut être plus judicieux de faire déborder le deuxième coulé sur la gauche pour bien faire comprendre qu'il s'agissait d'une continuation. Mais bon. Nous cherchons donc une solution et essayons ceci : quand un coulé est complet mais qu'il débute une ligne, il est marqué comme tel. Puis, dans le traitement des coulés brisés, on examine également les coulés de catégorie "parfait, mais...". Sur l'exemple cela fonctionne. A valider maintenant sur de nombreux documents pour voir si cela ne va pas fusionner des coulés qui ne devraient pas l'être. |
|
|
by Didier Guillion | | | |
|
Nous avons travaillé à recréer la librairie de jeu de la musique pour la rendre compatible avec PDFtoMusic. Des problèmes de suivi de coulé nous ont été soumis via un exemple clair. Nous y travaillons dessus. |
|
|
by Didier Guillion | | | |
|
|