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.
