lilypond-devel
[Top][All Lists]
Advanced

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

Re: GOP2-5 - GLISS discussions


From: David Kastrup
Subject: Re: GOP2-5 - GLISS discussions
Date: Fri, 21 Sep 2012 10:38:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Marc Hohl <address@hidden> writes:

> Am 14.09.2012 20:48, schrieb Graham Percival:
>
>> [...]
>> David, after Waltrop I was really enthusiastic about lilypond.  I
>> saw the problems that Rudolfo had in trying to make a simple
>> change to the website, and I was really fired up to fix the
>> problems in the CG.  I was also fired up to organize weekly
>> discussions on irc and/or voice.  However, your insulting tone in
>> the GLISS emails has completely negated that enthusiasm.
> Yes. Waltrop was a very special experience (I think for all
> of the participants) and the mail exchange about GLISS is
> quite the opposite to that.

So what's going wrong here?  The easy answer is that in Waltrop I was so
busy keeping up with the meeting requirements that I had no chance to
meddle.  But that's not the whole story.  Part of it was also the
setting where the talks were mostly a minor distraction and people
instead focused on something else they were just busy with.  If you
remember the syntax proposals talk of Janek, it got me in controversial
mode (it also scared the Scorio and Philomelos people who have an
interest in keeping up with LilyPond syntax) where objections kept
coming.  Now in some sense, that's one idea of such a meeting: bouncing
ideas off other people.  The agitation is similar on the mailing lists,
but the distractions in between are missing.

Now the lack of the conference organization and schedule meant that
I did not actually talk about the ongoing parser work.  Instead we had
talks about hypothetical syntax changes.  Which sheds _some_ light on
parser development and its involvement but rather indirectly.  I also
tried a session "let's see how to actually mess with the grammar, and
how to iron out problems" which might have served to bring across the
point "not everything's as easy as one would like to think" but mostly
made people's eyes glaze over in boredom.  I failed to cover the middle
ground, and thus missed out on this chance.

I would, however, strongly recommend that anybody wanting to involve
himself in syntax discussions read the 2.16 Changes document
<URL:http://lilypond.org/doc/v2.16/Documentation/changes/index.html>
completely.  It is not long, it has been written to be user accessible,
and it tells a good part of the direction and developments that several
syntactic elements have taken, along with the underlying rationale.  And
it is a waste of time to bring everybody to the present separately.

It's also a bit of a nuisance to get rehashes of
<URL:http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00194.html>
and its ilk every now and then.

It is thinkable to do a "repeat last pitch when unmotivated duration
occurs in music" rule, but we'll get a rerun of all the issues regarding
q again in the context of \relative music and other stuff.  \relative
really is not a favorite of mine to support.  \transpose c c'' { } is
probably more predictable in most cases.

> Don't get me wrong; I think I can understand your reaction.
> You are probably the only one who can cope with the parser
> stuff, so with every idea showing up, you probably weigh this
> in relation to the parser work you had done or are about to do,
> and most of the "proposals" (what they aren't really) go in
> the wrong direction.

For many of them the price is not right.  Not just in work to be done,
but in resulting hard to explain behavior (usually the amount of work
bears some relation to how well a change sits with the rest of the
parser also in terms of logic and consistency).  There are also changes
one can "just squeeze in" surprisingly easy and that cause a lot of
headaches for maintainability or future development.

q was such an example: it was implemented reasonably fast, and it took
years until I had the infrastructure in place to make it actually work
in the context of \relative music passing through music functions or
variables.  Once such a "feature" works 90% of the time, everybody will
crucify you if a change of yours causes it to break in different cases
than the previous 10%.

So there is not just a motivation to keep syntax proposals in an
affordable range, but also an incentive to actually discourage people
trying sleight of hand on the parser, because it might be much more work
to fix the followup breakage than the original "improvement" took until
it stopped breaking existing unrelated regtests (possibly by virtue of
"fixing" the regtests).

> By the way: I like the idea of simplifying the
> \override \set \tweak stuff, that's something that would really be
> helpful for users; ideally in combination with a more
> verbose explanation from Lilypond why
> \override BarLine #'foo will not change anything in the output.

Well, I am in disagreement over the approaches with Han-Wen, so for that
reason alone I want to give my approach the best shot I can, and that
means I am not delegating the bulk of the work.  At the current point of
time, the parser syntax stuff particularly in relation to music
functions is still most pressing for me, so putting a unifying framework
around \override/\set will have to wait.

One change in the area of the parser is to prohibit

\override Grob #'one #'two = 7

syntax and instead require

\override Grob #'(one two) = 7

The above syntax just confuses people into thinking that

\revert Grob #'one #'two

would be the corresponding revert, and it isn't.  You need to write

\revert Grob #'(one two)

anyway.

> Generally, I don't think there will be massive changes to the syntax
> (but maybe I am proven wrong): a lot of quite long and/or complex
> pieces are typeset by lilypond, so the ly language is not the worst
> option.

There is pressure from users for "simplifications", and from people
having to read the LilyPond files by computer for not going overboard
with the simplifications.

But I don't think we'll get around making LilyPond have good MusicXML
export, and be able to read MusicXML as a native input language.  But it
does not make sense to rush this before Guilev2 migration.

-- 
David Kastrup



reply via email to

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