[Top][All Lists]

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

Re: Clarify notation for slurs and beams (issue 343060043 by address@hid

From: dak
Subject: Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden)
Date: Mon, 30 Apr 2018 20:26:24 -0700
File Documentation/learning/fundamental.itely (right):
Documentation/learning/fundamental.itely:465: optionally followed by one
or more post-events.  Post-events add
On 2018/04/30 22:19:12, Carl wrote:
On 2018/04/30 21:49:37, thomasmorley651 wrote:
> I'd completely delete 'post-event'.
> From a musical thinking it makes no sense. An articulation is not
> _after_ the note.
> To explain it programmatical, this is not the right place, imho.
> Why not simply:
> "A note entry in LilyPond consists of a pitch, followed by a
> optionally followed by things such as articulations, fingerings,
> slurs, ties, explanatory text, etc."

We could do this.  But ultimately all the things that attach to notes
like this
are called post-events in the internals reference.  So I don't think
it's a bad
idea to introduce the LilyPond term here, just like we do for pitch
duration.  All three terms (pitch, duration, post-event) are LilyPond
terms, not
musical terms.

We aren't explaining music in this section.  We are explaining

"pitch" and "duration" are certainly valid musical terms outside of
LilyPond and describe musical entities even within LilyPond.
"post-event" does not carry meaning separate from the LilyPond grammar.

It might make sense to introduce it as a LilyPond term by putting it in
quote marks first mention:

one or more @q{post-events}.  Post-events are placed after a main event
in the input and constitute things such as ...
Documentation/learning/fundamental.itely:481: Post-events follow the
note to which they are attached.  Suppose we
On 2018/04/30 22:19:12, Carl wrote:
I don't think I agree that things are attached with "-" signs.

It's more a less a matter of what one wants to declare the rule and what
the exception.  It's more of a semantic difference, so it's more the
question of which view might be more helpful.

I'd lean towards keeping your version here: I think it better matches
what we use elsewhere.

reply via email to

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