Le forum

(αγορα ύδραυλις)


L'Hydraule

Facture d'orgue, informatique et internet.
mardi 11 août 2009 21:11:49
Il y a quelques années, j’avais déjà esquissé ici l’idée d’un utilitaire Web capable de faire le tracé et l’inventaire d’un plein jeu. Mais vu l’intérêt des foules, je n’avais jamais terminé cet utilitaire qui pourtant, fonctionnait suffisamment pour que certains tuyautiers français (et non des moindres) s’en servent assez couramment dans leur production.

Une fois n’est pas coutume, j’ai reprogrammé l’utilitaire en question (les navigateurs et les langages du Web ont beaucoup évolués ces dernières années) et cela m’a permis d’écrire un article sur des réflexions autour de l’orgue, de l’informatique et de l’internet. Si d’aucuns passent encore en ce lieu et souhaitent faire des commentaires sur la chose, il restent naturellement les bienvenus...

Bien à vous,
:-)

Re: Facture d'orgue, informatique et internet.
vendredi 25 décembre 2009 18:57:54
L'utilitaire de plein-jeu est un outil de travail et de recherche performant et pratique, la faible participation sur les fora ne doit pas être une limite à tes expérimentations ordinantes.

Il y a là certainement une suite logicielle à développer, qui permettrait de concevoir et de modéliser des instruments, qu'il s'agisse de projets, de recherches ou de reconstitutions virtuelles d'orgues disparues...

Ce serait une autre manière d'appréhender la facture et la recherche organologique.



Venez voir l'orgue de Moyeuvre!
Re: Facture d'orgue, informatique et internet.
samedi 9 janvier 2010 06:17:51
Tiens Olivier !

Je ne sais pas si tu as reçu mon courriel mais j’ai un petit problème avec ton serveur Free (qui blackliste les courriels en provenance de l’Hydraule)...

Bonne année à tous !

Ah j’oubliais, tu parles de « suite logicielle à développer »... Et bien figure-toi que justement...

;-)



Modifié 1 fois. Dernière modification le 10/01/10 12:49 par smcj.
Re: Facture d'orgue, informatique et internet.
jeudi 14 janvier 2010 07:18:43
     Très cher Olivier,


     La suite logicielle dont tu me parles est une chose à laquelle plus d’un ont déjà pensé et ceci, depuis fort longtemps. Je me souviens que Marc Garnier avait, dans le milieu des années 80, programmé des petits utilitaires de traitement de tailles de tuyaux et réfléchissait déjà aux grilles de sommiers. Plus récemment, Gérard Bancells a beaucoup travaillé à faire fonctionner sa machine numérique avec des utilitaires de son cru. Des ateliers comme ceux de Bertrand Cattiaux ou de Pascal Quoirin sont aussi pourvus de tables traçantes pilotées, je crois, par le logiciel propriétaire AutoCAD. J’ai toujours refusé d’apprendre à me servir de ce type de logiciels (dont je ne renie rien des immenses possibilités) parce qu’outre leur prix inaccessibles pour le simple artisan, (environ 1 450 € la licence pour la version light (2D) et 4 775 € pour la version Pro (3D)...), le format des fichiers qu’ils produisent n’est que très difficilement ouvert, donc pérenne. De plus, AutoCAD est très dépendant du système d’exploitation M$-Windows, ce qui le rend encore plus réduit dans son utilisation dans le temps. Or, c’est ce dernier point précis qui me semble devoir être appuyé : faire un plan d’orgue historique, aujourd’hui, ne peut que s’inscrire dans une vue qui dépasse notre génération. Aussi, quand nous prenons une photographie d’un orgue, à un moment donné, ne pas réfléchir à sa projection dans le temps me semble donner peu de sens et de portée à notre témoignage car il est acquis que l’Histoire n’a pas de sens sans l’À-venir.

     Dans un autre ordre d’idée, on peut aussi consulter le site Web de Pascal Leray qui donne à voir des esquisses de sommiers. Toutefois, on s’aperçoit vite qu’il ne s’agit, en fait, que de sommiers entièrement électriques avec un électro-aimant par tuyau. Si je reste assez vite impressionné par les vues en trois dimensions, la problématique sera, pour ma part, infiniment plus complexe puisque j’envisage d’abord de gérer des gravures d’un sommier à registres coulissants mécanique, puis dans un deuxième temps de réflexion, de choses en découlant comme, par exemple, des tracés d’abrégés.

     Car j’ai bien entendu dans la tête depuis très longtemps ce que tu appelles une « une suite logicielle » ; mais je te laisse imaginer que la problématique n’est pas simple... Je viens à peine de comprendre comment on peut, pratiquement, programmer une quinconce de tuyaux sur une chape ; cela paraît simple (et, de fait, la solution est quand même très accessible) mais il faut y songer avec à l’esprit de traduire une pratique de facture par des lignes de code informatique... Quand on commence à y réfléchir, on se rend compte que même la disposition des tuyaux en profondeur est tributaire de celle en largeur, que l’on a coutume de nommer « la règle de sommier ». Envisager un algorithme qui soit capable de déduire une règle de sommier à partir de plusieurs séries de diamètres est évidemment possible mais cela fait quand même rentrer un nombre conséquent de paramètres qu’il faut établir avant d’écrire la moindre ligne de code...

     En ce moment, je bidouille trivialement sur OpenOffice.org une boite de dialogue capable d’aller chercher des lignes dans des feuilles de relevé pour les monter en trois clic de souris dans une feuille de tableur convertible en CSV à destination de mon gadget de dessin de façade. Même si, pour l’instant, elle ne donne rien, tu pourras en comprendre par ici et par là un peu plus en allant visiter les endroits où je sévis sur le forum adéquat...

     Cela n’a rien de capital, mais ça me fait surtout travailler et comprendre le Basic d’OOo, mais aussi, les bases de données, avec en vue de traduire aisément des relevés de tailles déjà établis dans des pages de tableur. Je fourmille d’idées, mais, évidemment, je ne suis pas développeur professionnel ; donc je rame un brin... Le traitement SQL d’OOo possède encore des défauts de jeunesses qui finiront par disparaître à la longue. Le but est évidemment ODL, c’est-à-dire, à partir de fichiers de données tableur, arriver à des fichiers de données qui soient signifiants pour un ou plusieurs logiciels dédiés. Je dis « un ou plusieurs » parce que si, au départ, je pense utiliser des formulaires de page Web comme interface homme-machine, il n’est pas dit du tout que ce soit une finalité (je suis extrêmement réticent au concept de cloud, ou, en tous les cas, contre la direction que prend cette philosophie actuellement).

     Comme je te le disais plus haut, une fois établis deux ou trois fichiers de tailles, je voudrais arriver à faire un petit algorithme qui traite la disposition en quinconces des tuyaux sur les chapes. Ce n’est pas ce qui m’effraie le plus mais il faut prévoir une interface de saisie assez réfléchie pour engranger facilement l’ordre des tuyaux sur les sommiers, puis, évidemment, la règle de division des gravures de chaque sommier. Au passage, on retrouvera une boite de dialogue très proche de celle ébauchée pour la division des tuyaux de façade que je t’ai montré sur le forum d’OpenOffice.org. C’est une chose sur laquelle je me suis déjà penché, mais OpenOffice.org ne gérait pas encore le format A0 ce qui est maintenant le cas.

     Pour chaque chape, la disposition des tuyaux pourra s’étaler sur une quinconce de une à cinq lignes. Il faudra donc fournir au programme autant la disposition des notes que la distance qui les sépare ; c’est-là le propre d’une règle de sommier.



     Il est facile de savoir si deux tuyaux se touchent en dessinant un triangle rectangle (ici, en rouge) qui prend comme grand et petit côté les deux écarts X et Y des deux tuyaux considérés. Si la distance que forme l’hypoténuse (calculable très simplement par le théorème de Pythagore) moins la somme des rayons des deux tuyaux considérés est égale à zéro, alors les tuyaux se touchent.

     Partant de là, il est possible de programmer une fonction à qui on donne à manger X, Y et Diamètre de deux cercles successifs, plus l’écart minimal entre les tuyaux, sept valeurs en tout dont la dernière spécifie un minimum de matière pour les faux-sommiers, et qui renvoie en retour une valeur booléenne indiquant si la condition d’écart est remplie (vrai) ou dépassée (faux).

  • distance = racine_carrée((x2 - x1)2 + (y2 - y1)2) - (diam1 / 2) - (diam2 / 2)
  • si distance = 0 alors « touché » !
  • si distance < 0 alors « coulé » !

     On peut donc imaginer une itération par pas d’un millimètre, partant du plus gros écart de quinconce (les deux rayons des deux plus gros tuyaux consécutifs cumulés) jusqu’à arriver au minimum inter-tuyau déclaré, en se basant sur le premier écart de la règle de sommier afin de déterminer l’écart de la quinconce (traits pointillés horizontaux du dessin). À charge, pour le programme, d’aligner les tuyaux sur une même ligne (haut, bas ou centré) dès que possible et dans la mesure ou il en est aussi fait la demande (case à cocher). Tout cela n’a rien d’exceptionnel et reste tout à fait programmable, même à mon petit niveau !

     Ce qui est par contre nettement plus compliqué, c’est la règle de sommier... Elle pose problème car elle induit un compromis entre la largeur du sommier et sa profondeur. On peut imaginer imposer la largeur au programme. Ensuite on établit les gravures par la somme des surfaces de perces et on s’arrange pour avoir cette même surface sur la section de chaque gravures en fonction de l’épaisseur de la grille (hauteur de ceinture) fixée, elle, de manière arbitraire. Il est, forcément, d’autres façons de procéder ; par exemple, on peut aussi imposer la profondeur du sommier (dans la limite minimale de la somme des diamètres des plus gros tuyaux de chaque jeu cumulé), puis, faire jouer tout le calcul pour obtenir une largeur de sommier variable en fonction des quinconces de tuyaux. Dans tous les cas, il reste entendu qu’il faille forcément choisir une méthode au détriment d’une autre pour commencer à programmer en ayant toujours à l’esprit la possibilité d’envisager l’algorithme avec une autre méthodologie.


__________________


     Ce genre de réflexion ne peut, bien entendu, pas se faire seul, et je suis heureux de pouvoir te témoigner ici de la mienne puisqu’aussi bien, je sais que tu ne manqueras pas de la suivre, sinon de l’éprouver comme seuls les amis savent le faire. Nous avons, toi et moi, décidé d’échanger en public parce que nous pensons, je crois de manière commune, que ce n’est pas en restant dans son coin les volets fermés que les choses progressent et fleurissent. Cette réflexion, quoiqu’un brin technique, pourrait tout autant s’ouvrir aux apprentis et déboucher, en synthèse, sur des pages Web plus riches encore que celle du bénédictin qui ne fournit que des règles de sommiers toutes-faites comme le voulait l’usage de son temps... Je crois énormément pour ma part à la nécessité d’une synthèse écrite (pas seulement du blabla forumiste non rédigé) qu’à la nécessité d’ouvrir autant le code informatique que la réflexion qui l’a pétri, puis engendré.

     Gageons que ce soit encore possible ; notre génération nous offre tous les outils pour cela et il ne valent que le prix que nous saurons leur donner par la pratique maîtrisée de leur possibilités.

     smoking smiley
Seuls les utilisateurs enregistrés peuvent poster des messages dans ce forum.

Cliquez ici pour vous connecter