Re: GOP2-3 - GLISS or not
On 10/08/12 15:06, Reinhold Kainhofer wrote:
I haven't looked at the code, but I don't see a reason why it wouldn't
be possible to extend that to non-power-of-2 denominators.
Great! :-)
What's odd is that it already works for some cases, but not others -- examples
attached to the bug report here:
https://code.google.com/p/lilypond/issues/detail?id=2713
Double fractions and real numbers in the enumerator pose more problems,
because in these cases I have no idea how to determine the beat
structure... (e.g. in #'(1 4 3 8), eights are automatically beamed as c8
c[ c c c] c[ c c]. How would you beam #'(3.2 8)? )
Well, I would not try and generalize it to arbitrary _real_ numbers, mainly
because I don't know of any application -- rational numbers should suffice.
(You might have to handle simple floating-point cases like e.g. 2.5/4, but
nothing more complex.)
In the case of rational numbers, what I would do is, in the case of e.g.
#'(4 2/3 4)
you have 4 quarter-notes (beamed as normal) followed by one (2/3)/4 which if you
calculate the fraction, works out as 1/6. So, you'd beam it as if it were,
#'((4 4) (1 6)). That latter case I think should already be handled by the
compound-meter beaming (again, see examples attached to bug report).
Basically it's equivalent to asking how you would beam the following musical
sequence:
c4 c c c \times 2/3 { c4 }
While I'm not certain, I think that approach should suffice for just about every
rational-number example, and it should suffice also for simple floating point
number cases (I can imagine people using .5 increments, I may even have seen it
somewhere, but I can't imagine anyone writing something like 2.6/4).
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On 01/08/2012 00:29, Joseph Rushton Wakeling wrote:
> You get a similar error with the following:
>
> \compoundMeter #'((4 2/3 4))
>
> c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
> c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
>
> That is,
>
> Parsing...ERROR: In procedure ly:make-moment:
> ERROR: Wrong type argument in position 1 (expecting integer): 14/3
>
> ... which can again be avoided by using the equivalent time signature
> of 7/6.
>
> This is probably actually quite easy to fix, but _as things stand_ it
> seems to me that compound time signatures probably need some careful
> consideration with respect to the styles and use-cases out there.
>
> Based on the above it's _probably_ just an internals issue and not a
> syntax problem (I can make bug reports accordingly), but it's another
> contemporary music issue to throw into the mix regarding syntax.
When I implemented \compoundMeter, I only had the classical meters in
mind (i.e. denominators are powers of 2, all enumerators are (possibly
sums of) integers, and there are no double fractions).
I haven't looked at the code, but I don't see a reason why it wouldn't
be possible to extend that to non-power-of-2 denominators.
Double fractions and real numbers in the enumerator pose more problems,
because in these cases I have no idea how to determine the beat
structure... (e.g. in #'(1 4 3 8), eights are automatically beamed as c8
c[ c c c] c[ c c]. How would you beam #'(3.2 8)? )
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On 30/07/12 17:52, Graham Percival wrote:
In general, yes. But some aspects of our syntax haven't been
around for a long time -- footnotes, woodwind fingering, compound
meters, etc. Do we have the best syntax for those? I mean,
maybe David can figure out a way to allow us to write
\compoundMeter (3+2)/8
or simply
\time (3+2)/8
instead of
\compoundMeter #(3 2 8)
That's another very good case for careful thought. Just some examples of what
you might have to handle if you want to cover the gamut of expression in 20th
century notation:
(3+2+3)/8
3/8 + 2/8 + 3/16
(3+2)/8 + 3/16
3.5/8 [or (3+1/2)/8 ...]
(2 + 1/3)/4 [Boulez in Le Marteau Sans Maitre]
4/8 + 1/10
3/8 + 4/10 + (3+2+2)/12
Note that these are all _logical_ extensions of traditional time signatures.
There's no reason in principle why they can't all be supported. But (just as an
example) if you try,
\compoundMeter #'((3 2 3 8) (1 10))
c'4. c'4 c'4. \times 4/5 { c'8 } |
c'4. c'4 c'4. \times 4/5 { c'8 } |
... with current Lilypond, you get an error:
warning: strange time signature found: 11/10
ERROR: In procedure ly:make-moment:
ERROR: Wrong type argument in position 1 (expecting integer): 15/4
... even though Lilypond supports so-called "irrational meters" like 3/10,
11/24, etc. (and if you replace the compound meter in the above example with a
straightforward 11/10 time signature, it works fine).
You get a similar error with the following:
\compoundMeter #'((4 2/3 4))
c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
That is,
Parsing...ERROR: In procedure ly:make-moment:
ERROR: Wrong type argument in position 1 (expecting integer): 14/3
... which can again be avoided by using the equivalent time signature of 7/6.
This is probably actually quite easy to fix, but _as things stand_ it seems to
me that compound time signatures probably need some careful consideration with
respect to the styles and use-cases out there.
Based on the above it's _probably_ just an internals issue and not a syntax
problem (I can make bug reports accordingly), but it's another contemporary
music issue to throw into the mix regarding syntax.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Graham Percival writes: > In general, yes. But some aspects of our syntax haven't been > around for a long time -- footnotes, woodwind fingering, compound > meters, etc. Do we have the best syntax for those? I mean, > maybe David can figure out a way to allow us to write > \compoundMeter (3+2)/8 > or simply > \time (3+2)/8 > instead of > \compoundMeter #(3 2 8) I'd have done so already, but \time takes an optional beatstructure argument that is indistinguishable from a compound meter, being a number list. > Other than indirectly possibly motivating people to work on > converters and GUIs from lilypond code, I don't see GLISS as > adding new features to lilypond at all. Rather, I'm expecting > that new development continues as before; after some syntax has > been around for long enough that we're confident that it's good, > we declare it as "stable" so that users and programmers can rely > on it. Longevity is not a measure for quality. In particular when we are talking undocumented language quirks that are not likely to have been known or exercised. Documenting is a good litmus test: if writing documentation for some peculiarity makes your stomach turn, chances are that declaring it as part of a "stable" set is not doing anybody a favor. >> * dramatically simplify our parser/lexer code in a way that brings >> future rewards. > > David is working on this. Somewhat backwards: I am trying to bring future rewards, and when our current syntax throws a spanner in my works, I try arguing for change by figuring out the sneakiest way to streamline it. > Some of his changes will break user code, and some users will be upset > by this. I'm trying to make users feel better by phrasing it as a > "give and take" situation. Yes, some things will break, but other > things will have a guarantee of stability -- and the area of stability > will increase over time. LilyPond has quite a few areas where the underlying design is of "poke-with-a-stick-until-it-does-one-job" quality, drive-by coding. There is little won to "stabilize" on random stuff that is going to make life harder afterwards and that probably nobody understands or uses extensively. >> * dramatically expand our user-base > > Syntax stability can't hurt converts and GUIs. I hope that GLISS > can indirectly increase our user-base by making it easier for > people to convert music into lilypond. And have a good subset of LilyPond they can expect to convert back. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Fri, Jul 27, 2012 at 12:56:12PM -0300, Han-Wen Nienhuys wrote: > On Tue, Jul 24, 2012 at 6:09 AM, 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? > > I think Lily is way past the point for us to decide that the language > needs to be changed in any major way: syntax is not what stops people > from using lilypond, and changing it in notable ways will only drive > people away from Lily. If we're not going to change a piece of syntax, then why not inform users of that fact so that they can rely on it being the same? At the moment we have something like a "de facto" standard -- if somebody writes a GUI which exports lilypond 2.12 code, then it will probably work in lilypond 2.16. Unless it doesn't, in which case convert-ly will fix it. Unless it doesn't, in which case the GUI fails and the user needs to manually edit the exported .ly files and/or file a bug with the GUI project. Of course, then the GUI front-end needs to either support multiple .ly backends (i.e. "output to lilypond 2.12", "output to lilypond 2.16"). Or else it could drop support for lilypond 2.12 and only output for lilypond 2.16. Regardless of GLISS, we already *are* changing the format in non-convert-ly ways. Just last week, Keith found an example from mutopia that failed to compile after a proposed patch was applied. Now, I still support making that change, but I think we should give users (and programmers of projects which convert or export to lilypond) some hope that simple music won't be changed. I'm not saying that GLISS will necessarily involve any change of notation. I think we should discuss each notation element separately, and we should certainly consider whether any disadvantages of the current notation outweigh the pain of changing. Maybe we'll decide that it's not worth making any changes at all, so GLISS really will just be "input syntax *stabilization*". > We've had this problem for many years in the 1998-2003 period, when it > was a usable but limited program, and people had to re-tweak their .ly > files every few months because we had to get out of a corner we > painted ourselves into. Right. I was good friends with the guy who tried to maintain the rosegarden lilypond export when we were doing 1.6 to 1.8. I think that was when we changed from simultaneous music being <> to <<>> ? I can't remember the specifics, but he was pretty frustrated and in the end gave up. > Rather than "defining" some stable subset (and then getting into a lot > of discussion on what that subset should look like), I think we should > just take the overall decision on intent, that is: what are we trying > to do? My suggestion is: > > * big changes: not OK I agree with this. > * small changes, especially when they clean up things (I'm thinking of > the 4. vs 4.0 change David is working on): in principle OK, but the > upgrade path should either be automatic or cause failure on > compilation. I disagree; we're not going to be perfect with any new syntax. I think it's worthwhile to introduce new syntax for a year or two, find out what works and what doesn't, and fix it if necessary. Just look at all the iterations that footnotes have gone through! > * small changes that do not fall in the latter should be done over two > stable releases. First, you make the old syntax trigger compile > failure, and only the 2nd stable release you introduce a new > interpretation. That requires a fair amount of programmer effort to add the extra error checks and remove them later. > > ** Stability or not? > > > > Stabilizing a language is a tricky process. If you do it too > > early, then you’re stuck with whatever mistakes or poor design > > decisions. > > LilyPond has been around for 15 years, and its basic syntax for 9 > years. It would be weird to suggest that we'd be stabilizing to early. In general, yes. But some aspects of our syntax haven't been around for a long time -- footnotes, woodwind fingering, compound meters, etc. Do we have the best syntax for those? I mean, maybe David can figure out a way to allow us to write \compoundMeter (3+2)/8 or simply \time (3+2)/8 instead of \compoundMeter #(3 2 8) > > and then we guarantee that this file 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. > > I think this reasoning is red herring. Arguments take as much energy > as the participants want to invest in it. If you spend too much time > on it, stop writing replies to discussions. If people declared somebody as the ultimate dictator of input syntax, the
Re: GOP2-3 - GLISS or not
Han-Wen Nienhuys writes:
> On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
> wrote:
>> This summer hasn't been going as I'd hoped -- heh, who am I
>> kidding, this whole year hasn't been going as I'd hoped. Anyway,
>> we seem to have radically different concepts of what "input
>> stabilization" might mean, or even if it's a good idea worth
>> doing.
>>
>> Hopefully we can settle those questions now.
>> http://lilypond.org/~graham/gop/gop_4.html
>>
>>
>> ** Summary
>>
>> 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?
>
>
> I think Lily is way past the point for us to decide that the language
> needs to be changed in any major way: syntax is not what stops people
> from using lilypond, and changing it in notable ways will only drive
> people away from Lily.
Yes and no.
I have just created
http://code.google.com/p/lilypond/issues/detail?id=2702>
Patch: Unify the lexer's idea of words and commands across all modes.
This a a change of LilyPond's syntax in a major way. For example, the
previously working program
{ c-flat }
now no longer works. Similarly
\paper { dim2 = 5\cm dim3 = 2\dim2 }
stops working.
Will this cause an outcry? Hardly. You'll rather get "Wait, you mean
this worked?" It is unlikely that there is a significant body of code
around that would have relied on this to work because while it "worked"
previously, it did so undocumentedly, under circumstances that are not
documented and are not even explainable in terms meaningful to a user.
This is a large and invasive syntax change, and it does not even affect
the regtests.
LilyPond has a "de facto" syntax that is more or less being used and
documented. We won't be tying it down anytime soon. But it is also
clear that some changes are an improvement. With the above change in
place, I can write
\paper { paper-width = #(+ #{ 3\cm #} #{ \paper-width #} )}
and it works. Even though #{...#} sets up \notemode nominally.
There is good reason to make such a change. But of course there is also
"old code might have relied on this behavior".
And I agree with Graham that at some point of time we _should_ try to
settle just _what_ behavior people may rely on safely.
> As a corollorary, it is OK for a syntax change to invalidate previous
> .ly files, if it generates a warning at the problematic location.
You _can't_ reliably generate a warning for every undocumented detail
that may change its interpretation in future.
How would you even _start_ generating warning for a lexer change like
the one I pointed out?
Lexer changes are almost impossible to do with a proper deprecation
phase. Parser changes are hard, but sometimes possible. Music function
changes are often feasible.
The deeper the change is, the harder it is to do a deprecation phase
because in a deprecation phase, something needs to be interpreted in two
manners, and the whole point of the phase is presumably to arrive at a
completely different interpretation.
> Rather than "defining" some stable subset (and then getting into a lot
> of discussion on what that subset should look like), I think we should
> just take the overall decision on intent, that is: what are we trying
> to do? My suggestion is:
>
> * big changes: not OK
> * small changes, especially when they clean up things (I'm thinking of
> the 4. vs 4.0 change David is working on): in principle OK, but the
> upgrade path should either be automatic or cause failure on
> compilation.
Well, take the above lexer change. It is a big change, but it is
unlikely many people will encounter its effects because they likely have
shied away from completely undocumented behavior only working in corner
cases.
I want fewer corner cases, and more documented behavior. Fewer corner
cases means incompatibilities, but how many people actually have been
sitting in the unlighted corners anyway?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
>> Yes: cis, ces, fisis, feses, etc. > > And asas. Yes, I think so. > Or aeses? Or was that ases? Never heard. > bes or heses? Rather the latter. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Werner LEMBERG writes: >>> At least for German, the current syntax is the only good one IMHO, >>> both for accidentals (for the twelve tones of an octave >> >> You mean the 35 tones. After all, we are talking printed output and >> not Midi. > > Yes: cis, ces, fisis, feses, etc. And asas. Or aeses? Or was that ases? bes or heses? I am not actually convinced that f♯ and e♭ would not also be reasonably nice alternatives... But then I am used to writing German texts with an American keyboard layout and to using the compose key. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
>> At least for German, the current syntax is the only good one IMHO, >> both for accidentals (for the twelve tones of an octave > > You mean the 35 tones. After all, we are talking printed output and > not Midi. Yes: cis, ces, fisis, feses, etc. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Werner LEMBERG writes: >> This is kind of the nub of the issue. I agree that the notation for >> staff pitches (and octaves) is going to remain stable -- but I'm >> _not_ convinced that you can guarantee stability for accidentals or >> durations. > > At least for German, the current syntax is the only good one IMHO, > both for accidentals (for the twelve tones of an octave You mean the 35 tones. After all, we are talking printed output and not Midi. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
> This is kind of the nub of the issue. I agree that the notation for > staff pitches (and octaves) is going to remain stable -- but I'm > _not_ convinced that you can guarantee stability for accidentals or > durations. At least for German, the current syntax is the only good one IMHO, both for accidentals (for the twelve tones of an octave) and rhythm. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
wrote:
> This summer hasn't been going as I'd hoped -- heh, who am I
> kidding, this whole year hasn't been going as I'd hoped. Anyway,
> we seem to have radically different concepts of what "input
> stabilization" might mean, or even if it's a good idea worth
> doing.
>
> Hopefully we can settle those questions now.
> http://lilypond.org/~graham/gop/gop_4.html
>
>
> ** Summary
>
> 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?
I think Lily is way past the point for us to decide that the language
needs to be changed in any major way: syntax is not what stops people
from using lilypond, and changing it in notable ways will only drive
people away from Lily.
We've had this problem for many years in the 1998-2003 period, when it
was a usable but limited program, and people had to re-tweak their .ly
files every few months because we had to get out of a corner we
painted ourselves into. There are probably lots of other syntax
details that we adopted for them to be better-looking (eg. "\tempo
4.") that are making our lives difficult now.
I think the real problem with syntax changes is that users cannot be sure that
old syntax can be reinterpreted under new syntax rules to be something
else. That means that you have to check the output of the new file
note by note, and most users just don't have the time for that.
As a corollorary, it is OK for a syntax change to invalidate previous
.ly files, if it generates a warning at the problematic location.
Rather than "defining" some stable subset (and then getting into a lot
of discussion on what that subset should look like), I think we should
just take the overall decision on intent, that is: what are we trying
to do? My suggestion is:
* big changes: not OK
* small changes, especially when they clean up things (I'm thinking of
the 4. vs 4.0 change David is working on): in principle OK, but the
upgrade path should either be automatic or cause failure on
compilation.
* small changes that do not fall in the latter should be done over two
stable releases. First, you make the old syntax trigger compile
failure, and only the 2nd stable release you introduce a new
interpretation.
> ** Stability or not?
>
> Stabilizing a language is a tricky process. If you do it too
> early, then you’re stuck with whatever mistakes or poor design
> decisions.
LilyPond has been around for 15 years, and its basic syntax for 9
years. It would be weird to suggest that we'd be stabilizing to early.
> In greater detail: I’m suggesting that we have a round of syntax
> stabilization (GLISS). At the end of it (3 months? 6 months?), we
> add a few regression tests that might look something like this:
>
>
> \version "2.16.0"
> \score {
> \music {
> \staff {
> \voice {
> a4 b c4. d8 |
> \tuplet 2/3 { fis4 a bes } r2 |
> }
> }
> }
> }
>
> and then we guarantee that this file 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.
I think this reasoning is red herring. Arguments take as much energy
as the participants want to invest in it. If you spend too much time
on it, stop writing replies to discussions.
> ** 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.
I understand the desire of each of these changes, but I don't see any
of them either:
* expand on what people can do with LilyPond
* dramatically simplify our parser/lexer code in a way that brings
future rewards.
* dramatically expand our user-base
I think these should be the guiding principles for any kind of change
we contemplate.
I also think that there are very few changes that could meet these
standard because:
* what people can do is very often limited by the typesetting
infratstructure rather than syntax
* the lexer/parser is complex, but it is sunk cost. Cleaning it up is
only worthwhile if you intend to do further work (ie. more syntax
changes) on it.
* people that don't use Lily now probably do for lack of a graphical interface.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On 27/07/12 11:11, Graham Percival wrote: Think of the stable notation as a subset, not the complete set. Yes, fair enough -- it's very likely changes can be done additively and if not for the traditional syntax to be maintained as syntactic sugar. Hmm. I'll have to think about this more. My first thought is that sources of syntax problems is changing the syntax -- but rather being a "duh" moment, my point is that we've never changed the note-names and basic rhythms, so there's no data about how hard that would be. Users would need to memorize a new set of note-namess (not hard, but annoying), programs which export lilypond would need to be updated, etc. Well, since the question of the default note-name language was raised, that seems like a good basic way to test the difficulty of rewriting core syntax -- how difficult is it in practice to convert automatically from Dutch to English? To me the users' need is the single most important reason to stabilize, together with 3rd-party tools that _read_ Lilypond -- for archival purposes, or 3rd-party tools that write to LP, the only thing that matters is that there is a reliable converter. That's why I'd stress getting good data on what syntax changes cause convert-ly failures. I'll wrap your concern into the next version of this proposal and send it out later today or tomorrow. That should give it extra visibility and somebody may have a good suggestion about it. Cool! Will look forward to it. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Fri, Jul 27, 2012 at 08:54:47AM +0100, Joseph Rushton Wakeling wrote: > On 26/07/12 19:19, Graham Percival wrote: > >I should add some more context. I've just remembered that we have > >a tutorial (don't ask me how I forgot), and that covers pretty > >much what I was thinking about "really simple music". > > Thanks for that clarification -- it's actually a narrower subset > than I thought you might be considering. I do think it's very wise > to exclude beaming, articulation and slurs/ties/phrase marks -- > there are a number of potential syntax changes I can think of that > might be useful here. Yes, both in terms of user input and simplifying the parser. I'm not saying that we'll never stabilize those; just that I think they're too complicated for the first round. > >I think we're talking about different things. Let's put it this > >way: do you think that we'll ever move away from > > c'4 > >being a quarter note for middle C ? That's the basic question > >here. It doesn't matter how lilypond represents c'4 internally > >(whether it uses grobs or contexts or lilypond rationals or scheme > >rationals or bits or trits or qubits). > > This is kind of the nub of the issue. I agree that the notation for > staff pitches (and octaves) is going to remain stable -- but I'm > _not_ convinced that you can guarantee stability for accidentals or > durations. Think of the stable notation as a subset, not the complete set. > c + 1/2 - 1/4 + 1/8 + 1/16 [NOT a suggested notation!!] Suppose we adopt this notation in the future. We can still let users write cis c+1/2 ces c-1/4-1/4 and produce c sharp c sharp c flat c flat. Interally, the "stable" cis would be "translated" into c+1/2. Granted it would be somewhat annoying to maintain that kind of "pre-translation", so I don't want to open the floodgates and blithly assume that we can do that for everything. But in the case of note pitches, I think it's simple enough that we can handle this. Ditto for durations -- even if it's desirable to specify note lengths in a more advanced fashion, I think that the basic "1 2 4 8 16" could be "pre-translated" to that advanced fashion if necessary. > So in a way, this may be the > part of Lilypond that it's least urgent to commit to stabilizing > (which doesn't mean that it won't turn out to be stable in > practice). That's why I suggested doing a careful empirical study > of the principal sources of syntax problems when trying to convert > from one Lilypond version to another. Hmm. I'll have to think about this more. My first thought is that sources of syntax problems is changing the syntax -- but rather being a "duh" moment, my point is that we've never changed the note-names and basic rhythms, so there's no data about how hard that would be. Users would need to memorize a new set of note-namess (not hard, but annoying), programs which export lilypond would need to be updated, etc. I'll wrap your concern into the next version of this proposal and send it out later today or tomorrow. That should give it extra visibility and somebody may have a good suggestion about it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Just realized I sent my original reply straight to Graham and not to the list -- sorry for the double email :-( On 26/07/12 19:19, Graham Percival wrote: I should add some more context. I've just remembered that we have a tutorial (don't ask me how I forgot), and that covers pretty much what I was thinking about "really simple music". Thanks for that clarification -- it's actually a narrower subset than I thought you might be considering. I do think it's very wise to exclude beaming, articulation and slurs/ties/phrase marks -- there are a number of potential syntax changes I can think of that might be useful here. I think we're talking about different things. Let's put it this way: do you think that we'll ever move away from c'4 being a quarter note for middle C ? That's the basic question here. It doesn't matter how lilypond represents c'4 internally (whether it uses grobs or contexts or lilypond rationals or scheme rationals or bits or trits or qubits). This is kind of the nub of the issue. I agree that the notation for staff pitches (and octaves) is going to remain stable -- but I'm _not_ convinced that you can guarantee stability for accidentals or durations. Briefly, Lilypond's pitch notation consists of a unique identifying string per pitch that mashes together staff pitch (c, d, e, f, g, a, b) with accidentals (s, f, qs, qf, tqs, tqf, ...), which is fine when you've got the limited pitch palette of semitones and quarter-tones, but starts getting out of control when you have more fine-grained pitch divisions, perhaps having to deal with pitch alterations that look something like this: c + 1/2 - 1/4 + 1/8 + 1/16 [NOT a suggested notation!!] ... and you maybe want to put them together in fairly arbitrary combinations. It _might_ be possible to implement this as an additive change to the core syntax, but I'm not certain. For duration, what about the proportional case, where e.g. you might want to specify note lengths in very arbitrary units of actual time (0.5s, 0.1s, 0.333s, ...)? I suspect that'd be an additive change rather than a breaking one, but again, I'm not sure. Don't get me wrong, I think it's excellent to consider future possibilities such as microtonal notation. That's one of the reasons I think we should spend months and months discussing this, as well as having a huge "waiting period" before absolutely committing to even the most basic input. But whatever happens with contemporary notation, or gregorian chants, or what have you, I think that lilypond will always support basic classical and Romantic music, and I think that we can safely say "we will always support c'4 ". Don't get me wrong either, I'm broadly confident that the core syntax you've identified can probably be stabilized as-is. It's just that if you take, say, the collective body of music that is Gregorian, Baroque, Classical, Romantic and contemporary and say, "We'd like to support all the standard pitch notations from this literature and preferably to do it using a common style of syntax", I'm not 100% certain that the optimal syntax choice would be the one currently used by Lilypond. Likewise for duration. As you suggest, I think it's necessary and interesting to have that discussion. The other thing I'd note is that syntax changes to this core notation are possibly the _easiest_ syntax changes to make, because they're almost certainly the easiest changes to address automatically (to change e.g. Dutch note names to English is a straightforward search and replace). So in a way, this may be the part of Lilypond that it's least urgent to commit to stabilizing (which doesn't mean that it won't turn out to be stable in practice). That's why I suggested doing a careful empirical study of the principal sources of syntax problems when trying to convert from one Lilypond version to another. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Thu, Jul 26, 2012 at 06:31:50PM +0100, Joseph Rushton Wakeling wrote: > >Sounds to me like that was what Graham proposed in the first place. > > No, Graham proposed freezing a subset of _Lilypond syntax_. I'm > proposing that before doing any such thing it's important to look at > Lilypond's musical coverage and ask if it is adequate enough to > guarantee that the syntax can be stabilized. I should add some more context. I've just remembered that we have a tutorial (don't ask me how I forgot), and that covers pretty much what I was thinking about "really simple music". This isn't a formal proposal yet, but tomorrow or the day after I'll officially suggest something like: * stabilize an input syntax (not _necessarily_ the input syntax on these pages) for: http://lilypond.org/doc/v2.14/Documentation/learning/simple-notation http://lilypond.org/doc/v2.14/Documentation/learning/single-staff-notation with the following exceptions: - no beaming - no formatting of text - no articulations or fingerings - no ties or slurs plus a few additions: - setting a title and composer (but nothing else) - (implied) the general format of input files - create output in pdf and midi * schedule 4-6 months for discussion plus infrastructure work * after the discussion has ended, there will be a 6-month and/or 1-stable-release-cycle waiting period before absolutely finalizing that syntax. > The microtonal notation issue I highlighted is relevant in this > respect because it's almost guaranteed to involve a rewrite of how > LP considers pitches and pitch alterations internally. In turn, > that might impact all the way back up to a rewrite of LP syntax for > those things. And it's a completely standard part of modern musical > notation that is currently unsupported by Lilypond. I think we're talking about different things. Let's put it this way: do you think that we'll ever move away from c'4 being a quarter note for middle C ? That's the basic question here. It doesn't matter how lilypond represents c'4 internally (whether it uses grobs or contexts or lilypond rationals or scheme rationals or bits or trits or qubits). All we would be committing is that if the user enters c'4 it would produce a middle C (notwithstanding \relative mode). We could still have other methods of entering pitches (such as the current language method, or scheme methods, or chord-based stuff, etc); all we guarantee is that this one method will work in the future. Don't get me wrong, I think it's excellent to consider future possibilities such as microtonal notation. That's one of the reasons I think we should spend months and months discussing this, as well as having a huge "waiting period" before absolutely committing to even the most basic input. But whatever happens with contemporary notation, or gregorian chants, or what have you, I think that lilypond will always support basic classical and Romantic music, and I think that we can safely say "we will always support c'4 ". - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On 26/07/12 16:50, David Kastrup wrote: Joseph Rushton Wakeling writes: How feasible is it for LilyPond to support a deprecation mechanism for syntax? At some time, it will be removed or the warning is pointless. So this will not address the topic of bitrot for large mostly dormant bodies of music like Mutopia satisfactorily. Indeed. But a well-defined deprecation cycle which gives an organization like Mutopia time to update its contents may be preferable to freezing LP syntax. After all, there's value in the contents of an archive like Mutopia being maintained over time. Engraved music needs fixing for many reasons -- errors, previously-unidentified performance issues, responses to new scholarship -- you don't want them to be just dumped there and left untouched. The PDFs are still there for the truly unmaintained documents, so it's not like you're fundamentally losing the archived music. My overall feeling on this is that while there are areas of "standard" modern musical notation [e.g. https://code.google.com/p/lilypond/issues/detail?id=1278 ] 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. Sounds to me like that was what Graham proposed in the first place. No, Graham proposed freezing a subset of _Lilypond syntax_. I'm proposing that before doing any such thing it's important to look at Lilypond's musical coverage and ask if it is adequate enough to guarantee that the syntax can be stabilized. The microtonal notation issue I highlighted is relevant in this respect because it's almost guaranteed to involve a rewrite of how LP considers pitches and pitch alterations internally. In turn, that might impact all the way back up to a rewrite of LP syntax for those things. And it's a completely standard part of modern musical notation that is currently unsupported by Lilypond. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Joseph Rushton Wakeling writes: > 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 >> music. > > That surely depends on whether your archive can also maintain earlier > versions of LilyPond to compile its older files with. And earlier versions of GCC to compile its older LilyPond versions with. > 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. At some time, it will be removed or the warning is pointless. So this will not address the topic of bitrot for large mostly dormant bodies of music like Mutopia satisfactorily. > Or alternatively, to simply maintain in LP the previous syntax as a > separate option, so that for example > > lilypond file.ly -- uses the current standard syntax > lilypond --deprecated file.ly -- uses the previous syntax If it was simply... > My overall feeling on this is that while there are areas of "standard" > modern musical notation > [e.g. https://code.google.com/p/lilypond/issues/detail?id=1278 ] 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. Sounds to me like that was what Graham proposed in the first place. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
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 music. 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 file.ly -- uses the current standard syntax lilypond --deprecated file.ly -- 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. https://code.google.com/p/lilypond/issues/detail?id=1278 ] 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. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
"Trevor Daniels" writes: > Graham Percival wrote Tuesday, July 24, 2012 10:09 AM > >> ** Summary >> >> Let’s decide whether to try to stabilize the syntax or not. > > We /should/ try to stabilize the syntax, but trying to do this > at exactly the time when David is straightening out the > parser seems a bad idea. To be fair, it is not likely that David will stop "straightening out the parser" anytime soon. One problem with "straightening out" the parser, however, is that it is very much guided by remaining upwards compatible, and that individual changes breaking upward compatibility are hard to argue on their own merits. So the trend is to resolve ambiguities by adding complexity. That avoids compatibility issues for the time being. However, it means that the same amount of complexity for resolving ambiguities would need to get applied by convert-ly, text editors with syntax support for LilyPond, and tools importing LilyPond, all of which is not realistic. So the price of LilyPond retaining the ability to process almost anything it was able to process before and calling that the de facto standard is that everybody else gives up on LilyPond as a music description language. It also means that the moving target for full anecdotal backward compatibility (try supporting anything that may have worked at some point of time) gets more horrific the longer this goes on. > As yet we do not know where the parser changes may lead eventually. Well, the expectation in the medium range is to solidify on music functions, and have a mechanism where there is just one kind of them, and just one kind of argument parsing. >> ** Stability or not? >> >> Stabilizing a language is a tricky process. If you do it too >> early, then you’re stuck with whatever mistakes or poor design >> decisions. > > Exactly. We should wait until David's parser changes settle out. Again: this is not going to happen anytime soon, and even if we are postulating that I am the only one working on the changes, they need to fit with some direction. At the current point of time, I am more or less factually dictator of the lexer/parser since a statement "this is not doable" from me will go uncontested. But the path of least resistance is a path where lots of mostly historical ambiguities, partly due to arbitrary design choices, get resolved with a considerable involvement of complexity. And defining the whole of what will compile at a current point of time as an archive language does not really work. >> 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. 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. > > I'd be happy to see a start being made on this now, in spite of my > comments above, but we must delay the actual release of the definitive > syntax-stable version until we have confidence the parser changes have > stabilized. The task David has set himself is difficult enough > without his being hamstrung by a premature release imposing further > constraints on the parser. Predicting the effect those constraints > might have on the parser is pretty well impossible. It has to be said that at the current point of time the main challenge in lexer/parser work is in the _lack_ of constraints. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Thu, Jul 26, 2012 at 09:02:38AM +0100, Trevor Daniels wrote: > Graham Percival wrote Tuesday, July 24, 2012 10:09 AM > > > Let’s decide whether to try to stabilize the syntax or not. > > We /should/ try to stabilize the syntax, but trying to do this > at exactly the time when David is straightening out the > parser seems a bad idea. As yet we do not know where > the parser changes may lead eventually. tl;dr: we agree on the actual "what we will do", but disagree on the reasons behind it. :) I actually think that David's work on the parser makes this is the perfect time to do GLISS. - the code should match our desired language specification, not the other way around. Do we want to allow numbers like 0.37 which do not begin with a leading 0? that's not a code question, that's a language question. Of course the language design should be heavily influenced by the implications for the computer implementation (i.e. parser and lexer), so I don't think we would be able to have this discussion without David's expertise on the matter. - 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. > I'd be happy to see a start being made on this now, in spite > of my comments above, but we must delay the actual > release of the definitive syntax-stable version until we have > confidence the parser changes have stabilized. The task David > has set himself is difficult enough without his being hamstrung > by a premature release imposing further constraints on the > parser. Predicting the effect those constraints might have > on the parser is pretty well impossible. I agree with delaying the definitive syntax-stable versions; I'm imagining something like a "proposed stable" syntax that must exist for 6 or 12 months without any change or quibbles before it's accepted as "actually stable". - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Graham Percival wrote Tuesday, July 24, 2012 10:09 AM > ** Summary > > Let’s decide whether to try to stabilize the syntax or not. We /should/ try to stabilize the syntax, but trying to do this at exactly the time when David is straightening out the parser seems a bad idea. As yet we do not know where the parser changes may lead eventually. > ** Stability or not? > > Stabilizing a language is a tricky process. If you do it too > early, then you’re stuck with whatever mistakes or poor design > decisions. Exactly. We should wait until David's parser changes settle out. > 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. 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. I'd be happy to see a start being made on this now, in spite of my comments above, but we must delay the actual release of the definitive syntax-stable version until we have confidence the parser changes have stabilized. The task David has set himself is difficult enough without his being hamstrung by a premature release imposing further constraints on the parser. Predicting the effect those constraints might have on the parser is pretty well impossible. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Wed, Jul 25, 2012 at 04:58:57AM +, Keith OHara wrote:
> Graham Percival 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,
t
Re: GOP2-3 - GLISS or not
Francisco Vila writes: > 2012/7/24 David Kastrup : >> convert-ly can't work reliably since it does not understand the >> structure of LilyPond files. > (...) >> Reliable conversions need to understand structure. You can do them on >> XML. LilyPond is too complex. > (...) > > Right, so a "perfect" convert-ly would solve all problems but this is > impossible. Then, it is now clear to me that a syntax stability for a > long period of time is very desirable. > > Besides, I have weighted more than once the possibility of updating > all Mutopia music. That would improve its value (and the opposite, > i.e. doing nothing is effectively making it to lose its value more and > more). That sounds like a good user community project. It is very important for that sort of thing to have timely response to user contributions. I believe that the current Mutopia project may be a bit problematic in that department. Some automated and semi-automated procedures (proof-reading interfaces?) might help with that. > Just thinking aloud, sorry. I don't want to waste your time. I realize > this is fairly naïve. When "naïve" serves the majority of a large user community... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Wed, Jul 25, 2012 at 12:33:30PM +0200, Francisco Vila wrote: > Speaking of, another stupid idea I once had, was to establish big > "ranges of music Lily can do", for example "All J.S.Bach" and try to > find counter-examples that break this set. If we find them, _that_ > would be a good source of ideas for improving LilyPond. If we don't > find any, we go for the next level, say "All Bach' sons" or "All > Salieri" and so on. Of course we could (should) go backwards as well, > e.g. "All Lully". Eventually we'll reach a certificate or seal of > compatibility for a range of composers. I agree, that would be awesome. Although a slightly more plausible thing would be to isolate specific works. For example, 1. Bach cello unaccompanied suite no. 1. (single staff, a bit of polyphony but not much, etc) 2. (all?) Bach chorales. (multiple staves, lyrics) 3. Mozart symphony 40. (many instruments, but relatively easy notes/harmonies/notation) 4. Beethoven piano concerto no. X. (many instruments, more challenging notation) ... x. Tchaik. violin concert (already in mutopia, but would require updating and of course bug-fixing in lilypond to produce great output with no tweaks) However, that would be a huge understaking, and I don't think we have enough programmer interest or funds. (we could probably organize a user effort to write the .ly files, though) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
2012/7/24 David Kastrup : > convert-ly can't work reliably since it does not understand the > structure of LilyPond files. (...) > Reliable conversions need to understand structure. You can do them on > XML. LilyPond is too complex. (...) Right, so a "perfect" convert-ly would solve all problems but this is impossible. Then, it is now clear to me that a syntax stability for a long period of time is very desirable. Besides, I have weighted more than once the possibility of updating all Mutopia music. That would improve its value (and the opposite, i.e. doing nothing is effectively making it to lose its value more and more). Speaking of, another stupid idea I once had, was to establish big "ranges of music Lily can do", for example "All J.S.Bach" and try to find counter-examples that break this set. If we find them, _that_ would be a good source of ideas for improving LilyPond. If we don't find any, we go for the next level, say "All Bach' sons" or "All Salieri" and so on. Of course we could (should) go backwards as well, e.g. "All Lully". Eventually we'll reach a certificate or seal of compatibility for a range of composers. Just thinking aloud, sorry. I don't want to waste your time. I realize this is failrly naïve. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Graham Percival percival-music.ca> writes:
> 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.
>
I recently updated a fairly complex piece from 2004 on mutopiaproject.
Convert-ly turned it into valid input for current LilyPond, but none
of the \overrides did what was intended. Nearly all of them were no
longer necessary due to bug-fixes in the past six years.
> 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 ?
> 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.
>
If you mean the portions of these sections that users have likely
committed to memory, that should work.
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.
> In greater detail: I’m suggesting that we have a round of syntax
> stabilization (GLISS). At the end of it (3 months? 6 months?), we
> add a few regression tests that might look something like this:
Having the currently-frozen syntax be un-frozen and then re-frozen
six months later might lead to changes that we regret. But if it is
the core notation in a set of regression tests that is to be frozen,
that should work.
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.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Tue, Jul 24, 2012 at 3:09 AM, Graham Percival wrote: > 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. > As another example, I regularly use scientific Fortran codes that are 30 or 40 years old and have been made available as Python modules. Stability is certainly a good thing so long as it doesn't prevent genuine improvements in LilyPond. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Nicolas Sceaux writes: > As a maintainer of 100+ Mbytes of LilyPond files, I'm very interested > in this topic. > > IMHO, we should aim at stabilizing what is currently hardcoded in the > lexer and parser (notes, file structure...). Nowadays, only David > works in this area, he has the best expertise on the subject, and he > probably knows what best should be done. I am mostly working on extending the range of things that "just work". The main thrust is to stay upwards compatible. There are cases like footnote syntax where the "most natural" argument order now is not available due to technical reasons. In a similar vein, some of David Nalesnik's (and Harm's) functions require things like quotes around "Staff.NoteHead", something that should at one point of time become unnecessary. Moving that sort of complexity into the parsing possibilities of music functions means that the language is more or less open-ended. At the current point of time, there are a number of arbitrary-seeming restrictions when parsing. I am working on lifting them. So basically I am working on getting a framework where a lot can be done at runtime. Of course, it would be nice if one could at one point of time process the syntax of different versions just by plugging in different Scheme and LilyPond startup files. > I don't see how LilyPond files could be converted automatically, without > loss or deterioration, because of their complexity as soon as scheme > extensions are involved. However, if we have a toolkit which allows: > ly-file 'A.ly' -> PDF file 'A.pdf' > ly-file 'A.ly' -> MusicXML-file -> ly-file 'B.ly' -> PDF file 'B.pdf' > where A.pdf and B.pdf are identical, (even though A.ly and B.ly are not) > then a part of the problem is solved. > (I have no clue if this is possible). Not practically, I guess. Reasonably useful two-way XML conversions would be somewhat helpful, but of course that's not a conversion retaining the expressivity of LilyPond as a source file format: for example, most music functions would likely just end up expanded which rarely makes for a well-readable source. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Le 24 juil. 2012 à 11:09, Graham Percival a écrit : > ** Stability or not? > > Stabilizing a language is a tricky process. If you do it too > early, then you’re stuck with whatever mistakes or poor design > decisions. If you do it too late, then there’s a large body of > documents in the pre-stabilized version which will require > updating before they run in the stabilized version. > > I see two options: > > 1. No stability: we go back to the way things worked a few > years ago. When a programmer wants to change something, he > changes the code and maybe adds a convert-ly rule if it’s > convenient to do so, otherwise just adds a warning to the > NEWS. I stop telling people “no, don’t change the syntax, > and don’t even talk about changing the syntax”. > > 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. 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. Hi, As a maintainer of 100+ Mbytes of LilyPond files, I'm very interested in this topic. IMHO, we should aim at stabilizing what is currently hardcoded in the lexer and parser (notes, file structure...). Nowadays, only David works in this area, he has the best expertise on the subject, and he probably knows what best should be done. As for the name and semantics of builtin shortcuts, music functions, markup commands, they'd also be best stabilized in name, signature and semantics, across stable releases. The long discussed subjects, like tuplets (which should cause no problem for convert-ly), should be sorted out, as you suggest. But the name and semantics of grob or context properties and the like shall not be frozen, even though writing convert-ly rules for them is often problematic. This is the area where there are the more changes, and for a reason: this is where you can reach and change typesetting functionalities. [A good LilyPond writing rule is to avoid using \override:s everywhere in ly files, but to define a music function which in turn calls the override, to ease conversion.] I don't see how LilyPond files could be converted automatically, without loss or deterioration, because of their complexity as soon as scheme extensions are involved. However, if we have a toolkit which allows: ly-file 'A.ly' -> PDF file 'A.pdf' ly-file 'A.ly' -> MusicXML-file -> ly-file 'B.ly' -> PDF file 'B.pdf' where A.pdf and B.pdf are identical, (even though A.ly and B.ly are not) then a part of the problem is solved. (I have no clue if this is possible). Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Francisco Vila writes: > Take this as the result of a quick reading of the summary. My comment > as a non-expert is that probably a good, reliably working convert-ly > is a substitute for syntax stability, because it is precisely what > will make your documents compile on the long term. convert-ly can't work reliably since it does not understand the structure of LilyPond files. The kind of conversion rules I implemented for some things (like converting expressions involving ly:export into expressions using $) are several levels of complexity above the average convert-ly rules. You can't expect people to write rules like that, and they still don't do the trick. Reliable conversions need to understand structure. You can do them on XML. LilyPond is too complex. > So in any case I don't think we should get obsessed with syntax > stability if we can make convert-ly rules work better. One can polish around, but that yields marginal improvements. > Or if lilypond were able to read old files and convert-ly them on the > fly, issuing a warning and suggesting the user to make changes > permanent. > > I'd like to ellaborate a bit more, later. Basically it would mean that you'd need one versioned copy of LilyPond (and/or its parser) for every conversion that convert-ly does. That's not feasible for a local installation. It might be feasible for a web service. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Hi Graham, On 24/07/12 10:09, Graham Percival wrote: > > Hopefully we can settle those questions now. > http://lilypond.org/~graham/gop/gop_4.html > > > ** Summary > > 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? > > > ** 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. > > 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. > > > ** Stability or not? > > Stabilizing a language is a tricky process. If you do it too early, > then you’re stuck with whatever mistakes or poor design decisions. > If you do it too late, then there’s a large body of documents in > the pre-stabilized version which will require updating before they > run in the stabilized version. > > I see two options: > > 1. No stability: we go back to the way things worked a few years > ago. When a programmer wants to change something, he changes the > code and maybe adds a convert-ly rule if it’s convenient to do so, > otherwise just adds a warning to the NEWS. I stop telling people > “no, don’t change the syntax, and don’t even talk about changing > the syntax”. > > 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. 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. > > 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. > Definitely, definitely option 2. O.K. it'll be a PITA getting from here to there, but one of the big wins LilyPond has it that the files generating the music are not locked in to a proprietary format, and are text files. If we go back to a free-for-all, it-seemed-a-cool-idea-at-the-time idea for the language this baby will certainly get thrown out with some future bathwater. If we have a stable language core, then we could, if someone does have a wild, hairy-arsed idea, catch it at proposal/review time and have consider a solution that does fit into the spirit of our core syntax. On the projects I worked on back in the day, we produced a software product, which was, like LilyPond, translated into lots of languages (I18N), and could be customized by customer sites or re-sellers. This caused some issues when supporting and developing the product. One of the things we had to be crystal-clear about was the dividing-line between the base control language and customizations. LilyPond needs to draw this dividing-line now, but be prepared to support users like Mutopia with getting from supported by 2.16 and therefore supportable for the future. Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Tue, Jul 24, 2012 at 11:00:30AM +0100, Phil Holmes wrote: > Surely an alternative is to have an archive of stable version > installations? We have that already: http://lilypond.org/old-downloads.html > We could advise users who require that their work > will compile into the future to ensure it will compile on current > stable. Then, if they need to recreate it, the just download that > version. This is definitely a possibility. Although if that's how we want the LilyPond project to function, then I think this should be stated explicitly on the website in a manner similar to http://lilypond.org/easier-editing.html I believe in giving people enough information to make an informed choice. Text input is one "element" (some people would say "disadvantage") that I made sure that we inform users about before they download lilypond; an explicit lack of forward compatibility is another "element" that we should be up-front about, if that's what we decide. > @GP - I know this isn't what the question is about, but is there no > way of rolling back to a version of Lily which will compile your > files? Oh, of course I could compile an old version (or just use the GUB binaries above). There may be some library problems, but in a pinch I could grab a debian iso from 5 years ago, slap that into virtualbox, and run with it. A better solution would be to treat "updating old lilypond scores" as a hobby -- schedule 1 hour a day, spend one month, and I'd probably be done. Or at least, it would be updated to 2.14. Hopefully future updates wouldn't take as long; say, something like 5 hours a year keeping my scores up-to-date? However, that thought doesn't fill me with joy and motivation to use lilypond. I hate doing regular maintenance. I'd rather spend 100 hours up-front instead of spending 1 hour a year for the rest of my life (and no, I don't expect to live for another 100 years; I acknowledge that this is not a rational choice). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Tue, Jul 24, 2012 at 11:48:13AM +0200, Francisco Vila wrote: > Take this as the result of a quick reading of the summary. My comment > as a non-expert is that probably a good, reliably working convert-ly > is a substitute for syntax stability, I disagree. For one thing it is often very difficult to map new syntax precisely onto an old. There are bound to be people who use lily in a way that the designer of a syntactic construction did not expect because they find it "works for them." So even if all the expected uses convert properly that is no guarantee that convert-ly will work from the users point of view. Many people are put off using a program by even one perceived hassle. I have a lot of ancient lily files that contain things like bits of scheme I wrote just to get a particular effect in a particular instance. I ended up recoding some of them from scratch because it would have taken too much time doing anything else. Languages that have a stable core tend to last a long time. It is still possible to compile and run the vast majority of COBOL programs that were written in the 60's. Most of the problems that do occur are down to the i/o of modern computers being different. But this is the sort of problem a user would expect. It is unexpected problems that appear to happen for no apparent reason the annoy users. The idea of a stable core that is never changed, except for very very good reasons is excellent. It could be added to as various other parts of the program developped. If the core were large enough for 'good enough' scores to be written for most of the repertoire, but forgetting about arcane ancient or contemporay notations, then a site like Mutopia could merely require that this subset of the language be used. Users who want scores of reasonable quality that they want to be able to re-use in the long term could use the stable core, whereas users who want to use all the latest bells and whistles would be able to use the unstable parts of the program in full knowledge that this could lead to problems later. Bernard ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
- Original Message - From: "Francisco Vila" To: "Graham Percival" Cc: Sent: Tuesday, July 24, 2012 10:48 AM Subject: Re: GOP2-3 - GLISS or not Take this as the result of a quick reading of the summary. My comment as a non-expert is that probably a good, reliably working convert-ly is a substitute for syntax stability, because it is precisely what will make your documents compile on the long term. Your personal, misfortunate case would not have taken place. And Mutopia would compile in a higher percentage. I don't know if this is technically doable or how many hours/man would it take. So in any case I don't think we should get obsessed with syntax stability if we can make convert-ly rules work better. Or if lilypond were able to read old files and convert-ly them on the fly, issuing a warning and suggesting the user to make changes permanent. I'd like to ellaborate a bit more, later. -- Francisco Vila. Badajoz (Spain) Surely an alternative is to have an archive of stable version installations? We could advise users who require that their work will compile into the future to ensure it will compile on current stable. Then, if they need to recreate it, the just download that version. @GP - I know this isn't what the question is about, but is there no way of rolling back to a version of Lily which will compile your files? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Take this as the result of a quick reading of the summary. My comment as a non-expert is that probably a good, reliably working convert-ly is a substitute for syntax stability, because it is precisely what will make your documents compile on the long term. Your personal, misfortunate case would not have taken place. And Mutopia would compile in a higher percentage. I don't know if this is technically doable or how many hours/man would it take. So in any case I don't think we should get obsessed with syntax stability if we can make convert-ly rules work better. Or if lilypond were able to read old files and convert-ly them on the fly, issuing a warning and suggesting the user to make changes permanent. I'd like to ellaborate a bit more, later. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP2-3 - GLISS or not
This summer hasn't been going as I'd hoped -- heh, who am I
kidding, this whole year hasn't been going as I'd hoped. Anyway,
we seem to have radically different concepts of what "input
stabilization" might mean, or even if it's a good idea worth
doing.
Hopefully we can settle those questions now.
http://lilypond.org/~graham/gop/gop_4.html
** Summary
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?
** 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.
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.
** Stability or not?
Stabilizing a language is a tricky process. If you do it too
early, then you’re stuck with whatever mistakes or poor design
decisions. If you do it too late, then there’s a large body of
documents in the pre-stabilized version which will require
updating before they run in the stabilized version.
I see two options:
1. No stability: we go back to the way things worked a few
years ago. When a programmer wants to change something, he
changes the code and maybe adds a convert-ly rule if it’s
convenient to do so, otherwise just adds a warning to the
NEWS. I stop telling people “no, don’t change the syntax,
and don’t even talk about changing the syntax”.
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. 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.
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.
** Example subset
In greater detail: I’m suggesting that we have a round of syntax
stabilization (GLISS). At the end of it (3 months? 6 months?), we
add a few regression tests that might look something like this:
\version "2.16.0"
\score {
\music {
\staff {
\voice {
a4 b c4. d8 |
\tuplet 2/3 { fis4 a bes } r2 |
}
}
}
}
and then we guarantee that this file 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
