My main critique of the lilypond language design is and every extension would run into the limitation that the human brain has bounded processing power (while playing an instrument, you cannot usually run an interpreter for full lambda calculus in your brain - so lilypond did that for you).“visible abstractions” (that is, notational conventions for sheet music) are well-established over hundreds of years, so every-one knows them, but no-one would agree on extensions,.abstractions that appear in the source (e.g., \repeat unfold, named music expressions) and are interpreted by lilypond.abstractions that appear on the sheet (e.g., volta signs, chord names, staffs) and are interpreted by the musician,.You cannot put each note in the source by itself, and also not in the score sheet, so you use abstractions. The big challenge in the design of a textual music (representation) language is the following: You have to go from source text (what you type when you create the score) to score sheet (what you look at when you play) to actual music (what you hear). If you want a compressed representation on the page, but all notes in the MIDI, then you must do music = > % > have equal length. Lilypond has several ways to denote repeats. Lilypond is a command line program that reads a textual description of music and produces a graphical description and MIDI.Ī very short lilypond program is \score I do not necessarily want to make this text longer than it already is, but I do want to repair errors, and perhaps add specific links to original documentation. Sometimes, I asked on the mailing list and I do appreciate the help I got.Īlso, I invite comments (by email) on this text. In several cases, I later found that the information had been in the docs all along, but I did not know where to look. While writing this text here, I am trying to remember how I learned lilypond, and what was the information that I was missing the most. So, my typical score will exercise most of the basic features of lilypond, but probably just very few of the advanced ones. For reasons of copyright, I don’t publish these scores. That is, a song absolutely must fit on one page, and you want to see global structure, chords, voice plus perhaps some extra snippets for a typical instrumental or vocal accompaniment, or break. I should add that my application area is writing scores in the style of “real books” (for jazz and rock), to be used in a hobbyist band. Certainly a musician is capable of structured thinking? Music is structure that you can hear. So, the following is my attempt to explain lilypond in a “semantics first” way.Īnd I do think this kind of documentation would serve both groups of users well. We can infer some of the underlying semantics from that, but the description is mixed with implementation detail that a plain “user” does not need. There is a subset of lilypond documentation targeted at programmers that want to extend lilypond. (Of course there are enough under-documented programming languages and libraries out there, but I avoid them.) I find that lilypond docs are lacking in structure and exactness when compared to definitions of general or domain specific programming languages that I usually work with. I am a professional computer scientist and a hobby musician (at best). It seems that the documentation targets (semi) professional musicians that are hobby programmers (at best). I find it difficult to infer from that the underlying principles of the semantics of the language. Most of it consists of examples that show syntax and semantics of individual features. In the words of the authors, “ LilyPond is a music engraving program, devoted to producing the highest-quality sheet music possible.”
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |