Myriad Blog 1.3.0 Thursday, Aug 28th, 2014 at 07:14am 

Dev News Wednesday, Feb 28th, 2007 at 04:53pm
PDFtoMusic étape 168

 
Un nouvel algorithme permet de rabouter les différentes composantes du nom des accords lorsque celles ci ne sont pas alignées verticalement, comme dans cet exemple de M Machefert :
 

 
Des problèmes de clavier sur MacTel ont été corrigés, il sera possible d'interrompre un calcul par appui sur la touche d'échappement.
 
Le transfert des projets vers le MacPro se poursuit. Comme décrit dans ce carnet de route, le transfert via afp d'arborescences complêtes "oublie" des fichiers. Mais apparemment, ce n'est pas le cas si l'on "zippe" le dossier et extrait l'archive sur le MacPro...
by Didier Guillion
 2 comments.

Myriad Life Tuesday, Feb 27th, 2007 at 04:47pm
Mon nouveau Mac ! - Etape 6

 
Aujourd'hui rien de passionnant : transfert des projets sur le MacPro et reconstruction avec XCode.
by Didier Guillion
 7 comments.

Myriad Life Monday, Feb 26th, 2007 at 05:04pm
Mon nouveau Mac ! - Etape 5

 
J'ai reçu mon nouveau Mac ! 2x2.66 Ghz Dual Core Intel Xeon 2Go de RAM avec deux disques montés en RAID. C'est rapide, très rapide !
La compilation complète du projet PDFtoMusic en mode non optimisé prends 45 secondes...
Chipoter pour quelques secondes semble un peu futile, mais quand un programmeur compile soixante fois son projet dans la journée, sachant qu'il ne peut guère faire grand chose pendant ce délai, gagner une minute fait gagner une heure de travail...
Je change de Mac environ tout les trois ans, et à chaque fois je double la vitesse. Maintenant il reste à transférer trois ans de travail sur la nouvelle machine. Au passage le transfert via afp:// est complètement loufoque. Comment imaginer qu'un OS digne de ce nom oublie des fichiers ! Et c'est pourtant le cas, sans avertissement, je me retrouve avec des fichiers manquants dans mon arborescence...
by Didier Guillion
 5 comments.

Dev News Friday, Feb 23rd, 2007 at 04:35pm
PDFtoMusic étape 167

 
Nous avons analysé les tests d'hier montrant que le MacPro est plus lent que le PC. Le pourcentage d'occupation des processeurs sur PC est de 50% contre seulement 25% pour le MacPro : un seul des quatre coeurs est utilisé en même temps. Donc en fait, sauf si l'application est conçue pour le multi-tâche, avoir plusieurs coeurs ou processeurs ne l'accélèrera pas, car de toute façon elle n'utilisera qu'un coeur. C'est uniquement la fréquence du processeur qui peut faire gagner et bien sur, l'optimisation du code.
 
Je dirait qu'à première vue, le compilateur GCC utilisé par XCode est beaucoup plus à l'aise avec la technologie des processeurs Intel qu'avec celle de Motorola. Quant à CodeWarrior (produit par MetroWerks qui était une filiale de Motorola) il se défend bien sur tous les tableaux.
 
Nous continuons à optimiser la vitesse de traitement, sur Mac mais aussi sur PC.
Le lot de fichier de fichier PDF de référence a été converti en .myr en 5mn 15 sec sur MacPro (la version publique donne 8mn 04 sec) et 5 mn 20 sur PC.
L'on voit que c'est surtout le coté Mac qui à gagné (près de 35%). Nous avons activé certains modes de calcul des nombres à virgule et cela a été efficace.
by Didier Guillion

Myriad Life Thursday, Feb 22nd, 2007 at 04:55pm
Mon nouveau Mac ? - Etape 4

 
Voici les tests de vitesse sur un lot de 23 fichiers PDF complexes, effectués avec la version publique de PDFtoMusic Pro.
 
Windows XP Intel CoreDuo 2.66, compilé avec CodeWarrior : 7 mn 18 sec
MacPro 2x2.66 Ghz Dual Core Intel Xeon 1Go de RAM, compilé avec XCode : 8 mn 04 sec
by Didier Guillion

Myriad Life Thursday, Feb 22nd, 2007 at 04:41pm
Mon nouveau Mac ? - Etape 3

 
Ca y est, cela se compile, et se deboggue ! Les problèmes venaient du fait que, apparemment, sur MacTel le deboggage d'une application ne peut se faire que dans un bundle (paquet) complet.  
J'en ai profité pour brancher deux écrans et corriger les problèmes d'agrandissement de fenêtres soulevés par M Puff à l'étape 164. Au passage, l'ouverture d'un tiroir redimensionne maintenant la fenêtre dans les deux sens.
Quelques astuces vont également nettement améliorer la vitesse de traitement pour la prochaine version que ce soit sur Mac ou sur PC.
Nous allons maintenant faire quelques courses de vitesse entre notre PC le plus rapide et le MacPro.  
 
(...)
by Didier Guillion

Myriad Life Thursday, Feb 22nd, 2007 at 01:49pm
Mon nouveau Mac ? - Etape 2

 
CodeWarrior, c'est fini, salut l'ami...
 
En guise de test, le projet CodeWarrior de "PDFtoMusic" est transféré sur le MacPro.
Comme je le craignais, et bien que la compilation se passe bien sous CodeWarrior, impossible de débogger une application PPC sous MacTel.
CodeWarrior bloque sur "Loading Symbols".
Bonne performance tout de même, le même projet se compile 50% plus vite entre un un G4 bi pro et un MacPro, n'oublions pas que CodeWarrior tourne en émulation Roseta.  
 
La piste XCode.
 
Puisque XCode est maintenant la seule plateforme de développement sur Mac, la question devient, est- il enfin utilisable ?
Un projet type, "PDFtoMusic" est transféré sur le MacPro et la compilation est tentée. Le transfert se passe beaucoup moins bien que celui du projet CodeWarrior. En fait, XCode a mémorisé de nombreux chemins sur des fichiers en absolu. Après quelques heures d'essais infructueux. Je choisis de regénérer le projet XCode depuis zéro à partir du projet CodeWarrior. Il me faut également regénérer de la même façon toutes les librairies associées. Ouch !
Enfin, j'obtiens une application qui se compile et se lance.
L'interface d'XCode est plutot agréablement réactive...  
Le temps de compilation est très prometteur. En version non optimisée je passe de 74 secondes sur le G4/CodeWarrior a 27 secondes sur le MacPro/Xcode.
 
Et là nouveau problème, l'application se lance sous deboggueur mais perd son "focus", elle ne reçoit plus aucun événement.
Certainement une option d'XCode que je n'ai pas comprise, il reste du travail.
 
(...)
by Didier Guillion

Myriad Life Thursday, Feb 22nd, 2007 at 06:12am
Mon nouveau Mac ? - Etape 1

 
Aujourd'hui, grand jour.  Philippe m'a prété un Mac Pro pour faire des tests. Je dois vérifer, avant d'en acquérir un, si mes outils de développement fonctionnent dessus et à quelle vitesse. Pour XCode je ne m'inquiète pas trop, pour CodeWarrior, un peu plus. Comme il va tourner sous Roseta, va-t-il pouvoir accéder au déboggeur GDB ? Si ce n'est pas le cas, je suis mal... Je me vois mal opter pour XCode, mais peut-être sur une machine un peu rapide est-il enfin utilisable ? Sur un G4 bi, en tout cas, c'est "pizza" toutes les trente secondes.
 
La machine est sur le bureau (2x2.66 GHz Dual Core Intel Xeon 1Go de RAM), connectée sur le réseau en quelques secondes, le démarrage est simplissime. La coque métal fait solide. Grande satisfaction : pour une fois Apple à pondu une machine vraiment silencieuse (pas que dans leur pub). Agréable.
 
Installation des outils de développement
 
Codewarrior s'installe et se lance sans problème. Bien sûr il crie que GDB n'est pas présent. Il faut maintenant obtempérer et installer XCode.
 
Mon CD original de Mac OS X 10.4, contient une version trop ancienne de XCode (antérieure aux MacTels), je ne peux donc l'utiliser, je vais donc le télécharger sur l'ADC.
 
Le téléchargement d'XCode sur le site Apple a été une source de gags Kafkaiens. L'image disque fait 923 Mo et prend, quand tout se passe bien, 19 minutes pour se transférer (21 heures quand la connexion est faible). Or, les as de la sécurité chez Apple on décidé de déconnecter les membres "sans activité" au bout de 15 minutes !  Au cinquième téléchargement interrompu à 15 minutes, je décide d'essayer de faire semblant d'être en activité. Alors pendant 19 minutes, je clique sur des éléments de leur site au hasard... Ca ne change rien... Echec.
Je passe sur mon G4, et j'essaie de télécharger. Cela fonctionne du premier coup. Hasard ?  
L'installation se passe bien.
 
 
Passage des projets et des sources
 
Le transfert via le réseau Mac OS X (afp) est un enfer. Tous les trois fichiers/dossiers j'ai des erreurs de droits d'accès que je dois corriger à la main via le Finder et une fois sur deux cela ne change rien ! Facile de faire un système sécurisé quand la moindre opération comme ne serait-ce que copier un fichier ou changer son extension demande une confirmation à l'utilisateur...
 
Je pense avoir tout transféré, maintenant place à la compilation.
 
(...)
by Didier Guillion

Dev News Thursday, Feb 22nd, 2007 at 05:27am
PDFtoMusic étape 166

La nouvelle version de PDFtoMusic a été validée et postée sur le site. Le petit mot du jour n'a pas eu le temps de naitre...
by Didier Guillion

Dev News Tuesday, Feb 20th, 2007 at 04:55pm
PDFtoMusic étape 165

 
Aujourd'hui, correction de problèmes mineurs. La version 1.0.2 est en cours de validation sur nos fichier PDF de référence (cela prends en général une bonne douzaine d' heures). Si tout se passe bien, la version publique devrait être disponible très bientôt. Vraisemblablement une nouvelle version d'Harmony et du Plug-In devrait être proposée simultanément.
by Didier Guillion

Dev News Monday, Feb 19th, 2007 at 04:18pm
PDFtoMusic étape 164

 
- M Puff nous a signalé des problèmes de manipulation de fenêtres sur les Macintosh avec plus d'un écran. Je vais essayer de me faire prêter une machine pour pouvoir corriger cela : pour l'instant mon Mac ne supporte qu'un écran.
En attendant, la gestion du mode "plein écran" tient maintenant compte du fait que le tiroir soit ouvert ou non.
 
- Quelques ajustements mineurs ont été fait : La concaténation des nuances vérifie la logique du résultat ce qui empèche par exemple de fusionner "mf" et "sfz".
 Les textes encadrés pouvaient perturber les indicateurs de passage, ceci a été corrigé.
 
- Enfin  M Miconnet nous a soumis un fichier intéressant où les lignes additionnelles sont presque aussi épaisse que les accroches :
 

 
Ceci a été ajusté pour la prochaine version.
by Didier Guillion

Dev News Friday, Feb 16th, 2007 at 04:54pm
PDFtoMusic étape 163

 
- M Puff a signalé un problème intéressant : il n'est pas possible de changer à la fois la durée d'une note et le pointé associé. Ceci sera amélioré dans la prochaine version.
 
- M Nicoll nous a proposé une partition où le barré sur les appogiatures était considéré comme une note. Ceci sera corrigé.
 
- Un algorithme spécial a été implementé pour recalculer les sens des tiges des notes en accord. Ceci améliore grandement l'aspect final de nombreux fichier PDF.
 
- Afin d'uniformiser les changements d'échelle avec les autres logiciels, l'échelle 100% est maintenant accessible via le raccourci Commande+1. Une échelle à 200% a été implementée via Commande+2.
 
- Lors de l'export au format Harmony Assistant, l'indicateur "Ne pas imprimer les portées vides" n'est positionné que si au moins une portée est marquée comme cachée dans le fichier MusicXML
 
- La prise en compte du nom des groupes (et de leur nom abrégé) a été améliorée.
by Olivier Guillion
 1 comment.

Technical Thursday, Feb 15th, 2007 at 05:11pm
Ah, DéSoLé...

L'ADSL utilise votre ligne téléphonique pour vous connecter à l'Internet à haut débit. Mais cette technologie est assez sensible à la distance qui vous sépare de votre NRA (Noeud de Raccordement Abonné), le centre de FT (on doit dire Orange, maintenant ?) où aboutissent toutes les lignes du quartier.  
 
Jusqu'à 1500 m, vous êtes au top, jusqu'à 2500 m, c'est moyen, et au-delà, les problèmes commencent. Plus de "très haut débit", et selon la qualité de la ligne (diamètre des fils, qualité des connexions, etc) cela peut virer à la catastrophe.
 
Ici, à Myriad, nous sommes à environ 1km de notre NRA (MIN31), ce qui nous permet d'avoir une connexion rapide et sans problème. Mais, comme vous le savez peut-être, nous allons dans peu de temps déménager ailleurs dans le quartier.
 
Tout paraissait bon. La nouvelle adresse était située à moins de 1500m du NRA "MIN31"(Minimes). Mais voila, les câblages de FT sont parfois étonnants, et il semblerait que certains abonnés de la rue Montaigne (et l'ancien propriétaire de la maison était dans ce cas) soient connectés à "Capitole", à plus de 2,5 km.  Donc, adieu très haut débit, et bonjour aux ennuis qui se profilent, en comptant sur la loi de Murphy.  
 
Il y a même des maisons dans la rue, avec 3 lignes, dont 2 sont sur Capitole, et une sur Minimes
 
Alors comment s'y prendre pour faire en sorte d'être reliés au bon ? Contacter (ou soudoyer) FT ? Ouvrir 4 lignes pour les obliger à recâbler, et en résilier 2 ? Acheter un garage bien placé, y faire poser le téléphone, et mettre une liaison WIFI ?  
 
Si quelqu'un a une solution, des contacts ou une idée géniale, nous sommes preneurs. Notre usage d'Internet étant plutôt du genre "intensif", c'est une question vitale ...
 
Note : pour connaître le NRA et la distance, pour ceux qui ne savent pas, il y a http://www.degrouptest.com.  Avec les pages blanches ou jaunes, on fait des miracles.
by Olivier Guillion
 7 comments.

Dev News Wednesday, Feb 14th, 2007 at 04:13pm
PDFtoMusic étape 162

 
Un problème assez casse tête de notes accrochées avec double tige à été résolu. Une jolie palette de problèmes mineurs a été corrigée, une prochaine sous version devrait être disponible en début de semaine prochaine.
Nous commençons a réfléchir (enfin surtout Olivier) au traitement d'images matricielles (bitmap).  
 
M Peter Deutsh (un des initiateurs du projet GhostScript) nous a envoyé un gentil email. Il avait démarré en 2003 un projet similaire a PDFtoMusic, écrit en Python, appellé Musix, qu'il n'a jamais pu finaliser. Dommage pour lui. Un entretien intéressant à propos de GhostScript est disponible ici :
 
http://devlinux.org/deutsch-interview.html
by Didier Guillion
 1 comment.

Dev News Tuesday, Feb 13th, 2007 at 04:45pm
PDFtoMusic et autre, étape 161

 
Aujourd'hui pas mal d'ajustements et de corrections de problèmes mineurs sur PDFtoMusic et Harmony Assistant.
Dans PDFtoMusic un nouveau paramétrage du mode expert fait son apparition : épaisseur maximale des accroches.
Dans Harmony Assistant, sur requète justifiée de Sylvain, possibilité de définir le texte des objets textes associés aux notes dans la boite de changement de l'aspect général.
Sur PDFtoMusic nous continuons a réfléchir sur la possibilité de traiter les tuplets sous entendus. Nous recherchons un algorithme efficace et je pense que nous progressons.
Très bientôt nous allons mettre en chantier la reconnaissance des partitions sous forme d'image. Cela va être un gros chantier. Je prévois une sortie pour Septembre...
by Didier Guillion
 2 comments.

Dev News Monday, Feb 12th, 2007 at 05:16pm
PDFtoMusic, étape 160

 
- Un cas très intéressant proposé par M Miconnet : le mélange dans une même partie de notation en barres et de notation conventionnelle.  

 
 
- M Good nous à soumis quelques problèmes qui ont été corrigés :
 Reconnaissance des tenuti
 Lié dans coulés
 Reconnaissance silence de brève
 Affichage, édition, exportation des tempi
 
- Enfin merci de vos cogitations sur le schéma d'explication. Je pense que la démarche de Sylvain sur le forum est bonne : proposer le schéma quand quelqu'un pose la question et voir si cette personne comprend.
by Didier Guillion

Dev News Friday, Feb 9th, 2007 at 05:08pm
PDFtoMusic, étape 159

 
- Nous travaillons sur la prochaine version de PDFtoMusic. L'algorithme de concaténation de chaines pour reformer les noms des accords, décrit à l'étape précédente a été implémenté. Il "récupère" pas mal d'erreurs. Au passage le symbole "degré" n'était pas traité, c'est maintenant corrigé.
Il apparait que certains polices (comme la JazzChord) utilisent une façon un peu exotique de représenter les symboles. Par exemple pour noter exemple "-7" elles n'utilisent pas le "-" suivit du "7" mais un seul caractère qui contient "-7". Il n'y a aucune correspondance avec l'Unicode et la seule façon de pouvoir traiter cela serait de faire un module de reconnaissance spécifique à chaque police. A étudier.
 
- Nous reprenons les documents complexes fournis par les utilisateurs et qui étaient restés en attente car nécessitant des modifications de bas niveau et les traitons un par un. Chacun recevra une réponse... dès que nous en aurons une !
 
- Enfin, M Faivre nous propose une nouvelle version de son diagramme :
 

by Didier Guillion
 21 comments.

Dev News Thursday, Feb 8th, 2007 at 04:23pm
PDFtoMusic, étape 158

 
La nouvelle version de PDFtoMusic, v1.0.1, est disponible. Pas mal de corrections de problèmes, mais aussi les améliorations décrites dans ce carnet de route depuis la semaine dernière.
Nous avons pas mal réflechi à la manière d'annoncer qu'un document PDF ne pouvait être traité car, apparemment, il y avait pas mal de confusions. Nous espérons que la nouvelle présentation de ce cas sera plus claire.
 
M Faivre nous a soumit un diagramme à afficher dans le manuel pour expliquer les interconnections entre les formats de fichier et les logiciels :
 

 
Merci à lui, car ce n'est vraiment pas évident ! Qu'en pensez vous ?
 
Dans cette version, nous avons essayé de toucher au minimum au "moteur" interne de la reconnaissance, c'est surtout des améliorations ergonomiques qui ont été appliquées.
 
Si aucun problème n'est rencontré avec cette version, nous allons pouvoir essayer d'améliorer certains algorithmes. Par exemple M Baret (aka Groromrom) nous a signalé à maintes reprises des noms d'accord non reconnus. Ceci est du au fait que PDFtoMusic ne concatène les textes que si les caractéristiques de la police (nom, taille, casse) sont identiques. Or, certains fichiers notent les accord comme "Cm7" avec un "C" d'une taille supérieure au "m7".
 
Nous gardons a l'esprit d'améliorer le système de recherche de PDF musicaux sur l'Internet, déjà présent dans "Internet>Rechercher une partition", qui se contente d'envoyer une requète à Google. Nous envisageons de construire un automate qui balayerait les pages sur l'Internet, extrairait les PDF, déterminerait s'il s'agit de "vrais" PDF et les indexeraient dans une base de donnée sur notre serveur.
Ainsi, une recherche de partition donnerait toujours un PDF valide et exploitable, sélectionnable dans une liste avec peut-être une petite image montrant la première page. Nous savons comment faire, il nous faudrait juste un peu de temps pour l'implémenter.
by Didier Guillion
 13 comments.

Dev News Wednesday, Feb 7th, 2007 at 04:35pm
PDFtoMusic, étape 157

 
- Sur suggestion de M Puff, dans l'export par lot, il est maintenant possible de définir les corrections au mode de calcul qui seront appliquées à l'ensemble des fichiers traités.
 

 
- Lors de l'édition des paramètres "expert", le nom des rubriques dont au moins un élément a changé par rapport aux valeurs de référence s'affichent d'une couleur particulière. Pour chaque valeur modifiée, la différence à la valeur de référence s'affiche également.
Ceci permet de localiser rapidement les paramètres modifiés.
 
by Didier Guillion
 6 comments.

Dev News Tuesday, Feb 6th, 2007 at 04:59pm
PDFtoMusic, étape 156

 
- M Puff traque les erreurs dans la documentation Anglaise. Nous avons des demandes pour une version en Allemand de PDFtoMusic, nous nous y lancerons dès que le manuel sera vraiment totalement finalisé.
 
- Voici les modifications apportées à PDFtoMusic aujourd'hui :
Amélioration de la reconnaissance des métriques
Amélioration de la reconnaissance des paragraphes pour les textes libres
Mise à jour des bases de données pour l'OCR des polices.
Correction : Taille des nuances
Correction : Détermination du type de fichier selon l'extension lors de l'export.
Correction : Périphérique de sortie associé à l'instrument lors de la génération des .myr
Correction : Export MusicXML de la "slash notation"
 
- Enfin, une astuce. Pour l'instant PDFtoMusic ne gère pas les documents PDF avec rotation, comme dans cet exemple fourni par un utilisateur, M Tubb.
 

 
Mais une manip assez simple permet de le traiter tout de même : chargez le dans un visualiseur de PDF, appliquez la rotation et "imprimez le" comme un nouveau fichier PDF. Il sera traité sans problème par PDFtoMusic.
by Didier Guillion
 1 comment.

Dev News Monday, Feb 5th, 2007 at 04:39pm
PDFtoMusic, étape 155

 
- M Puff, nouveau dans ce projet (bienvenue à lui) nous a envoyé d'abondants et pertinents rapports ce week-end, ceci a engendré de nombreuses modifications en vue de la prochaine version publique. Associés aux rapports de MM Good, Machefert, Faivre et autres utilisateurs, voici ce que cela donne :
 
- Amélioration : après édition du mode expert, possibilité de recalculer tous les documents ouverts.
- Amélioration : lorsque l'on défini un nouveau type de tuplet il se rajoute dans la liste des valeurs de tuplet.
- Amélioration : les fichiers .myr sont maintenant compactés.
- Amélioration : Chapitre "Comment créer des PDF sous Mac OS 9" dans le manuel.
- Amélioration de la recherche des numéros de mesure
 
- Correction de problèmes divers dans les préférences générales
- Correction de problème pouvant survenir lors de l'édition de documents non vectoriels
- Correction de boucle infinie lors du choix d'un tuplet utilisateur
- Correction : choix des pages à exporter pour les formats autres que le MusicXML
- Correction : Les barres doubles de fin de mesure étaient parfois mal reconnues
 
La documentation a été mise à jour sur le Net.
by Didier Guillion

Dev News Friday, Feb 2nd, 2007 at 04:36pm
Projet PDFtoMusic, étape 154

 
- La journée s'est passée à référencer PDFtoMusic sur l'Internet et c'est toujours un peu long, heureusement les fichiers PAD sont maintenant de plus en plus reconnus.
 
- Les rapports d'erreur sur les modules d'importation d'Harmony Assistant sont en cours de traitement. Là aussi, cela demande beaucoup de temps. L'importeur Encore devrait mieux fonctionner.
 
- Comme expliqué dans l'étape 146 de ce carnet de route, nous avons implémenté un système de compression des fichiers MusicXML pour faciliter leur échange et leur utilisation via le Myriad Music Plug-in (le format .xmz). Cela faisait plusieurs mois que j' en exprimait la nécessité de plus en plus imminente à l'équipe de Recordare. Il y a quelques jours, ils ont ouvert une discussion sur leur mailing-list. Apparemment, ils ne se tourneraient pas vers une solution légère mais plutôt vers une version "luxe". Au lieu de simplement utiliser les algorithmes PKZip de compression pour encoder un fichier, ce serait le format Zip, multi-fichiers, répertoire, mot de passe, et tout le toutim. Bon. J'espère que les personnes qui ont poussé dans ce sens l'utiliserons rééllement...
C'est un peu comme si vous aviez un robinet qui fuyait dans votre salle de bain, le plombier vous propose de la refaire entièrement, et quand vous demandez "quand" il vous dit, de toute façon je ne suis pas libre avant 2010...
 
by Didier Guillion
 2 comments.

Dev News Thursday, Feb 1st, 2007 at 06:01pm
Projet PDFtoMusic, étape 153

 
Aujourd'hui, nous proposons, conformément à notre planning, la première version publique de PDFtoMusic. La gestation a duré 9 mois, ce qui semble un bon chiffre. En tout cas, l'un des plus gros chantier de notre histoire, un peu après la première version d'Harmony Assistant qui avait pris plus d'un an. Bien sur cette version est encore perfectible, ce n'est que la version 1.0, mais l'application est solide et traite déjà de manière plus que satisfaisante une grande quantité de fichiers PDF musicaux. Je pense que cette version va évoluer très rapidement. Ce projet défriche des zones encores vierges et il y a encore plein de nouvelles découvertes à faire. Pourquoi ne pas imaginer un convertisseur de PDF vers Word pour récupérer les documents textes ? A moins que cela n'existe déjà.
 
Mais, en premier lieu, nous voulons remercier grandement tous les membres de l'équipe de béta test qui ont montrés une grande patience et nous ont, dans de nombreux cas, appris des techniques de notation que nous ignorions totalement (par exemple les altérations "anciennes" au dessus de la note qui ont été un vrai casse-tête et autres Objets Musicaux Non Identifiés) .
 
La très prochaine étape sera une nouvelle version d'Harmony Assistant qui gérera de manière infiniment meilleure l'export et l'import MusicXML et pourra ainsi communiquer de manière des plus efficace avec PDFtoMusic Pro.
by Didier Guillion
 9 comments.


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Dev News
Technical
Mood
Memories
Myriad Life
To be seen
30 previous days
Apr 2006
May 2006
Jun 2006
Jul 2006
Aug 2006
Sep 2006
Oct 2006
Nov 2006
Dec 2006
Jan 2007
Feb 2007
Mar 2007
Apr 2007
May 2007
Jun 2007
Jul 2007
Aug 2007
Sep 2007
Oct 2007
Nov 2007
Dec 2007
Jan 2008
Feb 2008
Mar 2008
Apr 2008
May 2008
Jun 2008
Jul 2008
Aug 2008
Sep 2008
Oct 2008
Nov 2008
Dec 2008
Jan 2009
Feb 2009
Mar 2009
Apr 2009
May 2009
Jun 2009
Jul 2009
Aug 2009
Sep 2009
Oct 2009
Nov 2009
Dec 2009
Jan 2010
Feb 2010
Mar 2010
Apr 2010
May 2010
Jun 2010
Jul 2010
Aug 2010
Sep 2010
Oct 2010
Nov 2010
Dec 2010
Jan 2011
Feb 2011
Mar 2011
Apr 2011
May 2011
Jun 2011
Jul 2011
Aug 2011
Sep 2011
Oct 2011
Nov 2011
Dec 2011
Jan 2012
Feb 2012
Mar 2012
Apr 2012
May 2012
Jun 2012
Jul 2012
Aug 2012
Sep 2012
Oct 2012
Nov 2012
Dec 2012
Jan 2013
Feb 2013
Mar 2013
Apr 2013
May 2013
Jun 2013
Jul 2013
Aug 2013
Sep 2013
Oct 2013
Nov 2013
Dec 2013
Jan 2014
Feb 2014
Mar 2014
Apr 2014
May 2014
Jun 2014
Jul 2014
Aug 2014
Aug 27th, 2014 at 05:30pm 
Comment from Oliveira
Adelante
Aug 27th, 2014 at 05:04pm 
Comment from Nicou59
Aug 27th, 2014 at 05:04pm 
Comment from Nicou59
Aug 27th, 2014 at 05:01pm 
Article from Olivier Guillion
Harmony et les VST(i) Partie 2
Aug 27th, 2014 at 07:22am 
Comment from Antoine Bautista
les lignes...
Aug 27th, 2014 at 07:20am 
Comment from Sylvain Machefert
pré réglages
Aug 26th, 2014 at 05:00pm 
Article from Olivier Guillion
Harmony 9.6 et autre, étape 706
Aug 26th, 2014 at 05:00pm 
Article from Olivier Guillion
Harmony 9.6 et autre, étape 706
Aug 26th, 2014 at 05:00pm 
Article from Olivier Guillion
Harmony 9.6 et autre, étape 706
Aug 25th, 2014 at 04:55pm 
Article from Olivier Guillion
Harmony 9.6 étape 705

Top of page
Last update:  (c) Myriad 2013