[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP2-3 - GLISS or not

From: Joseph Rushton Wakeling
Subject: Re: GOP2-3 - GLISS or not
Date: Thu, 26 Jul 2012 12:45:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0

On 24/07/12 10:09, Graham Percival wrote:
Let’s decide whether to try to stabilize the syntax or not. What
type of project do we want LilyPond to be? What kinds of
guarantees (or at least firm intentions) do we want to give to
users with respect to lilypond 2 or 5 years from now being able to
read their current ly files?

As a first step, surely it's important to understand what are the typical sources of conversion problems, i.e. what kind of syntax changes can convert-ly not deal with?

It seems to me that \override statements and custom-written Scheme inherently come with a "may break in future" health warning (especially the latter). I don't think improvements to the language should be held back for the sake of such explicit departures from default behaviour.

Given that, LilyPond is not suitable as an archival format for

That surely depends on whether your archive can also maintain earlier versions of LilyPond to compile its older files with.

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.

How feasible is it for LilyPond to support a deprecation mechanism for syntax? E.g. so that when compiling you might get an error message,

    [such-and-such a syntax element] is deprecated syntax that will be removed
    from a future version of LilyPond.  Use [new syntax] instead.

Or alternatively, to simply maintain in LP the previous syntax as a separate option, so that for example

    lilypond                  -- uses the current standard syntax
    lilypond --deprecated     -- uses the previous syntax

... so that either way you'd always have a means of compiling a LP file from the previous syntax version, but you'd also have a clear warning of where maintenance was required.

This way you could build in a deprecation cycle for syntax changes which would minimize their impact.

This is a problem for projects such as mutopia – a large fraction of their
.ly files don’t compile with current lilypond.

If that's already the case, then it shouldn't block further syntax changes _now_ if they are useful and the syntax can be stabilized on the basis of these changes.

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.
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.

FWIW this is still a better archival status than Finale/Sibelius. In fact from what I recall, typical practice of professional engravers with these packages is to use the music software to produce a basic layout which they'd then tweak further in Adobe Illustrator. So the PDF/PostScript version would be the _only_ reliable archival copy.

My personal preference is to stabilize a subset. It won’t solve
all the user problems with manually updating ly files, but it
would be a step in the right direction. If the process goes well,
then we can have additional rounds of stabilization where we
expand the stable subset.

This seems like a good basic policy, but why not add the following caveat -- have a large test suite of different cases, including full scores provided by users (e.g. the whole Mutopia archive?), and allow syntax changes even to the subset if there is both a strong technical justification _and_ the developer can provide a convert-ly rule which demonstrably works across the whole test suite?

After all, a breaking syntax change is only bad if it _can't_ automatically be fixed.

My overall feeling on this is that while there are areas of "standard" modern musical notation [e.g. ] that aren't supported by LilyPond, it's difficult to guarantee syntax stability. So perhaps a first step is to define the subset of _musical_ notation that you want to provide stable support for.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]