Re: how to make decisions?
Jan Nieuwenhuizen jann...@gnu.org writes: Graham Percival writes: What's depressing? I didn't see anything unusual in those comments. I would not use the word depressing, but I cannot help wondering why someone would think that, anno 2009, using musixtex would be a good idea, and needs to blog about it and get comments to find out about the existence of LilyPond. Also, it is saddening to read a senior consultant with a PhD suggest the use of a proprietary software package. It is the job of a consultant to recommend a reliable way of turning money into success. Would you buy a car without gas tank opening? Oh, this car does not need refilling. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 06, 2012 at 10:22:57AM +0200, David Kastrup wrote: Absolutely. I'll just point out where one person who tried out Lilypond was innocently transparent in his bewilderment that anyone would call out fis in the key of D, and quietly denote the unusual F-natural as f. http://www.johndcook.com/blog/2009/03/15/typesetting-music-in-latex-and-lilypond/ The comments are almost more depressing than the blog post itself. What's depressing? I didn't see anything unusual in those comments. They shun LilyPond for all the wrong reasons. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
David Kastrup writes: Also, it is saddening to read a senior consultant with a PhD suggest the use of a proprietary software package. It is the job of a consultant to recommend a reliable way of turning money into success. Would you buy a car without gas tank opening? Oh, this car does not need refilling. You imagine that he receives some kind of revenue from suggesting the use of proprietary software and that for this particular blog, it was more lucrative to suggest Sibelius; otherwise he would just as convincingly steered people to Finale? Man, am I naive. I do see now what you find depressing about this. How can we ever hope to get people to suggest LilyPond; by merit only?! Jan but-it's-just-an-innocent-blog-post Nieuwenhuizen -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
David Kastrup writes: They shun LilyPond for all the wrong reasons. Well, the wrong reasons are easily countered. And as long as they don't identify the good reasons to avoid LilyPond, we can hopefully fix some of them before they find out ;-) Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On Fri, Sep 7, 2012 at 10:36 AM, Jan Nieuwenhuizen jann...@gnu.org wrote: You imagine that he receives some kind of revenue from suggesting the use of proprietary software and that for this particular blog, it was more lucrative to suggest Sibelius; otherwise he would just as convincingly steered people to Finale? I find it more depressing that most people do recommend proprietary software because they don't see anything wrong in it! Man, am I naive. I do see now what you find depressing about this. How can we ever hope to get people to suggest LilyPond; by merit only?! By sword and fire! ;) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
David Kastrup d...@gnu.org writes: They won't give up their working cars and their mechanics. We need to offer something new. And new business models (like transpose-on-demand with electronic or overnight delivery when the soloist would be inconvenienced by wrong pitches). Ultimately things like a whole orchestra playing from electronic paper, getting acoustically synchronized page turns, live synchronized performance indications (the conductor makes a different decision in his partitura and the sheets from the musicians follow suit) and corrections. Including let's take that aria one note down. Actually, just being able for the conductor to flip the partitura to one page and point to a measure and have all the orchestra's sheets flip to the same page and have the measure flashing in red would make things a lot easier. Of course you can do the same using traditional typesetting if every score rendition knows where every measure is. But things like an orchestra player telling his score to format things bigger since he can't properly see stuff (changing page layout, _if_ one wants to have page layout rather than an endless vertical roll) are also important. One _repeated_ advantage cited to me from people sponsoring LilyPond work was the ability to create scores formatted larger for the sake of people with seeing impairments, thus keeping the world of music accessible to old people and/or monks performing under less than optimal light conditions. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Keith OHara k-ohara5...@oco.net writes:
David Kastrup dak at gnu.org writes:
I proposed already at one point of time to require writing 4.0 rather
than 4. for the floating point number. This will not cure a lot of use
cases, and we still have the ambiguity between 4 the duration and 4 the
integer, and -4 the fingering and -4 the integer.
Some of those can be resolved in context, but this does not help for
conversions, and we also have largely context-free situations, like in
#{ ... #} or on the right side of assignments. At the current point of
time, I can't write things like #{ 4.0\cm #} in appropriate contexts
because 4.0 is not recognized in notemode as a real number. Writing
#{ $4.0 \cm #} would work but it does not exactly win a prize for
beauty.
This is interesting. LilyPond has used context to know that in
\paper {line-width = 16.\cm}
the '-' is part of the variable name, the '16.' a decimal number, and the
\cm a predefined dimension -- as opposed to
cm = {c16. d64 e_- } \new Voice \cm
We have been required to use Scheme to write decimal numbers, everywhere
outside of \paper{} and other headers
midiMaximumVolume = #0.7
Is this why you let '-' and '_' in identifiers out of their previous
confines? I thought you wanted them in music identifiers. (Others have
requested the '_' at least.)
I am not interested in using them in music identifiers (and the entry in
changes.tely clearly says so:
Staying with established conventions (like not using dashes or
underlines for command names intended to be used inside of music)
remains advisable. The reason for this change is more robust
recognition of LilyPond's lexical units for LilyPond itself as well as
external tools interpreting its syntax.
The principal reason was to be able to unify command/word syntax across
modes to allow scanning of a lookahead token over a lexer mode switching
border.
How far do you foresee merging the syntax in \paper {} with that in
note-entry mode?
One token far. Syntax is more than token syntax. I'd definitely like
fewer lexer modes, though.
I've seen complaints in non-Lilypond forums that LilyPond pitch
entry is not relative to key signature. We could accommodate this
...
My personal take on this is no. Reason 1 ... 2 ...
Absolutely. I'll just point out where one person who tried out Lilypond
was innocently transparent in his bewilderment that anyone would call
out fis in the key of D, and quietly denote the unusual F-natural as f.
http://www.johndcook.com/blog/2009/03/15/typesetting-music-in-latex-and-lilypond/
The comments are almost more depressing than the blog post itself.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On Thu, Sep 06, 2012 at 10:22:57AM +0200, David Kastrup wrote: Absolutely. I'll just point out where one person who tried out Lilypond was innocently transparent in his bewilderment that anyone would call out fis in the key of D, and quietly denote the unusual F-natural as f. http://www.johndcook.com/blog/2009/03/15/typesetting-music-in-latex-and-lilypond/ The comments are almost more depressing than the blog post itself. What's depressing? I didn't see anything unusual in those comments. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On 03/09/12 14:18, David Kastrup wrote: I don't have a good answer here, and I am not particularly happy with suggesting that the work I end up doing will not likely be shaped much by committee or community decisions but rather mostly by my own conscience and programmer instincts. Which, in turn, are shaped by the perceived needs of the community. Would it be better in this respect if, instead of proposing syntax changes (which are easily problematic if done without sufficient knowledge of how the parser and lexer work), we collaborated on defining the _problem_ with sufficient rigour? That is, identifying what the syntax needs to achieve and how the current syntax fails. In this case, the problem might include that the syntax needs an unambiguous way to indicate whether a command applies to a preceding or subsequent note or entity; an unambiguous way to group together entities (including commands) so that other commands can be applied to them collectively; a way to indicate direction where this matters; and so on. I'm deliberately _not_ being rigorous at this point, but I think you get the idea. Then, once the problem _is_ rigorously defined and agreed upon, you and the others who understand the technical issues could propose a solution, and we could provide feedback in terms of usability, whether it actually _does_ solve the problem we face and so on, and so evolve towards a solution. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On 06/09/12 11:48, Graham Percival wrote: What's depressing? I didn't see anything unusual in those comments. I suppose it's a bit depressing that no one pointed out why it matters that you enter exact pitch names and don't infer accidentals from the key signature. (I.e., how do you copy-paste effectively unless pitches are specified exactly?) I've added a comment (currently in moderation) touching on this point and also pointing out that it's possible to use other note-names than the Dutch. A bit late for a 2009 blog post, but better late than never. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Graham Percival writes: What's depressing? I didn't see anything unusual in those comments. I would not use the word depressing, but I cannot help wondering why someone would think that, anno 2009, using musixtex would be a good idea, and needs to blog about it and get comments to find out about the existence of LilyPond. Also, it is saddening to read a senior consultant with a PhD suggest the use of a proprietary software package. Hopefully he'll hear about Sibelius' [development] demise and takes the lock-in-to-a-possbily-dieing-vendor viewpoint into account when suggesting software solutions. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Message: 1 Date: Thu, 06 Sep 2012 16:25:49 +0200 From: Jan Nieuwenhuizen jann...@gnu.org To: Graham Percival gra...@percival-music.ca Cc: David Kastrup d...@gnu.org, lilypond-devel@gnu.org Subject: Re: how to make decisions? Message-ID: 878vcnp6s2@nlvehvbe01nb29b.ddns.nl-htc01.nxp.com Content-Type: text/plain; charset=utf-8 Graham Percival writes: What's depressing? I didn't see anything unusual in those comments. I would not use the word depressing, but I cannot help wondering why someone would think that, anno 2009, using musixtex would be a good idea, and needs to blog about it and get comments to find out about the existence of LilyPond. Also, it is saddening to read a senior consultant with a PhD suggest the use of a proprietary software package. Hopefully he'll hear about Sibelius' [development] demise and takes the lock-in-to-a-possbily-dieing-vendor viewpoint into account when suggesting software solutions. Advocating for free software is a lot more complex than just telling people to avoid vendor lock-in (which can happen in free software[1]. And having a PhD does not mean a person has the time to do a full-on research project to figure out if the four freedoms of the GPL are actually a viable way to protect users' freedoms. Heck, they probably don't even have the time to really grasp what user freedom even means, if we're being serious about the true extent of that phrase. This is especially problematic because the most obvious user-facing part of free software-- the graphical user interface-- has historically been the weakest link. So there's the quite real deficiency in what the user _sees_ when they open Pure Data when compared to Max/MSP-- which is immediately apparent-- and they must weigh that against the ethical implications of using proprietary software-- which require a research project[2]. Similarly with Sibelius. I don't understand why you're saddened by this, especially considering you're fighting on two fronts because even with the frontends Lilypond has no _easy_ way to make tweaks to a large score without unreasonably long periods of recompilation. Did you really expect composers and engravers to spend time they don't have solidfying an ethical argument against software that does a decent technical job for them in order to use an ethical alternative that will clearly require more of their time in order to finalize output? [1] See tivoization, as well as software-as-a-service. [2] And since when are PhDs more likely to make ethical decisions outside of their area of expertise? -Jonathan Jan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On Thu, Sep 6, 2012 at 2:33 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 03/09/12 14:18, David Kastrup wrote: I don't have a good answer here, and I am not particularly happy with suggesting that the work I end up doing will not likely be shaped much by committee or community decisions but rather mostly by my own conscience and programmer instincts. Which, in turn, are shaped by the perceived needs of the community. Would it be better in this respect if, instead of proposing syntax changes (which are easily problematic if done without sufficient knowledge of how the parser and lexer work), we collaborated on defining the _problem_ with sufficient rigour? That is, identifying what the syntax needs to achieve and how the current syntax fails. +1. I think i have to stop talking about my ideas all the time. :) I'll take a break and focus on defining problems. Then, once the problem _is_ rigorously defined and agreed upon, you and the others who understand the technical issues could propose a solution, and we could provide feedback in terms of usability, whether it actually _does_ solve the problem we face and so on, and so evolve towards a solution. +1. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On Tue, Sep 4, 2012 at 11:22 PM, Trevor Daniels t.dani...@treda.co.uk wrote:
So what problems do the users have, exactly? We should address this
question first.
[...]
But if we are to have a discussion about syntax let's first list the problems
we need to solve, and reach agreement on which ones need to be tackled.
Then we know what it is we are trying to optimise.
I think that's a very good idea. It seems to me that we don't have
the big picture yet - and we should have it before discussing specific
proposals.
I think that for the next several weeks we should focus on gathering
information about the /problems/ people have. Not the ideas for
solutions. Problems.
For example,
in { a \parenthesize b \mf c d } it's confusing what gets
parenthesized and what gets mezzoforte
is a description of a problem, while
lets require a dash before everything that attaches to a note
is a solution. Lets talks about problems first, then solutions.
I'd propose these as the official rules of thumb for next 2 months:
- describe the problems you have. What is confusing? What is
inconvenient? What is difficult to express in Lily syntax?
- don't discuss possible solutions. If you absolutely have to,
mention shortly and idea, but don't discuss it yet.
This way we won't waste our time discussing the specifics before
knowing what is this all about.
What do you think? Graham?
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Trevor Daniels t.daniels at treda.co.uk writes:
So what problems do the users have, exactly? We should address this
question first. Janek apparently has his list, which would be a good start.
But we should not invent problems where they don't exist. I've probably
read every email on the user list for the last 4 years, and inconsistent
parser rules have not figured prominently.
I generally agree. But I also have sympathy for the desire to first clarify
some broader questions -- such as, in which /direction/ to straighten out the
parser when user problems require changes to the parser.
I understand that past catering to concrete user needs has gradually resulted
in a messy syntax, very difficult to import into other systems (musescore
tried), which also makes it harder to cater to some current user desires.
The readable \tempo Adagio 4. = 30~40 lacks the delimiters that most
computer-entry formats require, which made it unusable in a \midi block for
many years -- because LilyPond accepts decimal-point numbers in the midi block,
for probably another good reason. Without requiring delimiters it is hard to
specify exactly when LilyPond should read 4. as a duration, and when as 4.000.
One situation where LilyPond /does/ require delimiters is \chordmode { c4:8 }
The broad question is: Require delimiters to clarify context (for users,
LilyPond, and software importing LilyPond) -- more or less?
I've seen complaints in non-Lilypond forums that LilyPond pitch entry is not
relative to key signature. We could accommodate this by re-defining pitch
names upon seeing
{ \keyAffectingEntry \d\major ... }
so that f means F-sharp and we have to type fn for F. (This requires pushing a
pitchname-table on a stack for every nested level of {} or )
Digits-in-identifiers is an often-requested feature that seems it should be
easy (if we are willing to require a space in \skip 4 and \tuplet 2/3). The
trouble is that I cannot use vn1 = {..} without either telling the lexer that
vn will never by a note-name in any language, or requiring some structure to
specify when music functions are done: \afterGrace ces2 des8 vn1 = c2.
I used to use \cueWhile, but then switched to your \cueDuring with the extra
parameter, and had a few mysterious errors when I forgot which one had the
extra parameter. David of course suggested I make a \cueDuring with an
optional parameter. Either way, the poor guy writing the .ly importer in
Musescore has no hope to keep up.
The broad question for these three is: Syntax that changes depending on the
definitions of the functions in the input -- good or bad?
My prediction is that LilyPond will keep its syntax that requires knowledge of
the definition of functions to be parsed correctly, thus un-importable by other
software,
.. and that LilyPond will keep its freedom from delimiters, with David pulling
LilyPond further toward scanning the input independent of context.
Others certainly frame the broad questions differently, and probably see
additional broad questions. I think we need to allow some time for compromise
on these balances between philosophy and practicality.
Many of the specific items on the GLISS list concern names of things, which I
think is independent of the broad questions, but will solve some real
problems. I was quite puzzled by a question on -user yesterday, until I
realized he had confused the purposes of Staff.keySignature versus
Staff.KeySignature.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Janek Warchoł janek.lilypond at gmail.com writes:
I think that for the next several weeks we should focus on gathering
information about the /problems/ people have. Not the ideas for
solutions. Problems.
For example,
in { a \parenthesize b \mf c d } it's confusing what gets
parenthesized and what gets mezzoforte
is a description of a problem, while [...]
is a solution. Lets talk about problems first, then solutions.
I think I have that problem, but maybe not exactly what you mean.
Does the confusion you refer to happen more in reading (other people's)
Lilypond input, or in writing your own Lilypond input?
I often have difficulty remembering which incantation I need to type, in
order to set music the way I need. Part of what I need to remember is the
order in which I need to type the commands and notes.
If I use \parenthesize, I also need to remember how to apply it to the
note-head, or more likely the mf or some accent.
When working with other people's Lilypond, I just look at the output to
remember what commands mean, so I have no problem there.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Keith OHara wrote Wednesday, September 05, 2012 9:59 AM I generally agree. But I also have sympathy for the desire to first clarify some broader questions -- such as, in which /direction/ to straighten out the parser when user problems require changes to the parser. The broad question is: Require delimiters to clarify context (for users, LilyPond, and software importing LilyPond) -- more or less? There are many places in LilyPond now where delimiters are necessary to resolve certain situations but are not generally mandatory. Perhaps this approach could be extended. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Keith OHara k-ohara5...@oco.net writes:
The readable \tempo Adagio 4. = 30~40 lacks the delimiters that most
computer-entry formats require, which made it unusable in a \midi
block for many years -- because LilyPond accepts decimal-point numbers
in the midi block, for probably another good reason. Without
requiring delimiters it is hard to specify exactly when LilyPond
should read 4. as a duration, and when as 4.000.
I proposed already at one point of time to require writing 4.0 rather
than 4. for the floating point number. This will not cure a lot of use
cases, and we still have the ambiguity between 4 the duration and 4 the
integer, and -4 the fingering and -4 the integer.
Some of those can be resolved in context, but this does not help for
conversions, and we also have largely context-free situations, like in
#{ ... #} or on the right side of assignments. At the current point of
time, I can't write things like #{ 4.0\cm #} in appropriate contexts
because 4.0 is not recognized in notemode as a real number. Writing
#{ $4.0 \cm #} would work but it does not exactly win a price for
beauty.
One situation where LilyPond /does/ require delimiters is
\chordmode { c4:8 }
That's because it changes the lexer modes. Switching back reliably is
only possible when you have a closing delimiter that can still be
scanned in the inner lexer mode, so that you are in outer lexer mode
again before even having to start looking at the next token.
The broad question is: Require delimiters to clarify context (for
users, LilyPond, and software importing LilyPond) -- more or less?
Where necessary.
I've seen complaints in non-Lilypond forums that LilyPond pitch entry is not
relative to key signature. We could accommodate this by re-defining pitch
names upon seeing
{ \keyAffectingEntry \d\major ... }
so that f means F-sharp and we have to type fn for F. (This requires
pushing a
pitchname-table on a stack for every nested level of {} or )
My personal take on this is no. Reason 1 is that then the actual
pitch will depend on _input_ accidental rules. That will make MIDI and
MusicXML output less predictable. Reason 2 is that a human-oriented
linear non-graphic representation of what is usually seen graphically
should resemble the manner in which humans would talk on the phone, a
similarly linear medium. I don't know other note language conventions,
but here in Germany you would _never_ call a fis an f just because its
accidental is contained in the key signature. Totally unthinkable even
among amateurs. You'd immediately get Oh, this is supposed to be an f?
How do you tell?. Not because of nitpicking, but because nobody would
guess that f would be used to describe a fis.
So this is at least for me a very definite this is not even open to
consideration area. Of course, people deserve to be told just _why_ it
is such a bad idea.
I used to use \cueWhile, but then switched to your \cueDuring with the
extra parameter, and had a few mysterious errors when I forgot which
one had the extra parameter. David of course suggested I make a
\cueDuring with an optional parameter. Either way, the poor guy
writing the .ly importer in Musescore has no hope to keep up.
Just because some part of LilyPond syntax is defined as music functions,
that does not mean that one can't describe it formally.
The poor guy writing the .ly in Musescore at least has a chance of
designing a single mechanism able to recognize _all_ variants of music
functions that we permit. That makes it easier for him to _systematize_
his work.
The broad question for these three is: Syntax that changes depending
on the definitions of the functions in the input -- good or bad?
Essential to LilyPond's design and expressivity. That does not mean
that we should not try maximizing the good aspects and minimizing the
bad aspects.
My prediction is that LilyPond will keep its syntax that requires
knowledge of the definition of functions to be parsed correctly, thus
un-importable by other software,
A LilyPond-to-LilyPond conversion would at least rip out user-defined
functions and render the predefined ones, where necessary to represent
music expressions, in a predictable manner.
.. and that LilyPond will keep its freedom from delimiters, with David
pulling LilyPond further toward scanning the input independent of
context.
Again, this is not achievable in the absolute. But there is still
leeway to do better than we have. And being able to get along with
fewer modes also means that one does not need to choose between the
respective benefits of several modes, but can profit from the
combination.
Others certainly frame the broad questions differently, and probably
see additional broad questions. I think we need to allow some time for
compromise on these balances between philosophy and practicality.
Many of the specific items on the GLISS list concern names of things,
which I think is independent of the broad
Re: how to make decisions?
On Tue, Sep 4, 2012 at 6:22 PM, Trevor Daniels t.dani...@treda.co.uk wrote: If I missed your point, can you state it more explicitly? I can see now my point was not stated clearly. It was: At this stage in the discussions it is important to be clear about what problems we are trying to solve, In this discussion we must always consider what it is we are trying to optimise. I take your point that the syntax should be unambiguous, but I don't see why this should dominate the discussion. Improving the syntax from the point of view of usability is equally if not more important; certainly those considerations and discussions should come before thinking how they might be handled in the parser. When you and Jan first started thinking about the LilyPond language I'm sure you began by considering how music could best be encoded. Only later did you devise the precise syntax. We should continue in the same way. You are largely correct about historical choices, but we made our choices on a clean slate. The complexity of the grammar has progressed so far that ambiguity and compatibility is now a major issue. So far, the only proposal I have seen so far that does not generate any ambiguity concerns is making \[ postfix. Furthermore, reiterating what David said, if something is ambiguous or subtle to the parser, it will be to the user as well, and as such it affects usability. Compare TeX macros. It may be obvious when you see some examples, but there is edge case behavior which is difficult to understand So what problems do the users have, exactly? We should address this question first. Janek apparently has his list, which would be a good start. But we should not invent problems where they don't exist. I've probably read every email on the user list for the last 4 years, and inconsistent parser rules have not figured prominently. Another example is the considerable discussion so far about pre- and post-fix notation. Again, has this been a problem prominent on the user list? I don't think so. So why try to solve it? Especially in ways that would screw all existing code. In fact, I don't think /users/ have any serious problems with the syntax as it currently exists, other than getting to grips with it initially. So I'd be happy to let David continue his work straightening out the parser, which is good, and improving the functionally, even better. But if we are to have a discussion about syntax let's first list the problems we need to solve, and reach agreement on which ones need to be tackled. Then we know what it is we are trying to optimise. I completely support this analysis. -- 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: how to make decisions?
2012/9/4 Trevor Daniels t.dani...@treda.co.uk:
So what problems do the users have, exactly? We should address this
question first. Janek apparently has his list, which would be a good start.
But we should not invent problems where they don't exist. I've probably
read every email on the user list for the last 4 years, and inconsistent
parser
rules have not figured prominently. Another example is the considerable
discussion so far about pre- and post-fix notation. Again, has this been a
problem prominent on the user list? I don't think so. So why try to solve
it?
Especially in ways that would screw all existing code. In fact, I don't think
/users/ have any serious problems with the syntax as it currently exists,
other than getting to grips with it initially.
Very true, in my opinion.
For newcomers, the whole paradigm is a challenge. However, once they
have the basics, musicians can learn the rules.
\offtopic {
New Spanish users find it difficult to get used to very common
keystrokes which are only under AltGr in Spanish keyboards. So, lesson
zero for the language from a practical POV is:
{}{}{}{}
\{} \{} \{}
Now you are prepared to write \relative f { c }.
What I once found embarrassing was to try \key d (and no \major or
\minor afterwards) and fail to compile because, in my mind, in D
means \key d \major with \major by default. Then I learned that \key
has two non-optional arguments and now I think optional arguments are
problematic.
Regarding \relative optional_pitch {}, I think the optional pitch is
very problematic and now it's time to mandate a pitch argument, forbid
the obsolete form \relative {} and convert-ly it into \relative f
{}.
New non-English users often complain for having to remember the
keywords, of course. In my opinion, if you know the keyword by heart,
you also know whether it is prefix or postfix, and its number of
arguments. For me as an user, it would be a disaster to change the
beautiful, consistent, unique backslash character to three different
characters for prefix, postfix and neutral commands. It would generate
by itself more errors that the current status.
Sorry for the
} % off-topic.
--
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: how to make decisions?
Francisco Vila paconet@gmail.com writes:
2012/9/4 Trevor Daniels t.dani...@treda.co.uk:
So what problems do the users have, exactly? We should address this
question first. Janek apparently has his list, which would be a good start.
But we should not invent problems where they don't exist. I've probably
read every email on the user list for the last 4 years, and
inconsistent parser
rules have not figured prominently. Another example is the considerable
discussion so far about pre- and post-fix notation. Again, has this been a
problem prominent on the user list? I don't think so. So why try
to solve it?
Especially in ways that would screw all existing code. In fact, I
don't think
/users/ have any serious problems with the syntax as it currently exists,
other than getting to grips with it initially.
Very true, in my opinion.
For newcomers, the whole paradigm is a challenge. However, once they
have the basics, musicians can learn the rules.
\offtopic {
New Spanish users find it difficult to get used to very common
keystrokes which are only under AltGr in Spanish keyboards. So, lesson
zero for the language from a practical POV is:
{}{}{}{}
\{} \{} \{}
Now you are prepared to write \relative f { c }.
What I once found embarrassing was to try \key d (and no \major or
\minor afterwards) and fail to compile because, in my mind, in D
means \key d \major with \major by default. Then I learned that \key
has two non-optional arguments
It has two optional ones. Being in end position, they can only be
skipped by an explicit \default. If I remember correctly, skipping just
one caused an error message, so \key \default works, but \key c\default
doesn't.
and now I think optional arguments are problematic.
Regarding \relative optional_pitch {}, I think the optional pitch is
very problematic and now it's time to mandate a pitch argument, forbid
the obsolete form \relative {} and convert-ly it into \relative f
{}.
That does not make sense. The obsolete form \relative {} is to be
converted to \relative c' {} if at all. I _wish_ it would have been
defined as \relative f {} since that is logically very much related to
leaving the pitch off altogether. But history has decided otherwise.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On Wed, 05 Sep 2012 02:54:38 -0700, Trevor Daniels t.dani...@treda.co.uk wrote: Keith OHara wrote Wednesday, September 05, 2012 9:59 AM The broad question is: Require delimiters to clarify context (for users, LilyPond, and software importing LilyPond) -- more or less? There are many places in LilyPond now where delimiters are necessary to resolve certain situations but are not generally mandatory. My brain is maybe not engaging; I can't think of an example of this. (Repeat alternatives ?) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Francisco Vila paconet.org at gmail.com writes:
For newcomers, the whole paradigm is a challenge. However, once they
have the basics, musicians can learn the rules.
\offtopic {
[...]
} % off-topic.
I found your \offtopic section, Francisco, to be quite relevant to the topic in
fact.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
David Kastrup dak at gnu.org writes:
I proposed already at one point of time to require writing 4.0 rather
than 4. for the floating point number. This will not cure a lot of use
cases, and we still have the ambiguity between 4 the duration and 4 the
integer, and -4 the fingering and -4 the integer.
Some of those can be resolved in context, but this does not help for
conversions, and we also have largely context-free situations, like in
#{ ... #} or on the right side of assignments. At the current point of
time, I can't write things like #{ 4.0\cm #} in appropriate contexts
because 4.0 is not recognized in notemode as a real number. Writing
#{ $4.0 \cm #} would work but it does not exactly win a prize for
beauty.
This is interesting. LilyPond has used context to know that in
\paper {line-width = 16.\cm}
the '-' is part of the variable name, the '16.' a decimal number, and the
\cm a predefined dimension -- as opposed to
cm = {c16. d64 e_- } \new Voice \cm
We have been required to use Scheme to write decimal numbers, everywhere
outside of \paper{} and other headers
midiMaximumVolume = #0.7
Is this why you let '-' and '_' in identifiers out of their previous
confines? I thought you wanted them in music identifiers. (Others have
requested the '_' at least.)
How far do you foresee merging the syntax in \paper {} with that in note-entry
mode?
I've seen complaints in non-Lilypond forums that LilyPond pitch entry
is not relative to key signature. We could accommodate this ...
My personal take on this is no. Reason 1 ... 2 ...
Absolutely. I'll just point out where one person who tried out Lilypond
was innocently transparent in his bewilderment that anyone would call
out fis in the key of D, and quietly denote the unusual F-natural as f.
http://www.johndcook.com/blog/2009/03/15/typesetting-music-in-latex-and-
lilypond/
Notice the phrase the Fs are sharped rather than the key has F-sharps
The broad question for these three is: Syntax that changes depending
on the definitions of the functions in the input -- good or bad?
Essential to LilyPond's design and expressivity. That does not mean
that we should not try maximizing the good aspects and minimizing the
bad aspects.
This begs for an expressive example.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
David Kastrup wrote Monday, September 03, 2012 2:44 PM Trevor Daniels t.dani...@treda.co.uk writes: Graham Percival wrote Monday, September 03, 2012 1:00 PM I don't know where to go from here. I spend a lot of effort trying to organize such discussions, because I think that LilyPond is a community project. I think that we should encourage people to participate, but telling people ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC might discourage people from working. It did. No doubt. And I don't want to promote a setup which will essentially end up as exactly that when viewed honestly. [snip] I am doing the best I can, but I don't really see how I can justly deny the underlying gist of the characterization ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC. And I want to avoid creating organizational structures that will cause exactly that impression if I am trying to do serious work according to the best of my conscience. David, it wasn't anything /you/ said; it was Han-Wen's reply which dismissed my cautionary offering as bed-shedding and referring to a sneering video about other syntax failures. Which, incidentally, illustrated my real point (which he missed) ideally. You're doing fine! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
On Tue, Sep 4, 2012 at 5:03 AM, Trevor Daniels t.dani...@treda.co.uk wrote: I don't know where to go from here. I spend a lot of effort trying to organize such discussions, because I think that LilyPond is a community project. I think that we should encourage people to participate, but telling people ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC might discourage people from working. It did. No doubt. And I don't want to promote a setup which will essentially end up as exactly that when viewed honestly. [snip] I am doing the best I can, but I don't really see how I can justly deny the underlying gist of the characterization ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC. And I want to avoid creating organizational structures that will cause exactly that impression if I am trying to do serious work according to the best of my conscience. David, it wasn't anything /you/ said; it was Han-Wen's reply which dismissed my cautionary offering as bed-shedding and referring to a sneering video about other syntax failures. Which, incidentally, illustrated my real point (which he missed) ideally. I'm sorry - I have been doing these kinds of syntax discussions for too long, and have too little time for them now. The video is intended to illustrate how a small features of a language may make sense (ie. was created with the best intentions) when viewed on small scale, but makes the language as a whole confounding. For javascript, for example, + can implicitly convert to string, which is neat for applications which do a lot of string manipulations, but it has the side effect that [1,2] + [2,3] evaluates to 1,22,3 rather than [1,2,2,3] which is surprising to many programmers. More to the point of lilypond, I'm trying to get across that the problems of new syntax constructs are usually not in the examples that motivate them, but rather in other areas of the language. An example that passed the list recently is having digits in identifiers, breaks compaitbility since \skip4 now would be a identifier dereference. My request for having parser patches is also grounded in this. Basic problems with most syntax changes become readily apparent if you try to change the parser grammar; since they often lead to ambiguities which Bison cannot resolve. Such considerations make me skeptic of changes that are explained by way of example, especially if they have a broad impact. Such changes can often not be implemented sanely. If I missed your point, can you state it more explicitly? -- 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: how to make decisions?
Han-Wen, you wrote Tuesday, September 04, 2012 2:58 PM Subject: Re: how to make decisions? On Tue, Sep 4, 2012 at 5:03 AM, Trevor Daniels t.dani...@treda.co.uk wrote: David, it wasn't anything /you/ said; it was Han-Wen's reply which dismissed my cautionary offering as bed-shedding and referring to a sneering video about other syntax failures. Which, incidentally, illustrated my real point (which he missed) ideally. I'm sorry - I have been doing these kinds of syntax discussions for too long, and have too little time for them now. I can appreciate that. Thanks for following this up. The video is intended to illustrate how a small features of a language may make sense (ie. was created with the best intentions) when viewed on small scale, but makes the language as a whole confounding. For I'm quite familiar with the concepts of grammar, parser design and BNF. In the '60s I learnt my first programming language, Atlas Autocode, largely by reading its formal description used by the compiler-compiler on the Ferranti Atlas computer at Manchester. If I missed your point, can you state it more explicitly? I can see now my point was not stated clearly. It was: At this stage in the discussions it is important to be clear about what problems we are trying to solve, In this discussion we must always consider what it is we are trying to optimise. I take your point that the syntax should be unambiguous, but I don't see why this should dominate the discussion. Improving the syntax from the point of view of usability is equally if not more important; certainly those considerations and discussions should come before thinking how they might be handled in the parser. When you and Jan first started thinking about the LilyPond language I'm sure you began by considering how music could best be encoded. Only later did you devise the precise syntax. We should continue in the same way. So what problems do the users have, exactly? We should address this question first. Janek apparently has his list, which would be a good start. But we should not invent problems where they don't exist. I've probably read every email on the user list for the last 4 years, and inconsistent parser rules have not figured prominently. Another example is the considerable discussion so far about pre- and post-fix notation. Again, has this been a problem prominent on the user list? I don't think so. So why try to solve it? Especially in ways that would screw all existing code. In fact, I don't think /users/ have any serious problems with the syntax as it currently exists, other than getting to grips with it initially. So I'd be happy to let David continue his work straightening out the parser, which is good, and improving the functionally, even better. But if we are to have a discussion about syntax let's first list the problems we need to solve, and reach agreement on which ones need to be tackled. Then we know what it is we are trying to optimise. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Graham Percival gra...@percival-music.ca writes: On Mon, Sep 03, 2012 at 01:24:22AM -0300, Han-Wen Nienhuys wrote: On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: The meta-target is after spending 5 years very publicly telling people *not* to talk about changing the syntax because we would do so 'in a year or two', I think I should encourage such discussions.. I mean, people trusted me when I said that there -snip- Whatever you have been saying in the past is irrelevant. Yes, I'm definitely getting that impression. For what it is worth, I disagree with Han-Wen here. There is sadly a grain of truth to it, but it is not the whole story, and it most certainly is not the moral of the story. As you may recall, I launched a proposal to discuss GLISS: http://lists.gnu.org/archive/html/lilypond-devel/2012-07/msg00639.html You replied with a single email: http://lists.gnu.org/archive/html/lilypond-devel/2012-07/msg00786.html Discussion continued: there seems to be fairly broad support for _some_ form of standardization: http://lists.gnu.org/archive/html/lilypond-devel/2012-07/msg00874.html The final proposal was posted: http://lists.gnu.org/archive/html/lilypond-devel/2012-08/msg00191.html with no substantial disagreement. That proposal became: http://lilypond.org/~graham/gop/gop_4.html I don't know where to go from here. I spend a lot of effort trying to organize such discussions, because I think that LilyPond is a community project. I think that we should encourage people to participate, but telling people ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC might discourage people from working. This is really a hard problem. What makes up the community and a sense of community, is a feeling of empowerment and mutual respect. LilyPond gives power to musicians to express music. And this music can be passed on and shared, and one can discuss the ways to create it, and exchange experience. And the developers are responsible for giving the users that sense of empowerment. But the actual power the users can wield over developers sensibly is rather undirected, in the way the actual power art critics can wield over the work an artist creates. If a customer says I like it or I don't like it, this is sort of a feedback. If a customer says you should use the brush X more often or I think the perspective is off in this corner or let me tell you how I think you should paint the sky, the potential for an actual improvement is rather limited. This does not imply a lack of respect for the critic's or customer's opinion. It is just that the problem space has a lot of its own inner logic that is not always easy to represent. The idea behind having an explicit policy proposal, following by at least two updates of the proposal, is to allow everybody to see just what is being considered and to have lots of time to make objections. If some people ignore the later proposals (especially the one marked final) and then object a month later, the whole process becomes a total waste of time. Granted, some people might see this as a good thing. I have the serious fear that this will either lead to a sham process and/or result in future problems. And I definitely admit that it would be mostly a relief to me if the whole process turned out a total waste of time, and it would not be honest of me to encourage decision structures that I see in conflict with the manner in which I strive to arrive at the best results I consider to be in public interest. I don't have a good answer here, and I am not particularly happy with suggesting that the work I end up doing will not likely be shaped much by committee or community decisions but rather mostly by my own conscience and programmer instincts. Which, in turn, are shaped by the perceived needs of the community. If you take a look at how, for example, religious communities work by and large, you'll find that most people are guided by their own conscience, but still feel being a part of a community, even though there are no democratic decision processes about what aspect of a deity to believe in. That's what I want to find out now. Is there any point to having policy discussions in the form of GOP ? I think they have their place, but will probably not work for governing everything. One of the neat things about Waltrop was seeing a range of developers and users. Some people were very concerned about Baroque music; others preferred pushing the boundaries of paper notation (and even going beyond static notation into video!). Some people ate meat, some people drank alcohol, some people were devoutly religious, some people were atheists. Some people organized crowd-sourcing of a book of vocal scores; some people write algorithmic music with write-once, read-never ly files. Some people wake up early, some sleep in. Some people work on converters to/from
Re: how to make decisions? (was: [GLISS] differentiatingpre/post/neutral commands)
Graham Percival wrote Monday, September 03, 2012 1:00 PM That proposal became: http://lilypond.org/~graham/gop/gop_4.html I don't know where to go from here. I spend a lot of effort trying to organize such discussions, because I think that LilyPond is a community project. I think that we should encourage people to participate, but telling people ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC might discourage people from working. It did. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions? (was: [GLISS] differentiating pre/post/neutral commands)
On Mon, Sep 3, 2012 at 9:00 AM, Graham Percival gra...@percival-music.ca wrote: On Mon, Sep 03, 2012 at 01:24:22AM -0300, Han-Wen Nienhuys wrote: On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: The meta-target is after spending 5 years very publicly telling people *not* to talk about changing the syntax because we would do so 'in a year or two', I think I should encourage such discussions.. I mean, people trusted me when I said that there -snip- Whatever you have been saying in the past is irrelevant. Yes, I'm definitely getting that impression. I'm sorry for saying this; it was too harsh. That said, I am confused. I thought the purpose was to stabilize syntax. But at the same time, I read in another mail, that you would like to consider writing all music functions with a / prefix rather than \. How can I interpret that as 'stabilising'? It is a large change that will invalidate almost all existing files, will have interactions with existing parts (/ is not unused), and will probably have repercussions we only understand after it's been rolled out for some time. As far as I can see, putting the syntax up as subject for discussion has generated lots of suggestions along the lines of let us throw away what we have and start from scratch, often without any clue of how to do this on a technical level. That's what I want to find out now. Is there any point to having policy discussions in the form of GOP ? If not, then how else should we organize ourselves? Part of my beef with the GOP mediated discussion here is that just me and David have a grasp of how things work. Get more people knowledgeable and there can be discussion. One of the neat things about Waltrop was seeing a range of developers and users. Some people were very concerned about Baroque music; others preferred pushing the boundaries of paper notation (and even going beyond static notation into video!). Some people ate meat, some people drank alcohol, some people were devoutly religious, some people were atheists. Some people organized crowd-sourcing of a book of vocal scores; some people write algorithmic music with write-once, read-never ly files. Some people wake up early, some sleep in. Some people work on converters to/from ly and musicxml, some people worked on online/realtime score generation. The LilyPond community has some shared values, some opposing values, but an overall interest in the specific code base called lilypond. How can we work on that together, while respecting our individual differences? How can we encourage and keep ourselves motivated to improve LilyPond? -- 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: how to make decisions?
On Mon, Sep 3, 2012 at 10:18 AM, David Kastrup d...@gnu.org wrote: [..] Thanks for saying all of this; I think it has been very well put. I don't have a good answer here, and I am not particularly happy with suggesting that the work I end up doing will not likely be shaped much by committee or community decisions but rather mostly by my own conscience and programmer instincts. Which, in turn, are shaped by the perceived needs of the community. That may actually be a boon; despite best intentions, design by committee usually does not lead to good designs. overall scheme, and also make some things easier to get done with. With regard to _designing_ the language of LilyPond, I think we are better off discussing and relating our goals, and seeing where this takes development. +1 -- 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: how to make decisions?
Trevor Daniels t.dani...@treda.co.uk writes: Graham Percival wrote Monday, September 03, 2012 1:00 PM That proposal became: http://lilypond.org/~graham/gop/gop_4.html I don't know where to go from here. I spend a lot of effort trying to organize such discussions, because I think that LilyPond is a community project. I think that we should encourage people to participate, but telling people ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC might discourage people from working. It did. No doubt. And I don't want to promote a setup which will essentially end up as exactly that when viewed honestly. Trying to empower non-programmers by handing them the decisions over what the programmers should be achieving is something I just don't see working out to the best interests of either. The only thing I can think of for evening out the balance is to make it easier for non-programmers themselves to bring LilyPond to do what they want it to be doing. That requires documentation, and it requires moving LilyPond in a direction where working with and on it with confidence becomes easier. This kind of empowerment has been the main theme of most of my work on music functions and Scheme/LilyPond interaction. It is, however, ongoing work, and I don't think I am doing anybody a favor by keeping it half-finished. I don't have good answers with regard to the questions what our policies should be focusing on and ruling on. And I am totally bad working according to instructions myself. But I definitely see that many people can be more productive by having good guidelines to work with. I am doing the best I can, but I don't really see how I can justly deny the underlying gist of the characterization ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC. And I want to avoid creating organizational structures that will cause exactly that impression if I am trying to do serious work according to the best of my conscience. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions? (was: [GLISS] differentiating pre/post/neutral commands)
On Mon, Sep 3, 2012 at 3:34 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: Part of my beef with the GOP mediated discussion here is that just me and David have a grasp of how things work. Get more people knowledgeable and there can be discussion. Well, is there a better ways for us (other people) to get knowledgeable than to watch you two discuss and ask questions of our own during that discussion? No offence meant. I really think that's the way to do it: we all discuss, and - by the virtue of your knowledge - you lead the discussion. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 3:34 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: Part of my beef with the GOP mediated discussion here is that just me and David have a grasp of how things work. Get more people knowledgeable and there can be discussion. Well, is there a better ways for us (other people) to get knowledgeable than to watch you two discuss and ask questions of our own during that discussion? No offence meant. I really think that's the way to do it: we all discuss, and - by the virtue of your knowledge - you lead the discussion. If you want to try messing with the parser, the integrate chordmode into notemode topic is a good starting point. Most of the reported parser conflicts in that process should bear a recognizable relation to an actual syntax issue. Of course, this suggestion is entirely unselfish, and nobody should suspect otherwise. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
