Après mise au propre de certaines parties de gestion de la base de données qui pouvaient poser problème, nous avons relancé la collecte de fichiers, en vérifiant régulièrement l'intégrité des bases de données, ainsi que les rapports dans les fichiers-journaux.
Aucun problème sur environ 6000 fichiers, jusqu'à ce que le plantage de base se reproduise à nouveau. Nous avons pu, cette fois, grâce au compte-rendu détaillé des opérations, comprendre ce qui s'était passé :
Notre serveur Web est muni de protections pour éviter qu'un ou plusieurs scripts puissent partir dans des boucles infinies et saturer la machine : aucun appel à un script ne peut durer plus de 5 minutes. Au-delà de ce délai, la tâche correspondant au script est automatiquement tuée.
Or, un des fichiers que nous avions à traiter était un fichier ZIP, contenant plusieurs fichiers ABC, eux-même contenant chacun plusieurs centaines de morceaux.
Cela faisait, dans un seul fichier, plusieurs milliers de morceaux de musique à analyser, indexer, et stocker dans les bases de données. Ce processus prenait plus de 5 minutes, et le script était alors terminé abruptement, alors qu'il était en plein dans l'écriture des divers fichiers des bases de données.
Dans ce type de cas, il vaudrait mieux envoyer les morceaux un à un plutôt que tous d'un coup. Ainsi, chaque accès individuel ne serait que d'une fraction de secondes, aucun d'entre eux ne flirtant avec le temps limite attribué à la tâche.
En attendant de modifier le programme dans ce sens, nous avons mis en place dans notre script une vérification du temps passé, permettant de quitter proprement lorsqu'on dépasse 3 mn (histoire d'avoir un peu de marge). Ainsi, tous les morceaux contenus dans le ZIP ne seront pas pris en compte, mais la base devrait rester intègre.
Nous allons essayer de faire tourner l'indexation pendant ce week-end de trois jours, et voir si tout tient le choc. |
|
|
| by Olivier Guillion |  |
| |
|
Nous avons passé une bonne partie de la journée à tenter de localiser le problème de corruption de la base de données de Kooplet.
L'ennui, c'est que cela ne semble se produire que dans de rares cas, après une collecte de plusieurs milliers de fichiers.
Nous avons essayé de créer un programme de "stress" de la base de données, avec des milliers de création, redimensionnement et suppression d'éléments, mais cela n'a pas permis de reproduire cette erreur.
Nous avons donc relancé une collecte, après avoir truffé notre code de marquage des opérations dans un fichier-journal. Nous espérons ainsi que, si cela se reproduit, nous pourrons nous en servir pour comprendre d'où ça vient.
En attendant, nous collectons donc à nouveau, tout en sachant qu'il faudra tout reprendre à zéro lorsque l'erreur aura été supprimée. |
|
|
| by Olivier Guillion | |
| |
|
Harmony et PDFtoMusic on commencé à traiter quelques milliers de fichiers collectés par notre crawler.
Cela nous a permis d'isoler des fichiers particulier que l'on traitait mal, voire qui faisait planter l'application.
Les imports ABC, NoteWorthy, TablEdit ont donc été corrigés.
Nous avons rencontré un cas qui n'était pas prévu : des archives .zip de plusieurs fichiers ABC, eux mêmes contenant plusieurs centaines de musiques.
C'est désormais traité.
Enfin, à 15h26, la base de donnée de Koolpet a été fortement corrompue. Nous avons tout arrêté et cherchons à comprendre ce qui s'est passé...
|
|
|
| by Didier Guillion |  |
|
| |
|
La documentation MyrScript a été complété avec les nouvelles méthodes et valeurs.
Correction d'un crash dans le Player lorsque l'on ouvrait la table de mixage sur un document vide.
Dans le Player il est maintenant possible de changer le volume et la position stéréo des pistes numériques. |
|
|
| by Didier Guillion | |
|
| |
|
Les appels à la lecture de pages et de fichier sur Internet par le crawler ont été rendus non bloquants, même sur Windows.
Pour ce faire, un processus indépendant est lancé pour l'envoi de commande et la lecture du résultat sur Internet, et si ce processus ne répond pas au bout d'un délai imparti, il est automatiquement détruit par le processus "père".
Malheureusement, un oubli de programmation nous a fait analyser incorrectement quelques centaines de fichiers. Ils seront récupérés au prochain balayage complet de chaque site.
Sylvain, en examinant les logs d'accès à son site, nous a fait remarquer que notre robot ne tenait pas compte des indications du "robots.txt" en ce qui concerne les adresses à ne pas balayer. Cela a été corrigé.
Il a également signalé que notre robot essayait d'accéder à des pages inexistantes, croyant à tort avoir trouvé des liens sur celles-ci dans les pages déjà visitées.
Nous avons donc amélioré cette partie.
Nous avons détecté quelques boucles de liens mal résolues (page A qui contient un lien sur page B, qui contient un lien sur page A...). Normalement, cela aurait dû être traité automatiquement par le robot, qui ne devrait jamais passer deux fois au même endroit. Il semble y avoir un problème dans certains cas...  |
|
|
| by Olivier Guillion | |
| |
|
Daniel a levé un gros lièvre. Dans le langage MyrScript nous avons complètement "zappé" l'objet de type Repère. Il a donc été ajouté et cela fait quelques dizaines de nouvelles méthodes et valeurs qu'il faut maintenant tester...
Bon week end !
|
|
|
| by Didier Guillion | |
| |
|
Aujourd'hui analyse et essai d'implémentation d'une demande de l'atelier démocratique : la possibilité de définir une taille papier différente selon la vue.
Après essais, nous nous sommes rendus compte que cela n'apportait pas grand chose car il est déjà possible de changer marges, échelle et orientation du papier de manière indépendante pour chaque vue.
A moins que l'utilisateur ait deux imprimantes, une A4 et une A3 par exemple, ce qui doit être plutôt rare et de toute façon il est impossible de changer d'imprimante au cours d'une même impression.
|
|
|
| by Didier Guillion | |
|
| |
|
Nous avons terminé de vérifier le système de parcours des pages Web (crawler), repérage et analyse des fichiers musicaux, et conversion de ces derniers en données utilisables par le moteur de recherche.
Nous avons reconstitué la liste d'une cinquantaine de sites Web qui avait servi à nos premiers essais, et lancé une indexation de ces sites.
Pour l'instant, 4 instances du client d'indexation sont en cours sur un PC sous Windows, une autre est en test sur une machine Linux, et une ou plusieurs autres seront démarrées ce soir sur un PC personnel.
Les 3 machines fonctionneront toute la nuit, et nous verrons demain matin ce que ça a donné.
Par contre, il s'agit seulement de la collecte des données. Ces dernières sont simplement stockées dans une base de données temporaire, limitée arbitrairement à 10000 éléments (fichiers).
Pour les transformer en quelque chose d'utilisable par le système de recherche, il faut extraire de ces données les informations musicales, ainsi que les divers textes. Ceci ne peut se faire pour l'instant qu'à l'aide de nos versions de développement d'Harmony Assistant et PDFtoMusic.
Pour éviter que tout s'arrête lorsque 10000 fichiers sont en attente d'analyse, il faut donc théoriquement que suffisamment d'instances de ces versions d'Harmony et PDFtoMusic tournent pour analyser les données plus rapidement qu'elles sont collectées. Il va nous falloir évaluer à l'usage combien de machines devront être mobilisées, et pour combien d'heures par jour. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui, correction d'un problème de sauvegarde de fichier ABC multi portées.
Le script pour cithare a été considéré comme finalisé par le demandeur.
Correction d'un problème de saisie des poignées des coulés.
Pour répondre à Mick, il serait en effet judicieux de sortir une sous version prochainement, nous attendons que le traitement partagé des fichiers de Kooplet soit bien au point afin de pouvoir demander aux utilisateurs de nous donner un peu de temps machine... |
|
|
| by Didier Guillion | |
| |
|
La nouvelle version du robot d'indexation (crawler) de Kooplet a tourné ce week-end, sur un petit nombre de sites (moins d'une dizaine). Il a indexé ainsi un petit lot de 4000 fichiers.
La partie client du crawler demande peu de ressources sur la machine sur laquelle elle tourne, et devrait même pouvoir être lancée depuis une clé USB ou un CD-ROM, car elle ne stocke aucun fichier sur le disque.
Ceci nous a permis de vérifier les accès concurrentiels de plusieurs instances de ce client, ainsi que la bonne récupération des données des fichiers musicaux.
Cependant, la vérification des doublons (même fichier musical disponible à des adresses différentes du même site) nécessitait des balayages assez longs, nous avons donc mis en place un index croisé pour une recherche plus rapide. Ceci nous a obligé à recommencer le processus d'indexation depuis le début.
Cette semaine, nous devrions pouvoir relancer la création de la base définitive. |
|
|
| by Olivier Guillion | |
|
| |
|
Une légère correction sur le script de forçage de la police des textes des paroles a été apportée.
Correction d'un problème d'affichage des barrés sur certains diagrammes d'accord.
Correction d'un problème d'annulation. |
|
|
| by Didier Guillion | |
|
| |
|
Nous avançons toujours sur le système de balayage des sites. Nous nous sommes heurtés à un problème assez compliqué qui n'avait jamais été résolu convenablement dans la version précédente du "crawler" : certains sites, pour être parcourus correctement, nécessitent un enregistrement de l'utilisateur.
C'est le cas notamment de CPDL.
Afin d'économiser la bande passante, les visiteurs se voient redirigés aléatoirement vers des sites miroir, ce qui perturbait notre robot. Heureusement, le webmaster de CPDL est également utilisateur de nos produits, il nous a donc aimablement ouvert un compte privilégié afin que nous puissions indexer tous les fichiers à notre guise.
Mais la phase de "login" nous a posé quelques problèmes. Le site est un wiki, donc pour éviter que des robots puissent s'enregistrer tout seuls et s'amuser sur les pages, des protections anti-robot ont été mises en place. L'analyse nous a montré qu'elles étaient similaires au système anti-spam de notre blog. Nous avons donc du gérer la prise en compte de cookies multiples, et récupérer des données générées dynamiquement sur les pages de log-in afin que notre robot puisse s'identifier correctement. Cela fonctionne maintenant.
Dans un tout autre domaine, nous avons reçu ce matin un e-mail qui nous a fait beaucoup rire.
Un utilisateur très soucieux de la confidentialité des échanges sur Internet s'est inscrit à notre liste de diffusion de la lettre d'information.
Dans l'e-mail de confirmation de l'inscription, nous terminons par le petit paragraphe suivant :
Quote:Note : Afin d'éviter les abus, l'adresse IP de la personne ayant demandé ce message vous est communiquée ici.
Il s'agit de : xxx.xxx.xxx.xxx |
|
Ceci permet d'éviter qu'un robot automatique, le voisin à qui vous avez rayé la voiture, ou un collègue de bureau un peu farceur n'inscrive votre adresse e-mail à votre insu juste pour rigoler. Avec l'adresse IP, vous pouvez vérifier que l'inscription provient bien de chez vous.
Voici donc le mail que nous avons reçu en retour. Je me suis permis d'en modifier légèrement la syntaxe afin que son auteur ne considère pas que nous dévoilons en public des éléments de correspondance privée  .
Quote:| A ma demande d'information concernant vos produits, vous me menacez en me précisant que vous avez mon adresse IP. Je me suis inscrit sans mauvaise intention et en retour, je suis agressé par vous. Pour quelle raison ? Clarifiez votre démarche, vous améliorerez ainsi votre image auprès de vos clients de bonne foi. |
|
Si ce monsieur savait qu'à chaque consultation d'une page sur un site, le serveur voyait son adresse IP en clair, je crains qu'il n'en perde d'un coup le sommeil et l'appétit. Les campagnes médiatiques paranogènes sur les dangers d'Internet ont, il semble, fait croire à certains que l'adresse IP était une information secrête, au même titre que le code de carte bleue ou la combinaison de son coffre-fort...
|
|
|
| by Olivier Guillion | |
|
| |
|
Suite à des suggestions courtoises sur l'Atelier Démocratique, de nouveaux raccourcis clavier pour la prochaine version :
Activation de l'outil tempo
Activation de l'outil changement de clef
Activation de l'outil changement de métrique
Activation de l'outil changement de tonalité
Nous avons repris le développement pour iPhone, en pause depuis un an tout juste. En plus des problèmes (normaux) de développement, nous nous heurtons une fois de plus à des casse-têtes Staliniens d'accréditation, keychain, scellement, juste pour pouvoir lancer notre appli sur notre périphérique tout ce qu'il y a de plus légal et standard. Que de temps gaspillé !
Par contre, le système de déboggage d'Apple émule maintenant l'iPad et c'est le premier mobile d'Apple qui offre une réelle possibilité de faire quelque chose au niveau visualisation des partitions, nous avons déjà des idées...
|
|
|
| by Didier Guillion | |
|
| |
|
Le module serveur et le module client du "crawler" de kooplet sont écrits, et fonctionnels. Le module client est très léger, et consomme une puissance de calcul négligeable (jamais plus de 1% de la puissance CPU). Il devrait pouvoir tourner en tâche de fond sans effet notable.
Avant de lancer l'exploration des sites musicaux, il faut d'abord vérifier ces modules en profondeur, afin de s'assurer qu'ils respectent bien les paramètres imposés par les sites visités (fichier robots.txt), et que cette exploration se passe bien.
Il faut par exemple éviter les boucles de liens (la page A a un lien sur la page B, qui a un lien sur la page A), et s'assurer que le module client réagit bien lorsque le site qu'il explore n'est pas correctement accessible.
La version Windows du Perl ne permet pas de définir un timeout sur les accès Internet, donc un site qui ne répond pas fait boucler le programme indéfiniment. Dans la version Linux, par contre, cela fonctionne... presque.
Il arrive en effet que certains accès très lents finissent par bloquer le programme également. Nous n'avons pas pu déterminer exactement dans quel cas, mais c'est assez gênant, car cela nous obligerait à relancer le module client tous les deux ou trois jours en moyenne.
Nous prévoyons donc de développer un module d'accès indépendant du corps principal du module, ce qui permettrait d'arrêter son exécution s'il ne répond pas au bout d'un certain temps.
Ainsi, le module pourrait fonctionner sans nécessité d'intervention humaine sur n'importe laquelle des deux plateformes.
|
|
|
| by Olivier Guillion | |
| |
|
Le script pour tablature de cithare est quasiment achevé, nous en sommes à régler des calages graphiques mineurs. Au passage, ceci nous a permis de nous conforter dans l'évidence de l'extraordinaire souplesse de MyrScript. En une quinzaine de jours nous avons soumis à notre testeur une vingtaine de versions qu'il a pu tester, critiquer et valider.
Nous obtenons ainsi une nouvelle fonctionnalité de gestion d'un instrument que nous ne possédons pas et c'est assez amusant.
Au passage, notre interlocuteur doit avoir plus de 90 ans et c'est toujours plaisant de constater la vivacité d'esprit et le haut degré d'adaptation aux nouvelles technologies de certaines personnes... |
|
|
| by Didier Guillion | |
|
| |
|
Correction d'un problème de durée de note en chargement ABC.
Correction d'un problème de marge en import GuitarPro
Correction d'un problème de deadlock dans PDFtoMusic.
Enfin, nous avons été recontacté par WordReference pour reprendre le développement de notre application iPhone.
|
|
|
| by Didier Guillion | |
| |
|
Avant de relancer l'indexation des sites musicaux par Kooplet, nous avons décidé de reprendre à la base le "crawler", c'est-à-dire le programme qui se balade sur Internet pour repérer les fichiers intéressants.
En effet, il avait été programmé assez à la va-vite, et dans sa version actuelle, ne permettait qu'à une seule machine de procéder à ces recherches. Nous lançions donc plusieurs instances du programme sur une seule machine dédiée (tournant sur Linux).
La quantité de pages à balayer ne pouvant qu'augmenter au fur et à mesure que de nouveaux sites à indexer seraient découverts, nous avions peur qu'une seule machine, ce soit un peu juste.
Nous avons donc repensé l'architecture du crawler : un serveur centralisé (sur kooplet.com) gèrera donc les sites en cours d'exploration, les pages à visiter, les fichiers découverts et en attente de traitement. L'intégralité de ces données sera gérée en utilisant notre système de base de données.
Un client léger pourra être lancé sur autant d'ordinateurs que désiré, ces ordinateurs demandant au serveur la page à explorer et lui renvoyant soit les informations sur le contenu des fichier musicaux, soit les liens découverts dans la page Web. On pourrait ainsi envisager, lorsque le besoin s'en ferait sentir, de demander de l'aide à quelques-uns d'entre vous pour explorer l'arborescence des pages Web. Cela pourrait se faire soit au travers d'un petit programme indépendant, soit par une commande privée de MyrScript, directement dans Harmony Assistant.
Nous avons également besoin des traitements d'Harmony Assistant, ou de PDFtoMusic, pour transformer les données des fichiers musicaux collectés par le "crawler" en données simplifiées pouvant être utilisées par le moteur de Kooplet lors d'une recherche. Là aussi, nous pourrions faire appel à des utilisateurs volontaires pour nous aider à traiter toutes ces données, par l'intermédiaire d'une commande privée cachée dans ces logiciels.
|
|
|
| by Olivier Guillion | |
|
| |
|
Quelques corrections dans le script de tablature pour cithare.
Dans PDFtoMusic, la barre de position de la musique ne tenait pas compte des mesures multi-silence ce qui entrainait un décalage, c'est corrigé. Mais cela a été chaud...
Lors de son ouverture, la taille de la fenêtre du JukeBox s'adapte à la résolution écran courante.
|
|
|
| by Didier Guillion | |
|
| |
|
Nous avons donc reçu notre microphone hier, et avons pu procéder à quelques tests.
Voici comment nous avons procédé.
Dans la pièce la moins résonnante du bâtiment (sous les toits, avec des tentures au plafond qui amortissent les échos), nous avons placé côte à côte:
- Un microphone stéréo Sony ECM-MS907 connecté au Creative Nomad Jukebox 3, au travers d'un préampli mono Sound Professionals SP-PREAMP-10.
- Le Microphone Blue Yeti, connecté en USB à un ASUS EEE PC équipé d'Audacity. Le sélecteur de type d'enregistrement du microphone est réglé, sauf mention contraire, sur "Stéréo".
Nous avons ensuite joué de divers instruments, et avons enregistré simultanément sur les deux systèmes. Voici les résultats au format WAV non compressé, avec un peu de blanc avant et après chacun, afin de pouvoir juger du bruit de fond. On entend parfois quelques bruits de rue et des "cui cui" d'oiseaux. On entend aussi de temps en temps le bruit du disque dur du Nomad qui change de piste .
Tout d'abord, trois notes à la flûte (un "tin whistle" irlandais en métal), jouées à 60cm
Yeti --- Nomad
Trois notes de Glockenspiel, jouées à 60cm
Yeti --- Nomad
Deux cordes à vide de guitare, jouées à 60cm
Yeti --- Nomad
Un accord de guitare, arpégé, joué à 30cm
Yeti --- Nomad
Enfin, nous avons un peu joué avec le Yeti, et notamment avec le sélecteur de type d'enregistrement. Nous avons joué la même chose trois fois, avec trois réglages différents :
Yeti, réglage "Stéréo"
Yeti, réglage "Omni"
Yeti, réglage "Cardioïde"
Nous n'avons pas testé la dernière position, destinée à l'enregistrement d'interviews.
La position "Omni" (enregistrement d'ambiance) est très proche, dans nos tests, de la position "Cardioïde" (enregistrement d'instrument solo), probablement parce que nous avons joué un son fort, placé en face du micro. Il faudrait effectuer d'autres tests, avec une saisie réelle d'ambiance sonore.
En conclusion, pour nos oreilles non expertes, le Yéti possède une bien meilleure dynamique, et un bruit de fond moindre, probablement dû à ses grandes membranes. Il reste assez lourd et encombrant, mais sa connexion directe en USB et l'utilisation d'un ordinateur portable permet un contrôle beaucoup plus fin de l'enregistrement, améliorant ainsi grandement la facilité générale d'utilisation.
Pour les enregistrements sans possibilité d'espace ou de préparation, on privilégiera donc une solution légère telle que le Nomad et le petit micro Sony, mais pour les enregistrements d'instruments, où l'interprète est à notre disposition, il sera grandement préférable d'utiliser le Yeti. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui :
Nouvelle méthode MyrScript : score.GetPlayMark()
Amélioration du script pour cithare avec :
- Affichage de la métrique et de la tonalité dans le titre
- Traitement des notes liées
- Correction du positionnement de la découpe
Et nous avons reçu notre nouveau microphone, il est très imposant avec un look plutôt rétro, nous allons l'essayer en détail demain !
|
|
|
| by Didier Guillion | |
|
| |
|
Lors de l'import ABC de fichiers multiples, et sur suggestion de Sylvain, on peut maintenant écouter les musiques dans la liste avant de sélectionner celle que l'on veut charger.
Les premières versions du script de calcul de tablature pour cithare ont été soumises à notre testeur et les calages sont bon. Excellente nouvelle.
Certaines cithares demandent, pour représenter les cordes, une largeur supérieure à celle d'une page A4. Mais souvent, lorsque des notes très aiguës sont jouées, il y a peu de notes très graves dans le morceau. Un mode spécial du script permet de recalculer la note de base et décale d'autant la tablature.
Il manquait la représentation des coulés entre les notes, cela a été fait.
La notation des accords de la main gauche suit certaines normes : des nombres sont parfois utilisés à la place du nom des accords. Nous en avons implémenté deux : la notation pour cithare ancienne et celle des instruments fabriqué par l'abbaye d' En Calcat.
Bon week end ! |
|
|
| by Didier Guillion | |
| |
|
|
