> > My bias is toward declarative because it encodes information, not > > instructions. I wrote my thesis on the topic of transforming one > format > > into another -- loosely taken, this means "music information > retrieval." > > In that case, you probably know that converters are easy, if the > source language is documented and parsable, and the target language is > expressive.
It think this is the direction in which lilypond is going on. I would like to sharpen my critisism. If only the default settings are used, the language is already nearly declarative -- in principle, perfect midi output could be rather easily compiled from such a declarative input. > > To be most useful, I believe music files ought to simply state *what* > is > > there, and let the engraver decide *how* to engrave it. I know this > is an > > over-simplification, but for the sake of brevity I'll leave it at > that. > > You did not, by chance, devise a nice declarative music langugage? > Would you like to send a little example? Instead, the music which is described declaratively cannot be always typeset the most beatiful and compact way using a straight-forward prosedure; the tighther the music is typeset, the more compromises have to be done. With compromises I mean collisions between graphical objects. In this case, an user may want, for example, to show only the first staccato dots and slurs, tell then that the following notes are to be played similarly, and leave the the other staccato dots and slurs away. Once notes are put in, everything is still declarative. For example, up- or down-typeset slur has no meaning in played music, but they exist in typeset music. When all the voices are put together, the relations between the notes should be shown in the typeset music. You may show polophonial music by putting all stems and slurs in a voice in the same direction, show (de)crescendi, etc. Stricly speaking, in played music the relations between individual notes are not present -- there are only individual notes (mathematicians may do Fourier analysis). The relations between the notes are the result of the culture of the music, and this culture is written down in the form of written music (nowadays also in the form of records). To summarize, an important problem in typesetting music is to give instructions how the music given in perfectly declarative manner can be shown the most compact and 'authentic' way. With authetic I mean not only perfect playing, but also the state of mind of the music player. Such development is on progress in LilyPond, I'll give few examples: scripts in midi (script-chart.ly): http://lilypond.org/doc/v2.3/input/test/out-www/collated-files.html#index-Feta%20scripts-83 writing trills in full (trills.ly): http://lilypond.org/doc/v2.3/input/test/out-www/collated-files.html#index-Trills-114 part-combiner (part-combiner.ly): http://lilypond.org/doc/v2.3/input/test/out-www/collated-files.html#index-Part%20Combine-66 different font styles (ancient-font.ly, etc.): http://lilypond.org/doc/v2.3/input/test/out-www/collated-files.html#index-Ancient%20Font-4 Therefore, declarative input fits perfectly for a midi parser or the player of the music, but for a typesetter there needs to be instructions. I would recommend that we would state that the declarative part of LilyPond is already in a rather mature state. It is the instructive part which is under active developement. You may typeset loosely without compromises, but in order to typeset tightly, you need instructions. Greetings, Heikki Junes _______________________________________________ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
