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 | | |
| |
|
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 | | | |
|
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 | | | |
|
- 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 | | | |
|
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 | | | |
|
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 | | |
| |
|
À 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 | | | |
|
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 | | | |
|
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 | | | |
|
|