On Wed, Jul 25, 2012 at 04:58:57AM +0000, Keith OHara wrote:
> Graham Percival <graham <at> percival-music.ca> writes:
>
> > 2. Define a subset of input as being stable for the 3.x branch.
> > We add regression tests for that subset of notation and
> > forbid running convert-ly on those files.
>
> Why forbid convert-ly? Is the idea to freeze the syntax that many
> users have already committed to memory ?
No, users memorizing syntax is the least of my concerns. :)
Reasons in favor of disallowing convert-ly for the specific subset
of "stable" syntax:
1. 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.
2. 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.
3. 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).
To clarify, all the bits and pieces of point 3 were taken from
real-life occurrences in lilypond over the past two years (other
than the version numbers which are obviously made up). It's not
far-fetched.
> > At the moment, I
> > imagine that the subset would consist of at most Notation
> > sections 1.1 Pitches, 1.2 Rhythms, and the overall file
> > organization; nothing else. Changes to input other than that
> > subset are fine.
>
> These sections also cover recently-added features like auto-beaming
> overrides, and modal transformations, which might someday be improved
> with a syntax change that convert-ly could handle.
Oops, yes, I'm not thinking about auto-beaming or cadenzas at all.
> There are some GLISS topics that would take longer to get right, such as:
> + whether we should implement {c4 d e f}*4 to repeat a sequence
> + whether to disallow some unusual syntax that Lilypond currently
> allows, but which prevents LilyPond from recognizing numbers in variable
> names.
>
> Such changes would affect what is allowed in the notation covered by
> Pitches and Rhythms, but would not affect the "forseeable usage" core
> notation as preserved in those regression tests.
There seems to be a surprising amount of agreement with the idea
of stabilizing a subset of our notation. However, most people are
thinking about much more advanced syntax than I think we can do.
To "rein in" some of the ideas, I'll toss out the following:
- let's not plan things too far in advance. I think we should set
a reasonable SMALL goal for stable syntax at the end of 2012.
Once we've achieve that (or not), we'll pause for a while, look
at what worked and what didn't, and then plan the next round
of stable syntax discussions for 2013.
- with that in mind, I can think of a few different ways of
picking our small concrete goal:
1) pick a piece of easy music, then stabilize the syntax for that
piece. Suggestions:
- Mike has part of a Handel anthem.
(it has footnotes which are far too complicated, but those
could be removed in the "syntax subset" version)
- prelude to the Bach unaccompanied suite in G minor
- one Bach chorale
2) strive for compatibility with other music formats, e.g.,
- stabilize lilypond syntax that affects MIDI output
(notes, rhythms, ... I guess ignore the instruments for now?)
- I know that SVG has a "svg tiny" subset; is there any
subset of musicxml?
3) make an ad-hoc list of notation. For example:
- Dutch note names, division-by-two and triplet rhythms,
general syntax, and dynamics. No slurs, no articulation,
no repeats, no lyrics, etc.
I really want to emphasize that we cannot over-estimate how much
work this will be. Also, there's no problem starting a second
round of discussions if the first round goes really well and is
implemented without problems.
BTW, in case you think that music without slurs is useless -- some
cello teachers swear that the best way to learn the Bach cello
suites is to start from sheet music with only notes and rhythms,
then write in your own slurs, dynamics, articulations, fingerings,
etc. A stable syntax which only handles MIDI and/or my ad-hoc
list of notation would not be useless!
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
