Hi, Last week I had the opportunity to talk about LilyPond in conjunction with my music as part of a presentation I gave at University College Cork (UCC) in Cork, Ireland. I made the presentation to a mixed group of 10 or 11 masters and doctoral students in composition who meet for classes regularly during the week with Dr. Jesse Ronneau. I gave the talk in the UCC computer lab and I used the last hour and half of the three-hour session for a guided, hands-on LilyPond tutorial. All parts of the presentation went great and I thought I would provide some feedback. I hope to follow Cameron's model here ...
http://lists.gnu.org/archive/html/lilypond-user/2008-10/msg00886.html ... from this thread in October. * * * The presentation I chose to give at Cork divided into two halves. In the first half I went over some of my own music (and the music of Víctor Adán) and talked about how it is that the two of us came independently to use the Python programming language together with LilyPond as a powerful way to control musical score symbolically. Víctor (who's another frequent member of the list) and I went through a whole series of tools -- from C, Java and Mathematica to Finale, Sibelius, SCORE, Illustrator and AutoCAD -- before we both independently settled on a Python / LilyPond approach to what you might call Symbolic Score Control (SSC). What I'm finding is that composers working in a variety of different styles at different universities are interested in this sort of thing. And I'm happy to be able to point to LilyPond as the notational 'engine' that powers the system of SSC that Víctor and I have built collaboratively over the last couple of years and in which I've first modeled and then notated all of my work since 2005. I used the second half of the presentation as a hands-on introduction to LilyPond. OS X workstations were available for everyone and so I worked a series of introductory examples off my laptop projected onto the wall. Of the 10 or 11 composers in the room, only 1 had previously heard of (and downloaded) LilyPond ... though all were interested in the tutorial and everyone stayed for the second half of the talk to try things out. The level of programming experience in the room varied quite dramatically: there was at least one programmer in the room with a reasonable command of Java, some HTML experience, and quite a few students who had never typed a line of code before. That being the case, I selected the following examples in this order: 1. LilyPond hello world which, for me, has always been \new Staff { c'4 } together with the an appropriate \version and \include commands. Right away this gives me the opportunity to talk about LilyPond commands beginning in backslash, notenames according to language, different versions of the program, and the European way of naming octaves with dancing ticks and commas. 2. The C major scale and the quatertone scale. For some practice in entering notes and getting some immediate visual feedback. Once there's more than a measure of music we get to talk about LilyPond as an 'auomated engraver' and watch barlines and time signatures draw as if by magic. We also get to talk about spacing and indentation of input and LilyPond's laxity towards whitespace. Perhaps surprisingly, the composers in the room tried out all sorts of different approaches to spacing and indentation, some much more successful than others. I suppose the freedom of being able to lay out input arbitrarily can be attractive ... though this made debugging a real problem in one or two cases by the time we reached manual polyphony in #7, below. 3. The 'stickiness' of durations and, with \relative, of pitches. 4. Note 'decorations' with \staccato, \marcato and the like. Which lets us talk a little about why \staccato followed by \marcato generates exactly the same output as the reverse. 5. Note \overrides with something like \override NoteHead #'color = #red and the corresponding \revert. This lets me show one of the more useful bits of syntax that users are likely to encounter at some point on their trip through the docs and to defang the syntax of its potential weirdness right up front. Actually understanding that the # signs are escaping constructions in Scheme under the hood is irrelevant at this point and the focus is on understanding that all sorts of different symbols like # and ' and , and \ are important and should be typed in just like you find in examples in the docs. Plus turning a string of notes bright red helps make the point of exactly what scope \override ... \revert pairs have on the lexical input. 6. Chords ... and ... 7. Explicit polyphony with << \new Voice { } \new Voice { } >> and manual Stem overrides instead of \voiceOne, \voiceTwo as an example of building up context settings by hand. * * * It was just possible to fit this particular sequence of examples into an hour and a half and I think they really worked. The students saw new bits of notation after every example and asked questions that made good sense throughout. Some questions were surprising. For example: * "I like the fact that \include "english.ly" lets us type notenames in English but is there a way to type in #'color in *our* language, ie, as #'colour?" (Which let me talk about how we use American English as a compromise and also to point to the international make up of both the developer and the user community of the program ... as well as pointing to the glossary in the docs). * "Why can't I type \new staff { } instead of \new Staff { } or \new voice { } instead of \new Voice { }? Note names don't have to be capitalized so why do I have to capitalize Staff?" (Which made me realize just how carefully I need to watch the details when working with new users and also that I probably needed a better terminal font to help distinguish lower- and uppercase characters on the projector). * "If I wanna put \staccato on a bunch of notes in a row, do I have to retype \staccato multiple times?" There were also questions of a more general nature, such as: * "Do you personally think the lack of GUI is a weakness of the program or a strength?" (Answer: a strength, for me anyway.) * "Why is the software free? Doesn't somebody wanna charge money for this?" (Which was a good opportunity to talk about how open source projects work and what motivates us as developers and users of open source software.) Importantly, LilyPond was installed only on a central server at the UCC labs before I started the tutorial: I thought this would spell disaster because we'd have almost a dozen installs going on simultaneously at the beginning of a tutorial. At least one or two, I was certain, would fail and make me eat up valuable time changing config settings somewhere. But no: every single install of each instance of LilyPond worked correctly the first time. And that at the hands of a roomful of new users who had (with one exception) never once seen the program. If that doesn't say something good about our build / package / distribution system then I don't know what does. * * * In the end, the second half of the presentation covering the hands-on LilyPond tutorial went off without a hitch and got at least three or four composers interested enough to start using the program on their own. The program demos well in its current form -- which was only 2.10.33 or something similar on the lab computers, I noticed later -- and gives attractive, professional output that graduate students working in a variety of different styles take serious at first brush even when coming from a Finale- or Sibelius-only background. If there are any questions or comments, let me know. This talk in Cork follows (and improves upon) a similar talk I gave last year at UCSD in San Diego. In both cases the feedback was similar: genuine interest from composers working in quite different ways. Trevor. -- Trevor Bača [EMAIL PROTECTED]
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
