https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode465
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
performed
> _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
duration,
> optionally followed by things such as articulations, fingerings,
string
numbers,
> 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
and
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
LilyPond
constructs.
"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 ...
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode481
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.
https://codereview.appspot.com/343060043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
