[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: |
thomasmorley65 |
Subject: |
Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden) |
Date: |
Mon, 30 Apr 2018 15:55:35 -0700 |
On 2018/04/30 22:19:12, Carl wrote:
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 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.
Pitch and duration are surely terms every musician and every
music-typesetter will know, they are _musical_ terms as well.
Not so post-event.
Maybe it would be sufficient to reword:
"optionally followed by one or more elements, which are called
"post-events".
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 21:49:37, thomasmorley651 wrote:
>
> Here as well.
>
> Also, I think it's important to drop a sentence about the "-"-signs,
which
> actually attach those optional elements to the note.
>
> So my suggestion:
>
> "Optional elements are added at the end of the initial
note-duration-entry.
> Probably using a "-"-sign, which can be omitted, if no ambiguity
occurs.
> Suppose we ..."
>
>
I don't think I agree that things are attached with "-" signs. For
example,
\staccato, \mordent, \turn, \fermata, \prall, (, [. None of these are
attached
with "-" signs, although they can have a direction indicator (-, _ ,
^)
preceding them if desired. At least, that is what the N.R. 5.4.2
says.
Here the NR is not entirely complete.
"_" and "^" _are_ direction-modifiers, ofcourse.
"-" _is_ the method to insert a post-event into a list of other
post-events.
For convenience it can be omitted, if no ambiguity is present. (It can't
be omitted before a fingering, for example)
The direction of this post-event is the default-direction for said
post-event. But this more a side-effect.
Also, see:
{ \displayLilyMusic c'\tenuto }
=> c'4--
If we want to talk about direction indicators here, I think we can
give a brief
introduction. If not, I think we should leave them out completely.
Agreed, direction-modifiers shouldn't be explained here in the
fundamentals.
In the LM
and the NR, the direction indicators are always included when we add
the
post-events, if they are needed.
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode488
Documentation/learning/fundamental.itely:488: {c'8-1--(~^\markup{"text
annotation"} c' d')}
On 2018/04/30 21:49:37, thomasmorley651 wrote:
>
> For the sake of simplicity I'd not use direction-modifiers and enter
the text
> without explicit \markup, i.e.:
> {c'8-1--(~-"text annotation" c' d')}
I think it's actually nicer not to have so many "-" characters; they
make it
confusing, in my opinion.
Ofcourse, but I don't understand the relevance here.
{c'8-1--(~-"text annotation" c' d')} does not use more "-" than the
other code.
Btw, maybe better to add a space after { and before }.
https://codereview.appspot.com/343060043/
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), (continued)
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), tdanielsmusic, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), Carl . D . Sorensen, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), Carl . D . Sorensen, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), tdanielsmusic, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), Carl . D . Sorensen, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), tdanielsmusic, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), thomasmorley65, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), Carl . D . Sorensen, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden),
thomasmorley65 <=
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), thomasmorley65, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), Carl . D . Sorensen, 2018/04/30
- Re: Clarify notation for slurs and beams (issue 343060043 by address@hidden), dak, 2018/04/30