Myriad Blog 1.3.0 Thursday, Oct 23rd, 2014 at 10:04pm 

Dev News Tuesday, Dec 1st, 2009 at 04:58pm
Linux natif ? (partie 2)

 
Un point crucial dans l'élaboration d'un projet multi-plateforme est le respect de l'aspect graphique natif du système sur lequel tourne l'application.
Les utilisateurs de Mac OS X, en particulier, sont très sensibles à cela. Les utilisateurs Windows le sont un peu moins, peut-être, et enfin les Linuxien s'en fichent un peu, apparemment, vu la disparité de l'aspect des applications qu'on peut y trouver.
 
Certes, la personnalisation de l'apparence (les "thèmes" actuellement présents dans la version Windows de nos programmes) peut être pratique, mais pour la plupart des utilisateurs, un programme qui a une apparence "standard" est moins déroutant et plus facile à prendre en main.
 
Nos recherches dans le monde Linux, et la grande interrogation du choix de la distribution et de la librairie d'interfaçage nous ont amenés à nous pencher sur diverses solutions de développement multi-plateforme déjà existantes.
 
Ainsi, la librairie FLTK permet d'écrire des programmes pouvant fonctionner sur Linux, Windows ou Mac OS. Intéressant. La lecture de la documentation est alléchante, la licence LGPL peu contraignante. Mais respecte-t-il l'aspect du système sur lequel il fonctionne ? Difficile de trouver des informations claires à ce sujet. Une recherche d'images nous a convaincus du contraire :  
(Source)
Le bouton "OK" n'a pas vraiment le look "Aqua" de Mac OS X. Donc, a priori, cette solution est éliminée. Dommage.
 
Deuxième piste: GTK+. Créée à l'origine pour l'application graphique GIMP, cette librairie est elle aussi compatible Linux, Windows et Mac OS X. Hélas, apparemment même problème. Même si les boutons sont plus jolis, et que le thème peut être choisi par l'utilisateur, nous avons des doutes quant à son intégration des éléments de l'interface native. Cette image combine des boutons Aqua avec d'autres éléments (taquets, ascenseurs) définitivement non-Macs:
(Source)
 
Enfin, Qt semble fournir un aspect cohérent avec le système sur lequel il tourne. Ce pourrait être un bon choix, car les sources sembleraient prouver qu'il utilise, autant que faire se peut, les appels au système pour tracer les objets graphiques.
Bémol de taille, il semblerait que QT, assez lourd d'utilisation, impose de travailler en C++, ce qui nous poserait des problèmes pour l'intégrer à nos projets existants écrits en C tout court.
 
Nous en revenons donc à la question de base. Même si cela est plus rapide, vaut-il mieux faire confiance à une librairie multi-plateforme existante, ou prendre le temps d'écrire la nôtre?
Nous avons fait une petite liste des avantages de chacun des deux procédés :
 
* Utilisation d'une librairie existante
  - Mise en place plus rapide (tout est déjà prêt)
  - Possibilité de compatibilité avec des systèmes que nous ne possédons pas encore
  - Allègement de la charge de travail de mise à jour : tests, maintien et débogage assurés par la communauté
   
* Création et utilisation de notre propre librairie
  - Meilleure adaptation à nos besoins
  - Maintenance et débogage assurée par nos soins, sur des fichiers source que nous avons nous-même écrits
  - Facilité d'ajouts ou de modification de fonctionnalités  
  - Contrôle total de nos application. En cas de bug, pas la peine de se demander qui l'a causé.
  - Assurance de la pérennité de la librairie
 
Pour l'instant, la deuxième solution l'emporte, cette façon de travailler étant notre credo depuis nos tout débuts.
 
Reste alors la question du développement spécifique sur Linux. Avec quoi travailler sur ce système? Les librairies FLTK ou GTK utilisent-elles directement le système, ou, comme sur Mac OS ou Windows, tracent-elles leur propres boutons et autres objets?
De plus, ces librairies fonctionnent-elles aussi bien sur KDE que sur Gnome, sans demander à l'utilisateur d'installer quelque chose d'autre ? Les fonctionnalités sont-elles identiques sur les deux GUI ?
 
Etant donné notre très faible connaissance du développement sur Linux, et particulièrement le développement cross-distribution, cela risque de virer au casse-tête. Impossible de trouver une documentation claire sur la manière d'ouvrir une boîte de dialogue "native" sur KDE ou Gnome, c'est-à-dire respectant les personnalisations (couleurs, tailles de fontes, etc) effectuées globalement par l'utilisateur du système.
 
Apparemment, ce n'est pas le cas pour GTK+ sur une distrib basée sur KDE. Est-ce le cas avec QT4 sur une distrib basée sur Gnome? Ou nous faudra-t-il obligatoirement prévoir deux versions de chacune de nos applications sous Linux ?  
by Olivier Guillion
 11 comments.

Dev News Friday, Dec 4th, 2009 at 04:53pm
Harmony 9.5 et autre étape 15

 
En cette fin de semaine, nous avons corrigé des problèmes, certains assez vieux, dont peu d'utilisateurs s'étaient rendu compte. Entre autres :
 
- La correction de problèmes d'annulation d'opérations depuis MyrScript nous a permis de mettre en évidence la non prise en compte des modifications aux "Titre, compositeur, remarques" lors d'un "refaire" (contraire de "Annuler").
 
- La modification du titre de la partition par clic droit -> Editer ne pouvait pas être annulée.
 
- Le déplacement de notes en accord en sélection individuelle (maj-clic) ne fonctionnait plus depuis la version 9.4.7
 
- Un problème de coulé sur une note liée par-dessus une barre de mesure en fin de ligne a été corrigé
 
- Un problème d'échelle des différentes vues lors de l'impression de toutes les vues a été corrigé.
 
Enfin, ce week-end, si notre emploi du temps et le temps tout court le permettent, nous irons peut-être faire un tour du coté de l'ubuntu-party de Toulouse, histoire de voir de quoi qu'est-ce qu'on cause.
 
Et, pour mettre tout le monde de bonne humeur ce week-end, la vidéo du chaton le plus mignon du monde
by Olivier Guillion
 1 comment.

Dev News Monday, Dec 7th, 2009 at 05:19pm
Koala karmique

 
A l'occasion de la sortie d'Ubuntu 9.10, cryptiquement nommée "Karmic Koala" (on peut présager que la suivante s'appellera "Lazy Llama"), Toulibre et Ubuntu-fr organisaient samedi après-midi une ubuntu-party à Toulouse. Nous sommes donc allés y faire un tour en voisins curieux.
 
Un public jeune et nombreux était présent, des planches didactiques sur le logiciel libre, les diverses licences ou l'open-source permettaient aux visiteurs un peu extérieurs au mouvement comme nous de tenter de comprendre le modèle économique sous-jacent, à moins qu'il s'agisse d'une philosophie, ou même, à en écouter certains, d'une véritable religion.
 
Des conférences techniques étaient également organisées. Toujours préoccupés par nos problèmes d'outils de développement et de librairie graphique multi-plateforme, nous avons assisté à deux conférences:
 
- La première concernait Eclipse, que nous pensions être un environnement intégré de développement (IDE) destiné au Java et au C++.
En fait, l'outil est plus large que ça, et sa structure permet de faire virtuellement n'importe quoi avec, pour autant qu'il s'agisse de saisir, visualiser, éditer et transformer les données. Son architecture ouverte lui permet d'accueillir des plug-ins, qui cohabitent en harmonie pour produire le résultat attendu.  
Nous avions connaissance d'Eclipse depuis plusieurs années, mais nos tentatives d'utilisation comme simple IDE pour le C s'étaient avérées décevantes, donnant l'impression, maintenant expliquable, d'essayer d'utiliser un couteau suisse à 25 lames pour planter un simple clou.
 
- La seconde conférence concernait QT4, l'environnement graphique multi-plateforme utilisé notamment par KDE (par exemple dans KUbuntu). Une très bonne présentation technique en a été faite, permettant d'en comprendre les concepts de base. Techniquement, tout a été parfaitement clair, et la bête semble bien structurée, solide, puissante et agrémentée d'excellents outils. Seuls bémol pour l'usage que nous désirons en faire.  
 
Nous avons eu confirmation cette librairie n'utilise pas les objets graphiques standard du système, mais retrace les siens. Elle imite cependant l'aspect standard, si bien qu'il est impossible de se rendre compte de la différence.  
Cela pose cependant quelques problèmes : il faut avoir toute confiance en la réactivité de la communauté pour espérer que lors de la sortie d'une nouvelle version d'un système, la librairie continue à tourner, et soit agrémentée du nouvel aspect. De plus, les anciennes applications utilisant la librairie statique QT gardent l'ancien aspect sur le nouveau système.
 
Enfin, point qui n'a pas vraiment été approfonci lors de la conférence, le système de licence quasi-incompréhensible semblerait dire qu'il n'est possible d'utiliser QT, propriété de Nokia, dans un logiciel commercial aux sources fermés qu'en achetant une licence coûtant environ 1500 euros par type de machine visé. Nous espérons seulement que ceci ne concerne pas le développement en natif sur Kubuntu, sur lequel QT est le coeur de l'interface graphique.
 
Nous en restons donc pour l'instant à notre première idée, qui est de tout faire nous-mêmes, et de considérer QT seulement comme le moteur de l'interface graphique d'un des multiples systèmes sur lesquels nos applications seraient susceptibles de tourner.
 
Mais pour en revenir à la réunion, les participants étaient sympathiques et les intervenants d'un excellent niveau. Nous avons pu obtenir des réponses à quelques-unes de nos nombreuses interrogations. Assez pour commencer à chercher les autres nous-mêmes.
by Olivier Guillion
 5 comments.

Dev News Tuesday, Dec 8th, 2009 at 05:13pm
Harmony 9.5 et autre étape 16

 
Aujourd'hui, les trépidations des engins de chantier dans la rue, de l'autre coté du mur du bureau, ne nous ont pas beaucoup laissé de possibilité d'une grande concentration.
Un gros rouleau compresseur produit des vibrations, amplifiées par l'effet de caisse de résonance des planchers, que nous évaluons à 4 sur l'échelle de Richter.  
 
Nous avons cependant corrigé quelques problèmes signalés par les utilisateurs, par exemple des crashs lors de l'utilisation de certaines fonctions de formatage des paroles dans le cas de portées fusionnées.
Le modèle de portées "grégorien" a également été corrigé, l'ancien comportant 5 lignes au lieu des 4 attendues. Quelques scripts ont également été repris.
 
Enfin, nous avons commencé à réfléchir à la manière d'organiser les données dans notre future interface graphique, afin de faciliter le travail de relecture, modification et traduction du contenu des boîtes de dialogue.
by Olivier Guillion

Dev News Thursday, Dec 10th, 2009 at 05:10pm
Harmony 9.5 et autre étape 18

 
Nous travaillons toujours sur la prochaine version beta, en essayant d'y inclure tout ce qui est susceptible de poser problème, afin de permettre la plus longue période de test possible.
 
Ainsi, certains utilisateurs sur Windows Vista (et peut-être Windows 7), avaient un problème d'installation de la police musicale. Ils installaient le programme, le lançaient et tout fonctionnait. Mais après un redémarrage de l'ordinateur la police n'était pas disponible, et ils devaient alors réinstaller pour pouvoir travailler.
 
Nous n'avons jamais pu reproduire ce problème sur nos machines virtuelles. D'après les symptômes, il semblerait que ce soit dû à une impossibilité pour l'installateur d'inscrire quelques clés dans le registre Windows, empêchant ainsi une déclaration permanente de cette police.
 
Nous avons donc décidé de mettre en place le mécanisme suivant dans tous nos programmes en version Windows : si, au lancement du programme, la police musicale n'est pas disponible dans le système, la copie de celle-ci (dans le sous-dossier "Font" de l'application) est utilisée localement jusqu'à la fermeture du programme.  
 
Malheureusement, les fonctions nécessaires à ce procédé ne sont disponibles qu'à partir de Windows 2000. Nous nous efforçons donc de redémarrer nos machines virtuelles sous Windows 95 et 98 afin de le tester et d'assurer une compatibilité, même au prix de fonctionnalités réduites, avec ces anciens systèmes.
 
Car, même si notre sondage ne le montre pas encore, nous savons que plusieurs utilisateur continuent de fonctionner avec ces vieux machins.
by Olivier Guillion

Dev News Monday, Dec 14th, 2009 at 05:32pm
Vers l'abandon de Windows 9x ?

 
 
 
Nous avons enfin pu, pendant quelques heures, réinstaller Windows 98 en machine virtuelle pour tester nos logiciels. Hélas, VirtualBox ne semble pas très doué pour gérer ces anciennes versions du système, et les crashs à répétition ont eu raison de notre test. Il ne nous reste plus qu'à recommencer une installation.
 
Mais entre-temps, nous avons pu lancer nos installateurs, et là, mauvaise nouvelle: ils ne fonctionnent plus pour des versions de Windows inférieures à Windows 2000.
 
Le nouveau compilateur (Visual C++) ne sait plus générer d'exécutables compatibles avec les anciennes versions du système du même éditeur. Outre les librairies de démarrage (Run-time libraries, appelées aussi "CRT") qui ont besoin de fonctions apparues avec Windows 2000, le compilateur marque les exécutables qu'il génère avec un sceau "Windows 2000 et supérieur" qu'il n'est apparemment pas possible de modifier.
 
Nous avons donc 5 solutions (si vous en trouvez une autre, exprimez-vous) :
 
1- Faire en sorte que ces exécutables, une fois compilés, soient à nouveau compatibles, par exemple changeant la version minimale nécessaire, et en court-circuitant les fonctions dans le CRT.
Pas génial, c'est un peu du bricolage, et cela revient à hacker nos propres programmes.
 
2- Reprendre et modifier les sources du CRT de Microsoft, et enlever ce qui est spécifique à Windows 2000.
Pas top, car nous ne disposons pas de ces sources, et cela rendrait difficile les évolutions dans les versions du compilateur. De plus, cela ne résoudrait pas le problème de la version minimale demandée, et nécessiterait tout de même de modifier les fichiers exécutables après compilation.
 
3- Compiler tant que c'est encore possible nos programmes sur notre ancien compilateur CodeWarrior, qui lui est resté compatible.
Possible, mais c'est reculer pour mieux sauter. Nous savons qu'au prochain changement de machine, nous aurons probablement un système récent (Windows 7) sur lequel CodeWarrior ne fonctionnera pas.
 
4- Fournir deux versions de nos produits, en conservant une machine sous Codewarrior qui compile pour Windows 9x.
Waouh, théoriquement possible, pratiquement difficile. Ce serait vraiment beaucoup de peine (machines multiple, maintien de la compatibilité de tous nos projets avec l'ancien système, double maintenance de tous nos produits...) pour un maigre résultat.
 
5- Abandonner purement et simplement la compatibilité Windows 9x. Il y a malheureusement encore des utilisateurs sous Windows 95, 98 ou ME. Même si nous leur laissont la possibilité de télécharger la dernière version compatible (9.4.7c) ils vont petit à petit perdre la compatibilité en fonctionnalités et en format de fichier avec les nouvelles versions du programme. C'est surtout dommage car, fonctionnellement, tous nos programmes tournent sans problème sur ces systèmes.
 
 
Cinq solutions, et aucune de satisfaisante. Nous allons, je crois, être obligés de déterminer quelle est  la moins mauvaise.
by Olivier Guillion
 5 comments.

Dev News Wednesday, Dec 16th, 2009 at 05:08pm
Un sursis pour les vieux Windows

 
Comme nous l'annoncions dans le billet d'avant-hier, le maintien de la compatibilité de nos programmes avec les version de Windows pré-2000 (Windows 95, 98 et ME) posait de sérieux problèmes.
 
Entre arrêter purement et simplement cette compatibilité, ou déployer des efforts disproportionnés pour l'assurer, nous devions faire un choix.
 
Nous avons découvert quelques astuces qui nous permettent de générer encore des versions de programmes compatibles avec ces Windows 9x. Ce n'est ni immédiat, ni automatique, mais c'est faisable.
 
Aussi, nous avons décidé de maintenir, en tout cas pour un temps, la compatibilité.
Mais les utilisateurs de Windows 9x devront installer une version spéciale de nos programmes, qui ne sera pas mise à jour avec la même fréquence que la version standard. Les éventuels rapports de crash de ces versions ne pourront pas non plus être traités aussi rapidement que les autres.  
 
En résumé, nous fournirons des versions compatibles de temps en temps, afin de permettre à ces utilisateurs de conserver la compatibilité de fichier et de fonctions avec les versions récentes. Mais ces versions spéciales seront fournies sans garantie de résultat, les utilisateurs étant priés d'envisager sérieusement la mise à jour de leur système (une fois tous les 10 ans, ce n'est pas du luxe).
 
Sur Macintosh, un problème similaire nous était posé par la dernière version du système de développement XCode, annonçant une incompatibilité avec les version de Mac OS inférieures à 10.4.  
Nous avons donc testé nos nouvelles versions d'application sur Mac OS 10.3, et à notre grande surprise, elles fonctionnent parfaitement. Effet d'annonce, erreur, ou incompatibilité seulement partielle ne nous affectant pas ? Nous n'en savons rien, mais pouvons continuer à produire des programmes fonctionnant sur 10.3.
 
 
by Olivier Guillion
 2 comments.

Dev News Tuesday, Dec 22nd, 2009 at 04:43pm
Harmony 9.5 et autre étape 22

 
La version Windows de nos programmes est appelée à fonctionner sous 3 environnements différents :  
- Windows 2000/XP/Vista/7
- Windows 95/98/ ME
- Linux au travers de Wine
 
La version 95/98/ ME nécessite une compilation et une mise en place différentes. Nous avons donc créé les projets correspondants, compilé pour ces plateformes, créé les installateurs et essayé tout cela sur nos machines virtuelles équipées d'anciens OS.
 
La version Linux/Wine, elle, utilise directement la version "standard" pour les Windows récents. Par contre, elle nécessite de petits aménagements, les polices de texte proposées dans Wine posant quelques problèmes. En effet, la fonte standard Windows "Tahoma" est bien présente sous Wine, mais les résultats visuels sont catastrophiques pour les petites tailles. Nous devons donc trouver un moyen, sous Wine, de choisir une autre fonte par défaut, sachant que la liste disponible semble varier entre les distributions et versions de Linux.  
 
Ensuite, nous essaierons de débarasser l'installateur de l'alerte qui apparaît sous Linux, et qui est due à l'absence du menu standard des programmes installés présent sous Windows (Menu démarrer > Programmes).
 
by Olivier Guillion
 2 comments.

Dev News Wednesday, Dec 23rd, 2009 at 04:56pm
Harmony en quarantaine

 
Depuis quelques semaines, nous avons reçu un nombre anormalement élevé de courriels nous signalant qu'Harmony Assistant ne pouvait plus être lancé sur Windows XP.
 
Une boîte d'alerte système s'ouvre lors de la tentative de lancement, indiquant: "Windows ne parvient pas à accéder au périphérique, au chemin d'accès ou au fichier spécifié. Vous ne disposez peut-être pas des autorisations appropriées pour avoir accès à l'élément.".
 
Après de longues et pénibles investigations tous azimuths, nous pensons avoir enfin compris ce qui peut bien s'être passé.
 
Tous les utilisateurs rencontrant ce problème semblent utiliser le même antivirus : Kaspersky.
 
Suite à une réelle infection de leur ordinateur, ou, plus probablement, suite à un "faux positif" lors de l'utilisation à une certaine date par Kaspersky d'une base virale mal configurée, l'exécutable Harmony Assistant a été considéré comme "application douteuse" (sic).
 
Il a donc été rangé d'office dans la liste des programmes ne devant pas être lancés. Malheureusement, l'alerte apparaissant désormais lors d'une tentative de lancement est moins que claire, et ne permet pas de faire le lien avec l'antivirus.  
 
Il suffit de déplacer Harmony Assistant vers la liste des applications dites "de confiance" pour tout arranger.
 
L'honnêteté intellectuelle des fabricants d'anti-virus devrait leur imposer de re-tester les programmes rangés en quarantaine lors de la sortie d'une nouvelle base virale. Si un programme n'était pas détecté auparavant, a été détecté un jour, mais ne l'est plus le lendemain, il y a de fortes chances qu'il se soit agi d'un "faux positif", et l'antivirus devrait alors proposer de le rétablir.
 
Mais il faudrait alors montrer clairement à l'utilisateur que l'antivirus n'est pas infaillible et peut commettre des erreurs. Il est plus simple et moins dommageable pour l'image de marque de laisser l'application "plantée", et de faire porter le chapeau à celle-ci, en délivrant une information confuse. L'utilisateur et le support technique de l'application se lasseront peut-être, et personne ne saura jamais ce qui s'est vraiment passé...
 
Merci à B.T (Chicoutimi, Qc) pour son assistance et sa patience.
by Olivier Guillion
 1 comment.

Dev News Monday, Dec 28th, 2009 at 05:10pm
Harmony 9.5 et autre étape 23

 
Harmony / Melody
 
- Les mesures de métronome avant le début de la musique étaient exportées en numérique, ceci a été corrigé.
 
- Il est maintenant possible de spécifier que la taille des paroles est adaptée en fonction de l'échelle d'affichage de la portée.
 
- Sur Windows, correction de l'aspect des groupes de notes et des trilles altérées dans la palette d'ornements
 
- Crash possible lors de la fabrication de la liste des noms de séquence d'accompagnement.
 
- Modification de l'interprétation des symboles d'appui et de fin de pédale (Ped / *). Une note relâchée par une fin de pédale (*) ne peut pas voir sa relâche maintenue par un nouvel appui de pédale (Ped).
 
- L'option "Edition > Ajouter" ne vérifiait pas la présence d'une barre de mesure avant d'en ajouter une autre. Ceci permettait d'avoir plusieurs fois la même barre dans une même mesure. Avec plusieurs copier/ajouter successifs, le nombre de barres augmentait exponentiellement, jusqu'au "plantage" du fichier. On nous signale que ce problème affectait également le script "Joindre fichiers". Nous devons vérifier si cela a également été corrigé.
 
PDFtoMusic / Pro
 
- Correction d'un crash dans la gestion des coulés multiples (devait aussi affecter l'import XML d'Harmony).
 
- l'export MIDI avait été malencontreusement inactivé. C'est rétabli.
by Olivier Guillion

Dev News Wednesday, Dec 30th, 2009 at 04:57pm
Harmony 9.5 et autre étape 25

 
Pour terminer l'année, les dernières versions Beta ont été postées.
Elles concernent Melody et Harmony d'une part, et PDFtoMusic et PDFToMusic Pro de l'autre.
 
Nos autres applications, Melody Player et Myriad Plug-in, dont le fonctionnement avait été peu modifié par rapport à la beta précédente, n'ont pas été republiés.
 
Outre les corrections de problèmes listés aux fils des jours dans ce blog, les nouvelles versions sont donc utilisables sur les vieilles versions de Windows (95, 98 et ME) par le biais d'une version spéciale, également téléchargeable.
 
L'heure n'est pas encore au bilan de cette version beta, mais au vu de la multitude de corrections apportées grâce à la recompilation de la version Windows, la stabilité de toutes nos applications devrait avoir été grandement améliorée. Nous restons cependant à l'affut des rapports de crash provenant de participants à la version beta, et surtout des fichiers qui leur ont posé problème, seul moyen pour nous de reproduire et corriger ce dernier.
 
Mais sur ce, nous vous souhaitons un bon réveillon, et un passage en douceur à l'année 2010 !
by Olivier Guillion
 3 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
Sep 2014
Oct 2014
Oct 23rd, 2014 at 05:00pm 
Article from Olivier Guillion
PDFtoMusic 1.4.3
Oct 22nd, 2014 at 04:53pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Oct 21st, 2014 at 05:02pm 
Article from Olivier Guillion
PDFtoMusic 1.4.3
Oct 20th, 2014 at 08:43pm 
Comment from Antoine Bautista
et puis aussi...
Oct 20th, 2014 at 05:39pm 
Comment from OliveiraLe mixer ge enard
Le mixer garde en mémoire l'étirement de la dernière partition
Oct 20th, 2014 at 04:45pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Oct 17th, 2014 at 08:18pm 
Comment from Antoine Bautista
Le mixer et l'étirement...
Oct 17th, 2014 at 08:18pm 
Comment from Antoine Bautista
Le mixer et l'étirement...
Oct 17th, 2014 at 05:20pm 
Comment from Olivier Guillion
Re: Ajustar medidas del mixer
Oct 17th, 2014 at 05:13pm 
Comment from Oliveira
Ajustar medidas del mixer

Top of page
Last update:  (c) Myriad 2013