The computer

The usefulness of O.D.L. (Organ Definition Langage).

Thoughts of an organbuilder on computer science.

Version française    Deutsche Version    		L'Hydraule

Note from the author:

It is necessary to clarify here that the English version of this text is a result of an automatic translation corrected by myself for specific things of the organ. Unfortunately I don’t speak English enough to provide to the public a version worthy of the language of Shakespeare. Also, the reader will forgive me for even multiple faults, all of grammar than spelling, which abound in the following lines, but who, neverless, allow to the English readers to understand the content of this text as long as I didn’t find a translator worthy of this name.

Note on Friday 21 August 2009:
I very much would like to thank Adrian Wadey of the Solid State Organ Systems companie took the time to correct these lines that I know hardly readible to the public and whose thoughts on what could make a language like ODL as open standard combinations. This will, of course, part of a discussion to follow.

  S.M.C.J.




Anyone who has at some time tried to publish on the web knows the basics of HTML. It is a mark-up language. The text to be displayed in browsers is wrapped up in Internet tags which themselves are not intended to be displayed but to control how the text is displayed. For those who do not know the principle (or to refresh the memory of those who have forgotten) here is an example so you can see this basis for publication on the web.

Take the example of a very simple sentence: "The name of the Rose.". Give it as is to a Web browser and it will display normally in a standard font and without any formatting. If you want the word "name" displayed in bold, it is necessary to enclose it in two tags, one opening and one closing, which gives this:

The <b>Name</b> of the Rose.: "The Name of the Rose.".

Had we wanted to use italics or underline the word, instead of using the tag <b> we would use <i> to get italics or <u> for underline. Many, but not all, opening tags have a closing tag to turn off the formatting. This is of course true for italics or underlined. Some tags allow you to change the colour of the text. These are tags which have one (or several) attributes. Thus, to display the word "Rose" in pink, you must write the HTML code:

The Name of the <font color="pink">Rose</font>.: "The Name of the Rose.".

It should be noted that it is a <font> tag, that serves to change the font and in addition the tag may have, among other things, a "color" attribute and an "=" sign with a color between quotes. From this you will understand that it is easily possible to write:

The Name of the <font color="green">Rose</font>.: "The Name of the Rose.".

for a Martian rose...

HTML has a large number of tags and here is not here the place to describe them all nor the specifics of their syntax. The HTML language was created at CERN in Geneva in 1989 by Tim Berner Lee. From the late 1990s there arose the question of the structure of the language itself (its syntax) and from this the extraordinary hierarchical tree structure of the language emerged. In fact, every Web page is first constructed as an HTML entity, within this there is a header and a body, within this again are paragraphs containing text, and so on. The header of the document itself can contain a title, style definitions, script commands to dynamically modify the document etc... The structure of an HTML document may take the form:

    <html>
     <head>
      <title>
       I am the title
      </title>
     </head>
     <body>
      <p>
       I am a paragraph with the word <font color="pink">Rose</font> in <font color="pink">rose</font>.
      </p>
      <p>
       I am a paragraph with the word <i>italic</i> in <i>italic</i>.
      </p>
     </body>
    </html>

There is talk of root (the <html> tag) which gives rise to nodes and childrens. But the fact that the tags contain words such as html, head, body, &c, is ultimately less important than the tree structure. For this reason, writing computer often written using indentation, ie shift to the right the words according to their interlocking in the tree. This indentation is not taken into account by the reading of the computer. For against, it helps to read and understand the interlocking elements of the language among themselves.

All words tags refer to the formatting of a text document, which may contain images, audio or video, but whose final destination is first that of a Web browser capable of interpreting and , especially (since it is the main aim of all HTML pages) can use hypertext to link documents between them, regardless of the physical place they occupy on the computers on the planet.

But it is quite possible to imagine totally separate vocabulary specific to HTML and replace it with another, invented from scratch, for the purposes of any other cause than to view a Web page but retaining the tree structure which all processing is so fond. In practice, this may, by example, giving this:

    <organ>
     Saint-Hippolyte-du-Fort
     <keyboard>
      Grand Orgue
      <stop>Montre 8'</stop>
      <stop>Prestant 4'</stop>
      <stop>Flûte 4'</stop>
      <stop>Fourniture III-V</stop>
      <stop>Bourdon 8'</stop>
      <stop>Cornet IV</stop>
      <stop>Flûte 8'</stop>
      <stop>Trompette 8'</stop>
     </keyboard>
     <keyboard>
      Récit
      <stop>Flageolet 4'</stop>
      <stop>Flûte douce 8'</stop>
      <stop>Haut-bois 8'</stop>
      <stop>Voix-Humaine 8'</stop>
     </keyboard>
     <keyboard>
      Pédale
      <stop>Bourdon 16'</stop>
      <stop>Flûte 8'</stop>
     </keyboard>
    </organ>

Because the structure of the organ is extremely hierarchical, because you can quite describe how much further the ramifications of the tree (a stop contains sets of pipes - wood, metal, open, closed, with chimney - and the types of specific measures, &c.), it is possible to describe almost anything and everything in our instrument by following this principle, as long as the focus - still - to respect language tag defined in referential (and therefore, very flexible). We talk of XML, the first X of the acronym is called the signifier of eXtension, since is first concerned with the structure rather than the form. It accepts XML thousands of ways and it is no detail specified by MusicML open format that allows you to write music in a standard way.

In computer terms, the benefits are enormous. The first to receive the organ seems to be in the sustainability as documents written in XML are in simple text files. The format should be human readable and must always have the opportunity to alter the code manually. The mere reading of the composition of organ foregoing demonstrates that software can read <keyboard> and understand as a meaningful entity, ie, exploitable under specific conditions on that it deals.

And that's the whole point of a markup language as also the significance of its syntax, the tags are for specific software, carry much more meaning than the cell contents of a spreadsheet. Moreover, the extraordinary flexibility that allows the arrangement of data into a hierarchical tree structure is infinitely better than the tabular structure of databases, much further away from the structure of our instrument.

Knowing that the first C of Montre made of 145 mm and that the calculation of progress follows the formula of Cavaillé-Coll based root forty-eighth of six is one thing; exchange statements of plans, without the slightest problem translated into English, German and Japanese is another. We have in Europe the chance to own a organological heritage an extent that the other four continents can be envy. But we also, still in Europe, ultimately little taste to magnify our know-how, often preferring to let our knowledge resting in the shade of the library, or even lose our knowledge gained since the abundance of our culture allows us to shine often without the slightest effort...

Since I believe I am the first (if not the only) that I looked at this problem, the first meaning example of using XML in the field of organbuilding is, curiously, not in the simple setting database of organ compositions but in the much more specific arrangement of mixtures. The reason is simple: an arrangement of mixture, for the organbuilder, is a thought that might have nothing aesthetics but that can be purely accounting, so practice. The same applies to the scales pipes that, if it gives a musical idea of where it goes, must be able for the worker, to be followed by planning practice. In this, I think that I am in right line of a monk of the Benedictine Congregation of St. Maur with a history of organbuilding that did not to much suffer...

A few years ago now, so I have programmed an organbuilding utility (which was not exactly my first...) and it was tasked with planning the same pipes of mixture. The task is already difficult enough with a spreadsheet; it is even more so with a Web browser whose forms are not exactly planned for organbuilding data processing (and one wonders why for that matter)... But I still come to produce a favorite of some French pipemakers for one simple reason: apart from the outflow table, it emerges very simply and cheaply (in art ASCII), the map of mixture. Moreover, because very didactic, it is very easy for the learner to understand the problem of mixture once after viewing the map that appears each pipe and the educational aspect of things, within the exchange and continuity of know-how, was rather far from displeasing me. Of course, where the apprentice discovers a practice, the expert can demonstrate the presence of sound masses, favoring a particular area of the frequency spectrum that the mere statement of the arrangement gave not necessarily understand..

My utility had several flaws that should be corrected (there always has to be refined, but they are not fundamental). It was not multilingual and asked to perform data entry into two separate stages (two Web pages to produce a third, in terms of PHP programming is realy too...). Above all, it did not save the data as input data structure even if it was indeed already possible to make a copy of the data produced in several formats. But at no time did they came out of the scheme of data to be published in the form, not in the sense...

"Tempus fugit". But time can often provide much without any effort. Strict view of the evolution of Web browsers and languages used on the Internet over the last ten years have obviously not missed to be so much fruitful. XML, still very young in the early 2000s, where I developed my utility, has not made much progress. Anyway, for the purpose of being verb (meaning) to be before the word (overt), XML is so trivial that we know it will change little. For against, the languages that can turn around and have to treat them, greatly advanced in recent years. PHP or JavaScript, and especially the D.O.M. specification became objects with which we can now work easily, even if we does, as in my case, computer science that dilettante and autonomous.

Receiving an email from a young organ enthusiast proposing to put a link from my website on his own, I realized that the young generation (the one that I really do not belong...) there was the question, it, much to use the Internet effectively as the one before. Responding positively to this request, I returned to my notes, sometimes very old, but still of course available (computer controlled, it serves to this). Apart from the fact that to be very careful notes, I still remember the procedures used in my utility of outflow of mixture, I had also, in all these years, acquired the certainty that XML could one day be used in organbuilding, especially in data storage restorations that we arrive, here in Europe, and as an organbuilder restaurant worthy of the name, to publish.

The email from my young organ passionate has had the advantage of me wanted to reworked my utility. And I did, this time, reaching the programming there. My original three pages written in PHP is reduced to one, it was possible to envisage their Japanese translation but, finally, a prototype of ODL was emerging with the power to demonstrate his abilities as long as the we give ourselves the trouble to reflect on the meaning. Of course I chose English as the language center of my tags, but this did very little importance to a specification with the tag <kb> (keyboard) rather than <clavier> or <werk> since software and will be obviously to bring in a transparent manner these instructions defined in the language and present the data so much fun as reading a code. In fact, it is undeniable that the English language is particularly suited to be recovered in the form of code, but that is another debate.

As any implementation of program, things have taken place in stages. At first I almost completely rewrite my form to make it much more dynamic, and license the ODL export that was not originally programmed. Finally import, that which opens doors as I had interviews.

Because once made software production of ODL file, things are accelerating for the least power in combinatorics it becomes possible to:

On the web site of "l'Hydraule", the URL adress of my treatment utility of mixtures is:
"http://hydraule.org/bureau/ordi/pleinjeu/pleinjeu.php" Text in French..

So you download the file "pleinjeu.php" in your browser. If the address is given as-is, the page is displayed in French. It should specify the language in the address for a display in another idiom. For example, in English the address is:
"http://hydraule.org/bureau/ordi/pleinjeu/pleinjeu.php?l=en".

Following this principle and using the additional separator "&", it is possible to write the URL in the form:
"http://hydraule.org/bureau/ordi/pleinjeu/pleinjeu.php?l=en&f=0&url=http://hydraule.org/bureau/ordi/pleinjeu/src/exemples/PJ_STH.odl"

There are three variables that are passed in the URL to the file "pleinjeu.php":

We must understand that "pleinjeu.php" fetches the file "PJ_STH.odl" which can be anywhere in the world and will display it in a format "f" where:

Imagine the power... Very small data files containing highly calibrated, in a format readable by humans in two hundred years but readable software or web pages capable of obtaining a sense, to use the data to derive others, even to cross it...

For it is not finished and it does that even begin...

Reading the contents directory of this server allows to realize that I put the examples of arrangements of mixtures. An ascendant Germanic mixture type, a ceiling mixture French style, the mixture of the historic organ of Saint-Hippolyte-du-FortText in French. and the three mixtures of the historic organ of AuxonneText in French..

This last one is interesting because it is spread over three distinct stops, each with its arrangement. In server directory, files are naturally called "Aux_PJ_GO.odl" for the Plein-Jeu of Grand-Orgue, "Aux_FourIII_Pos.odl" for the Fourniture of Positif and "Aux_CymIII_Pos.odl" for the Cymbale of this last keyboard. For each of them, it is easy to read that the ODL code contains as many tags "<RANK></RANK>" that each stop contains ranks, so three ranks for the two stops of the Positif and eight for the stop of Grand-Orgue.

Reading the ODL code of file "Aux_Plenum.odl" demonstrates that it is just a concatenation of three files of data between the tags "<MIXTURE></MIXTURE>" and added comments (in tags "<!--  -->" ) can, of course, to facilitate reading. This is so just a copy/paste into a text file! And this allows, from a file of less than 4 kb to produce this or that with a simple combinatorial of URL...

Merging arrangement is so already possible in part with a simple text editor to the extent that the reported times are the same composition of a mixture and the layout of notes, from an arrangement to the other, is identical both in their numbers and in their "holes" (no first C #, short octave, &c.)

The merger arrangement so consists to:

I have for the time not programmed utility to fetch multiple separate files on hard drives to merge without manipulation of code, but I know it is very easy to do because the reading of ODL, which is pure XML, is extremely easy to program in PHP. Because of its simplicity, the power of this language is astounding and allow to organ people of the world to exchange data regardless of specific language. It becomes possible to create a standard organ database compositions in all places and all times, which would be highly beneficial to everyone. It would arise over the huge problem of changing standards of spreadsheets, databases or simply softwares because, in fact, XML was designed to cross the centuries.

This does not in any way to capture data on software like M$-Word, M$-Excel or OpenOffice.org as this softwares can extend their capacity through macros. For users of this office suite, I have proved hereText in French. that it is easy to use the power given by this softwares to produce datas, standard and shareable, even though I remain convinced that web forms have the undeniable advantage of lightness in their modularity.

In all cases, there is no problem to recover and unite the data set as text, graphic, sound or videos. The organ drawings could be translated into SVG which is a already established standard vector graphics, obviously compatible with ODL to be, itself, pure XML... Because significant, the scales of pipe organs saved in ODL files could lead fairly quickly windchest grids, so rollerboards. The scales files could be translate themselves into graphic files, such as abacuses scales that Dom Bedos engraved on copper plates in 1766 by the simple translation from ODL to PDF format. Having been used in some articles on the methodology of the calculation of organ pipe scalesText in French., the utility already exists; it is a simple matter of establishing standards and the adaptation of a few lines of code...


My God, I have a dream, were you in?



----------------------------------------------------
                          _
                         | | _
         Sébastien       | || | _
         Matthieu        | || || | _
         Cosson          | || || || | _
         Jacquet         | || || || || | _
                         | || || || || || | _
                         | || || || || || || |
                         | || || || || || || |
          ,-~~-.___.     | || || || || || || |___
         /  | .     \    |_||_||_||_||_||_||_|  /|
        (   )        O   |_||_||_||_||_||_||_| / |
         \_/-. ,----'   / V  V  V  V  V  V  V /  |
            ====      _/____________________ /  /
           /  \-'~;  /|  The Organbuilder   |  /
          /  __/~|  /_|   and his organ     | /
       o=(_______|  |_|_____________________|/
  
  ----------------------------------------------------
     Site web : http://www.hydraule.org
        E-mail: smcj@hydraule.org
  ----------------------------------------------------