On 9 août 2012, at 11:05, Graham Percival <[email protected]> wrote:
> Not much discussion after the mid-way point. I'm not certain if > this means that everybody agrees, or they just think I'm > completely wrong and it's not worth even discussing it (as > happened with the first proposal for stable release handling). > http://lilypond.org/~graham/gop/gop_4.html > > > ** Summary > > Let’s start stabilizing portions of the LilyPond input syntax. We > will guarantee that selected elements of the syntax will not > change (even with convert-ly) during the 3.x releases. This will > be a slow process, and the first phase (2012) will not even cover > the entire “single staff notation” section in the tutorial. > > > ** Motivation > > Some “computer languages” are fairly stable. A TeX or C++ program > written 10 years ago will probably still compile with no > modifications (notwithstanding the g++ 4.3 header and namespace > changes). The same is not true of LilyPond; even after using > convert-ly, there are still bits that require manual updating. > > Given that, LilyPond is not suitable as an archival format for > music. It can produce a great pdf when you first write the file, > but the .ly files require regular maintenance if you want them to > compile in the latest stable version of lilypond. This is a > problem for projects such as mutopia – a large fraction of their > .ly files don’t compile with current lilypond. That means that > they can’t benefit from recent bugfixes; users wanting the sheet > music in a different size (say, printing a choral score as an A5 > booklet) must delve into the ly code and make manual changes. > > A stable input syntax should also make it easier to write > converters to/from lilypond, and should also make it easier to > write GUIs for lilypond. Currently, any program which exports > lilypond code needs to support multiple versions (e.g., 2.12 vs. > 2.16). Hopefully making it easier to output lilypond code will > lead to more/better programs which do this, either in terms of > converting from alternate formats into lilypond, or in terms of > GUIs calling lilypond as the backend. > > On a personal note, this is one of the biggest reasons I’ve given > up on using lilypond personally. From 2001 to 2004 I got a minor > in music composition. I carefully kept all my .ly files but > foolishly did not preserve the pdfs. And now, 10 years later, I’m > left with a bunch of music that I cannot generate sheet music for. > It’s true that I could dig out old lilypond binaries to process > the ly files (and I’ll probably tdo that at some point), but it > would be much nicer if I could benefit from the past ten years of > bugfixes in lilypond. Manually updating the .ly files would take > hours or days; I’ve started this process a few times but always > lost interest after a few files, since there’s no guarantee that I > wouldn’t need to go through the same process in another few years. > > > ** Why disallow convert-ly? > > it forces us to take the process seriously by removing the > "safety net". Any poor decisions from the process will be > enthroned in the syntax for years to come[1]. Hopefully this will > make us proceed cautiously, take a more serious look at the syntax > proposals for potential problems, etc. > it signals to other projects that we’re serious about this. > This makes tasks such as writing importers/exporters to/from > lilypond much less undesirable. It also might help people doing > musicology (or music theory) research with lilypond files. > it makes lilypond more suited to being an "archival" format > (or at least less unsuited). convert-ly only converts files in a > forward direction. Granted, there aren’t many instances where > somebody might have a corpus of music they want to render in both > lilypond 3.0 and 3.2, but it’s not impossible. For example, > suppose there was a team of a dozen Russian musicologists > archiving folk tunes, but lilypond 3.2 doesn’t work on OSX 11.4 > because Apple broke their own API again. It would be nice if the > team could share lilypond files between lilypond 3.0 and 3.2. > (assuming that there were no special tweaks happening – i.e. the > team was first getting the notes and rhythms written down, and are > not planning to do a great deal of tweaking). > > > ** Will this help the parser? > > Straightening out the parser is going to lead to some breakage in > complicated and/or badly written scores. That may lead to some > understandable frustration from some users, but if we’re running > GLISS at the same time, that gives them some hope that things will > settle down. Also, simply discussing the notation we wish to > support will give rise to questions about precisly what the > current system already supports, and can clarify our thoughts on > it. > > > ** Not necessarily any changes > > GLISS will not necessarily involve any change of notation; in > fact, the first portion of “syntax stabilization” could just end > up approving the existing syntax exactly as it stands. I think we > should discuss each notation element separately without simply > rubber-stamping the existing syntax. If there are any changes in > the basic notation, then of course it would be extremely bad if > convert-ly couldn’t handle it. But the end result of such > discussions could lead to the conclusion that any disadvantages of > the current notation outweigh the pain of changing. The important > thing is informing users (and programmers) about what elements are > guaranteed to work for every 3.x release. > > > ** Subset, not complete definitions > > When we discuss something like accidentals, we’re not committing > that the finalized syntax will be the only way of achieving the > relevant goal. For example, if we standardize on cis to indicate a > C sharp, then at a later date we can still introduce syntax such > as c+1/2 to indicate the same C sharp (the latter possibilities > are to allow more greater flexibility for microtonal notation). > Multiple rounds of standardization > > It’s really easy to under-estimate the work that goes into such > discussions and implementing the changes. I think we should start > very small and expand gradually. At the present time, we will > decide on what to do in the first round only, but I’ll add a very > tentative suggestions for rounds 2. There will be another GOP > discussion to settle on the exact range of notation tackled in > round 2. > > The basic idea is to spend approximately 3 months discussing some > changes, then spend a few months implementing the changes (with no > syntax discussions). Then we’ll have a stable release, and wait > for at least 6 months to see of there’s any complaints with the > input syntax; if there’s no complaints, then we’ll declare that > part of the input syntax to be “finalized”. > > Round 1: note pitches (absolute and relative, common 12-tone > accidentals only), durations (powers-of-two and non-nested > tuplets), key signatures, time signatures (non-compound), bar > checks, dynamics, partial measures and grace notes. Also setting a > title and composer, and outputting in pdf and midi. Expected to be > implemented by the end of 2012 and finalized by the end of 2013. > Round 2: ties, slurs, articulations, adding text, manual > beaming, chords, multiple voices on a staff, multiple staves, > lyrics, variables/identifiers. > > > ** Subset for first phase > > In greater detail: I’m suggesting that we have multiple rounds of > syntax stabilization. The proposed elements of current lilypond > notation which we will stabilize is captured by these two files: > > \version "2.16.0" > \header { > title = "don't overwrite this title" > composer = "the lilypond GLISS team" > } > \score { > \new Staff { > \new Voice { > \partial 8 d8 | > c4 d' e, f'' | > \times 2/3 {a4 b c} \grace {d16} d2 | > \acciaccatura {b16} c2 \appoggiatura {b16} c2 | > } > } > \layout {} > \midi {} > } > > \version "2.16.0" > \score { > \new Staff { > \new Voice { > \relative c, { > \clef "bass" > \time 3/4 > \tempo "Andante" 4 = 120 > c2\mp e8 c' | > g'2. | > \time 6/8 > \key d \major > \tempo "Allegro" 4. = 120 > f4.\f eisis8 eis r | > deses,8 des r e'8 c c,8 | > } > } > } > } > > and then we guarantee that these files will compile, completely > unmodified (no convert-ly allowed), for every lilypond 3.x > version. This seem like a really small step, but I really don’t > think that we can overestimate how much time, energy, and > arguments this will require. > > ** Example questions > > Here’s a few sample questions that we’d encounter even with a > really small subset. > > PLEASE DO NOT DISCUSS THESE RIGHT NOW. > > do we keep dutch as the default language, or switch to > english? > do we finally make that \times -> \tuplet change that’s been > discussed for years? > \score \staff vs. \new score \new staff. > what’s the canonical input structure? what shorthands do we > commit to supporting? > > - Graham > > _______________________________________________ > lilypond-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/lilypond-devel I'd sent out a note of agreement before but I'll send out another one just to signal that I'm 100% for incrementally freezing parts of LilyPond's syntax. Specifically, I'm comfortable saying that everything in the examples above should be frozen. Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
