Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Dev mailing list
Reviewers: ,

Description:
Doc: Some miscellaneous suggestions from Peter Toye

Peter Toye suggested some additions/corrections to the
manuals a while ago in

https://lists.gnu.org/archive/html/lilypond-devel/2019-12/msg00191.html

and

https://lists.gnu.org/archive/html/bug-lilypond/2020-02/msg00010.html

He does not have the time to create a patch, so I prepared one for
him, mostly following his suggestions.
Sorry for the ambigous patch description.

Please review this at https://codereview.appspot.com/579280043/

Affected files (+28, -5 lines):
  M Documentation/learning/common-notation.itely
  M Documentation/learning/tutorial.itely
  M Documentation/notation/input.itely
  M Documentation/notation/rhythms.itely


Index: Documentation/learning/common-notation.itely
diff --git a/Documentation/learning/common-notation.itely b/Documentation/learning/common-notation.itely
index dec1677eb91796ce5330b0eebdafdac3298d9a83..39bf2f000e6ea7bec9ec511d9182b83eec714c31 100644
--- a/Documentation/learning/common-notation.itely
+++ b/Documentation/learning/common-notation.itely
@@ -157,8 +157,9 @@ and a @notation{flat} pitch by adding @code{es}.  As you might
 expect, a @notation{double sharp} or @notation{double flat} is
 made by adding @code{isis} or @code{eses}.  This syntax is derived
 from note naming conventions in Nordic and Germanic languages,
-like German and Dutch.  To use other names for
-@notation{alterations}, see @ruser{Note names in other languages}.
+like German and Dutch.  To use other naming schemes for
+@notation{note names} and @notation{alterations},
+see @ruser{Note names in other languages}.
 
 @lilypond[verbatim,quote]
 \relative { cis''4 ees fisis, aeses }
@@ -1331,6 +1332,7 @@ cello = \new Staff {
 
 @noindent
 By convention, variable names consist of alphabetic characters only.
+For detailed information, see @ruser{File structure}.
 
 Variables must be defined @emph{before} the main music
 expression, but may be used as many times as required anywhere after
Index: Documentation/learning/tutorial.itely
diff --git a/Documentation/learning/tutorial.itely b/Documentation/learning/tutorial.itely
index 27084f32eab12e95ac29cef38e2cda32ea92edcc..8de0c99a979119f2712052e0c4deda38697b8d3a 100644
--- a/Documentation/learning/tutorial.itely
+++ b/Documentation/learning/tutorial.itely
@@ -213,7 +213,11 @@ Music Glossary: @rglos{pitch}, @rglos{interval},
 @rglos{scale}, @rglos{middle C}, @rglos{octave},
 @rglos{accidental}.
 
-LilyPond uses lower-case letters for pitches.  The letters
+LilyPond uses lower-case letters for pitches.
+The default note names are taken from the Dutch
+naming system (white piano keys are c-b).
+These note names are used in all following examples.
+The letters
 @code{c} through@tie{}@code{b} denote pitches in the
 @q{small octave} below @notation{middle C}.  Added @code{'}
 or@tie{}@code{,} suffixes indicate higher or lower octaves.
Index: Documentation/notation/input.itely
diff --git a/Documentation/notation/input.itely b/Documentation/notation/input.itely
index 67c4fa3cbb3fab3674c8dbb7463240e3600a5e77..f0e906041c6ec9a252d89da2540017ea4147d500 100644
--- a/Documentation/notation/input.itely
+++ b/Documentation/notation/input.itely
@@ -456,7 +456,12 @@ foo = @{ c4 d e d @}
 
 This can be used later on in the file by entering @code{\foo}.  The
 name of a variable should have alphabetic characters only; no
-numbers, underscores or dashes.
+numbers, underscores or dashes.  In addition to this convention,
+variable names can include non-ASCII characters and non-adjacent
+single underscores and dashes. Any combination of characters is
+allowed if the variable name is enclosed in double quotation marks.
+In this case backslashes and double quotation marks need to be
+escaped with backslashes.
 
 @end itemize
 
@@ -863,6 +868,11 @@ Installed Files:
 @node Default layout of headers and footers
 @unnumberedsubsubsec Default layout of headers and footers
 
+@cindex page headers
+@cindex page footers
+@cindex headers, page
+@cindex footers, page
+
 @emph{Headers} and @emph{footers} are lines of text appearing at
 the top and bottom of pages, separate from the main text of a book.
 They are controlled by the following @code{\paper} variables:
@@ -2243,7 +2253,9 @@ numbers, underscores, or dashes) which cannot be confused with notes,
 the @code{#'} may be omitted and, as a shorthand, a list of symbols
 can use the dot separator: i.e., @code{\tag #'(violinI violinII)} can
 be written @code{\tag violinI.violinII}.  The same applies to
-@code{\keepWithTag} and @code{\removeWithTag}.
+@code{\keepWithTag} and @code{\removeWithTag}.  All tagging commands
+cannot be used to filter items that are not music expressions, such as
+@code{\book} or @code{\score} blocks.
 
 In the following example, we see two versions of a piece of music,
 one showing trills with the usual notation, and one with trills
Index: Documentation/notation/rhythms.itely
diff --git a/Documentation/notation/rhythms.itely b/Documentation/notation/rhythms.itely
index 55ddba8842d01e1e2d2e547c1ea0dce0dcc9c9f1..a8bf246678428baba36003a895be9550f7f939c4 100644
--- a/Documentation/notation/rhythms.itely
+++ b/Documentation/notation/rhythms.itely
@@ -3320,6 +3320,11 @@ example,
 will print a warning if the @code{currentBarNumber} is not 123
 when it is processed.
 
+@knownissues
+If MIDI output is selected and volta repeats are in place, the
+bar number check may fail.  It is best to suppress MIDI output
+while checking bar numbers.
+
 @seealso
 Snippets:
 @rlsr{Rhythms}.



Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

nine.fierce.ballads

https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely#newcode3325
Documentation/notation/rhythms.itely:3325: bar number check may fail.
It is best to suppress MIDI output
No.  Bar number checks are ignored by default when processing MIDI.  See
https://sourceforge.net/p/testlilyissues/issues/5624/ .

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Dev mailing list
In reply to this post by Dev mailing list
A nit.


https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely#newcode464
Documentation/notation/input.itely:464: escaped with backslashes.
This is confusing.  'Alphabetic characters' and 'non-ASCII characters'
are not different sets but are overlapping.  What about

  The name of a variable should not contain (ASCII) numbers,
  underscores, dashes, or space characters.  All other
  characters Unicode provides are allowed, for example Latin,
  Greek, or Chinese.  In other words, variable names like
  @code{HornIII} or @code{αβγXII} work.

  Any combination of characters is allowed if the variable name
  is enclosed in double quotation marks.  In this case
  backslashes and double quotation marks need to be escaped with
  backslashes (not that you actually should use them).
  Examples: @code{"foo bar"}, @code{"a-b-c"}, @code{"Horn 3"}.

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Dev mailing list
In reply to this post by Dev mailing list
On 2020/02/05 14:14:47, Dan Eble wrote:
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely
> File Documentation/notation/rhythms.itely (right):
>
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/rhythms.itely#newcode3325
> Documentation/notation/rhythms.itely:3325: bar number check may fail.
It is
> best to suppress MIDI output
> No.  Bar number checks are ignored by default when processing MIDI.
See
> https://sourceforge.net/p/testlilyissues/issues/5624/ .

Ok, I will remove it. Peter's report was based on 2.19.83.


https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Dev mailing list
In reply to this post by Dev mailing list
On 2020/02/05 14:51:03, lemzwerg wrote:
> A nit.
>
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely
> File Documentation/notation/input.itely (right):
>
>
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notation/input.itely#newcode464
> Documentation/notation/input.itely:464: escaped with backslashes.
> This is confusing.  'Alphabetic characters' and 'non-ASCII characters'
are not

> different sets but are overlapping.  What about
>
>   The name of a variable should not contain (ASCII) numbers,
>   underscores, dashes, or space characters.  All other
>   characters Unicode provides are allowed, for example Latin,
>   Greek, or Chinese.  In other words, variable names like
>   @code{HornIII} or @code{αβγXII} work.
>
>   Any combination of characters is allowed if the variable name
>   is enclosed in double quotation marks.  In this case
>   backslashes and double quotation marks need to be escaped with
>   backslashes (not that you actually should use them).
>   Examples: @code{"foo bar"}, @code{"a-b-c"}, @code{"Horn 3"}.

Thank you, Werner!
I tried to combine your suggestions with Peter's remarks in
https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg00265.html

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Dev mailing list
In reply to this post by Dev mailing list
An important nit to check...

Besides this, LGTM, thanks!


https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely#newcode464
Documentation/notation/input.itely:464: @code{αβγXII} or @code{Теноры}
work.
Not sure whether this works.  We are using Computer Modern fonts for
typesetting the PDF manuals; this font family comes with some (limited)
Greek support, but it doesn't contain glyphs for Russian...  Please
check the resulting PDFs to be sure!

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

ptoye

-------------------------
Thursday, February 6, 2020, 3:00:35 PM, you wrote:

> An important nit to check...

> Besides this, LGTM, thanks!


> https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely
> File Documentation/notation/input.itely (right):

> https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely#newcode464
> Documentation/notation/input.itely:464:
> @code{αβγXII} or @code{Теноры}
> work.
> Not sure whether this works.  We are using
> Computer Modern fonts for
> typesetting the PDF manuals; this font family
> comes with some (limited)
> Greek support, but it doesn't contain glyphs for Russian...  Please
> check the resulting PDFs to be sure!

I didn't know this. But check https://www.fontsquirrel.com/fonts/computer-modern which says that Computer Modern supports the Russian language (which I assume means that it has Cyrillic glyphs).

> https://codereview.appspot.com/579280043/
Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Dev mailing list
In reply to this post by Dev mailing list
On 2020/02/06 15:00:35, lemzwerg wrote:
> An important nit to check...
>
> Besides this, LGTM, thanks!
>
>
https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely
> File Documentation/notation/input.itely (right):
>
>
https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely#newcode464
> Documentation/notation/input.itely:464: @code{αβγXII} or @code{Теноры}
work.
> Not sure whether this works.  We are using Computer Modern fonts for
typesetting
> the PDF manuals; this font family comes with some (limited) Greek
support, but
> it doesn't contain glyphs for Russian...  Please check the resulting
PDFs to be
> sure!

You are right, Werner. Thanks for pointing this out.
Removed the cyrillic example.

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Thomas Morley-2
In reply to this post by Dev mailing list

https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely
File Documentation/learning/common-notation.itely (right):

https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely#newcode162
Documentation/learning/common-notation.itely:162: @notation{note names}
and @notation{accidentals},
Here I disagree.
From wikpedia https://en.wikipedia.org/wiki/Alteration
"In music, alteration is the use of a neighboring pitch in the chromatic
scale in place of its diatonic neighbor."
An _accidental_ is the printed ♯-sign or ♭-sign, etc, indicating the
alteration.
Thus "accidentals" is plain wrong here. Please keep "alterations"

Probably:
@notation{note names} and their @notation{alterations},

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

ptoye
In reply to this post by Dev mailing list
Thursday, February 6, 2020, 9:14:00 PM, you wrote:

> On 2020/02/06 15:00:35, lemzwerg wrote:
>> An important nit to check...
>>
>> Besides this, LGTM, thanks!
>>
>>
> https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely
>> File Documentation/notation/input.itely (right):
>>
>>
> https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely#newcode464
>> Documentation/notation/input.itely:464: @code{αβγXII} or @code{Теноры}
> work.
>> Not sure whether this works.  We are using Computer Modern fonts for
> typesetting
>> the PDF manuals; this font family comes with some (limited) Greek
> support, but
>> it doesn't contain glyphs for Russian...  Please check the resulting
> PDFs to be
>> sure!

> You are right, Werner. Thanks for pointing this out.
> Removed the cyrillic example.

> https://codereview.appspot.com/579280043/

Теноры
Very odd - I've just installed a CMU font and it's got all the Russian alphabet. See the line above which is in CMU Concrete! Are you sure that you've got all of the font installed?

All the best,

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Michael Käppler-2
In reply to this post by Thomas Morley-2
Am 06.02.2020 um 22:55 schrieb [hidden email]:

> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely
> File Documentation/learning/common-notation.itely (right):
>
> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely#newcode162
> Documentation/learning/common-notation.itely:162: @notation{note names}
> and @notation{accidentals},
> Here I disagree.
> >From wikpedia https://en.wikipedia.org/wiki/Alteration
> "In music, alteration is the use of a neighboring pitch in the chromatic
> scale in place of its diatonic neighbor."
> An _accidental_ is the printed ♯-sign or ♭-sign, etc, indicating the
> alteration.
> Thus "accidentals" is plain wrong here. Please keep "alterations"
That were my thoughts, too.
But I ascribe more importance to Peter's opinion (as a native speaker)
than to mine, so
it is difficult for me to decide now...
>
> Probably:
> @notation{note names} and their @notation{alterations},
>
> https://codereview.appspot.com/579280043/
>


Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Werner LEMBERG
In reply to this post by ptoye

> Теноры

> Very odd - I've just installed a CMU font and it's got all the
> Russian alphabet.

What exactly do you mean with 'installing'?  I'm talking about the
creation of PDF files using xelatex, using only standardized fonts
(this is, avoiding fonts that are accidentally present on your
system).

> See the line above which is in CMU Concrete!

???  I use Emacs to read my e-mail, and emacs is configured to use the
font 'DejaVu Sans Mono' on my GNU/Linux box.  This font contains
Cyrillic glyphs...

> Are you sure that you've got all of the font installed?

It seems there is a fundamental misunderstanding.  We want to
*restrict* the fonts used for creating the documentation to an exactly
defined set so that you get identical PDFs regardless on which
platform they are built.  By default, texinfo uses the 'Computer
Modern' (CM) family; for some additional glyphs the 'EC' and 'feym*'
font families get used.  None of those fonts contain Cyrillic glyphs.

Note that music snippets in the PDF are handled differently.


    Werner
Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

ptoye
-------------------------
Saturday, February 8, 2020, 5:03:15 AM, you wrote:


>> Теноры

>> Very odd - I've just installed a CMU font and it's got all the
>> Russian alphabet.

> What exactly do you mean with 'installing'?  I'm talking about the
> creation of PDF files using xelatex, using only standardized fonts
> (this is, avoiding fonts that are accidentally present on your
> system).

I thought that "install a font" meant "install a font". I'm on Windows, so it may have other meanings on other OSs.

>> See the line above which is in CMU Concrete!

> ???  I use Emacs to read my e-mail, and emacs
> is configured to use the
> font 'DejaVu Sans Mono' on my GNU/Linux box.  This font contains
> Cyrillic glyphs...

I composed that line in the email using CMU Concrete. Presumably your email client changes that.

>> Are you sure that you've got all of the font installed?

> It seems there is a fundamental
> misunderstanding.  We want to
> *restrict* the fonts used for creating the
> documentation to an exactly
> defined set so that you get identical PDFs regardless on which
> platform they are built.  By default, texinfo uses the 'Computer
> Modern' (CM) family; for some additional glyphs the 'EC' and 'feym*'
> font families get used.  None of those fonts
> contain Cyrillic glyphs.

OK, that's fine by me. I was confused as earlier emails referred to the font family, not the version of the font that are used in the documentation project, which you tell me is a subset.

> Note that music snippets in the PDF are handled differently.


>     Werner
Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Werner LEMBERG

>>> See the line above which is in CMU Concrete!
>
>> ???  I use Emacs to read my e-mail, and emacs is configured to use
>> the font 'DejaVu Sans Mono' on my GNU/Linux box.  This font
>> contains Cyrillic glyphs...
>
> I composed that line in the email using CMU Concrete.  Presumably
> your email client changes that.

You have (correctly) sent a plain text e-mail, which doesn't preserve
any font information...

>> None of those fonts contain Cyrillic glyphs.
>
> OK, that's fine by me. I was confused as earlier emails referred to
> the font family,

Just for clarification.  A font family 'Foo' traditionally consists of
'Foo Regular', 'Foo Bold', 'Foo Italic', and 'Foo Bold Italic'.  Some
font families contain *much* more series – Computer Modern (CM) is
such an example[1] – others contain only a single one.  The PDFs as
produced by texinfo use CM (plus some other, additional fonts, as
mentioned in a previous e-mail).

Note that 'CMU Concrete' is a completely different thing; while based
on CM, it is not part of it.  With 'part of it' I mean that
historically it wasn't part of the fonts that TeX has started many
years ago.

> not the version of the font that are used in the documentation
> project, which you tell me is a subset.

What I'm talking about has nothing to do with font versions.


    Werner


[1] To be more precise, CM is a collection of various font families.
Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

ptoye

Saturday, February 8, 2020, 6:07:23 PM, you wrote:


>>>> See the line above which is in CMU Concrete!
>>
>>> ???  I use Emacs to read my e-mail, and emacs is configured to use
>>> the font 'DejaVu Sans Mono' on my GNU/Linux box.  This font
>>> contains Cyrillic glyphs...
>>
>> I composed that line in the email using CMU Concrete.  Presumably
>> your email client changes that.

> You have (correctly) sent a plain text e-mail, which doesn't preserve
> any font information...

Odd - I thought I'd sent it as text + HTML precisely to preserve the font! Oh well.

>>> None of those fonts contain Cyrillic glyphs.
>>
>> OK, that's fine by me. I was confused as earlier emails referred to
>> the font family,

> Just for clarification.  A font family 'Foo'
> traditionally consists of
> 'Foo Regular', 'Foo Bold', 'Foo Italic', and
> 'Foo Bold Italic'.  Some
> font families contain *much* more series – Computer Modern (CM) is
> such an example[1] – others contain only a
> single one.  The PDFs as
> produced by texinfo use CM (plus some other, additional fonts, as
> mentioned in a previous e-mail).

> Note that 'CMU Concrete' is a completely
> different thing; while based
> on CM, it is not part of it.  With 'part of it' I mean that
> historically it wasn't part of the fonts that TeX has started many
> years ago.

I know nothing about the history of TeX or fonts. Thanks for the info.

>> not the version of the font that are used in the documentation
>> project, which you tell me is a subset.

> What I'm talking about has nothing to do with font versions.

I suggest that we now close this discussion as I was completely wrong in my understanding of CM fonts, their glyph set and their relation with LilyPond documentation.


>     Werner


> [1] To be more precise, CM is a collection of various font families.
Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Thomas Morley-2
In reply to this post by Dev mailing list
I'd love to see more opinions about comments #12 and #14.
Otherwise I'd object to this part of the patch

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

David Kastrup
In reply to this post by Dev mailing list
On 2020/02/09 12:33:23, thomasmorley651 wrote:
> I'd love to see more opinions about comments #12 and #14.
> Otherwise I'd object to this part of the patch

I agree with the objection raised in #12

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Dev mailing list
In reply to this post by Dev mailing list
> > I'd love to see more opinions about comments #12 and #14.
> > Otherwise I'd object to this part of the patch
>
> I agree with the objection raised in #12

+1

https://codereview.appspot.com/579280043/

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

ptoye
In reply to this post by Michael Käppler-2
-------------------------
Friday, February 7, 2020, 8:39:36 PM, you wrote:

> Am 06.02.2020 um 22:55 schrieb
> [hidden email]:
>> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely
>> File Documentation/learning/common-notation.itely (right):
>>
>> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely#newcode162
>> Documentation/learning/common-notation.itely:162: @notation{note names}
>> and @notation{accidentals},
>> Here I disagree.
>> >From wikpedia https://en.wikipedia.org/wiki/Alteration
>> "In music, alteration is the use of a neighboring pitch in the chromatic
>> scale in place of its diatonic neighbor."
>> An _accidental_ is the printed ♯-sign or ♭-sign, etc, indicating the
>> alteration.
>> Thus "accidentals" is plain wrong here. Please keep "alterations"
> That were my thoughts, too.
> But I ascribe more importance to Peter's
> opinion (as a native speaker)
> than to mine, so
> it is difficult for me to decide now...

Is 'alteration' an American English term? I've never heard it in British English. But our languages diverge... Are there any US speakers in this discussion? Wikipedia tends to have a US bias IMHO.

'Alteration' does not appear at all as a heading in the Oxford Companion to Music. However, 'accidental' is defined as a 'sign used in musical notation', which rather leaves open the question of how to describe a change to a note in the abstract. Something I've not really thought about. Hmmm...

But this leaves me very unhappy about NR 1.1.1.4, which is called 'accidentals' when the first sentence is describing alterations: cis in D major is an alteration, not an accidental.

>>
>> Probably:
>> @notation{note names} and their @notation{alterations},
>>
>> https://codereview.appspot.com/579280043/
>>

Reply | Threaded
Open this post in threaded view
|

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaeppler@googlemail.com)

Graham King-3

> On 9 Feb 2020, at 13:23, [hidden email] wrote:
>
> -------------------------
> Friday, February 7, 2020, 8:39:36 PM, you wrote:
>
>> Am 06.02.2020 um 22:55 schrieb
>> [hidden email]:
>>> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely
>>> File Documentation/learning/common-notation.itely (right):
>>>
>>> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely#newcode162
>>> Documentation/learning/common-notation.itely:162: @notation{note names}
>>> and @notation{accidentals},
>>> Here I disagree.
>>>> From wikpedia https://en.wikipedia.org/wiki/Alteration
>>> "In music, alteration is the use of a neighboring pitch in the chromatic
>>> scale in place of its diatonic neighbor."
>>> An _accidental_ is the printed ♯-sign or ♭-sign, etc, indicating the
>>> alteration.
>>> Thus "accidentals" is plain wrong here. Please keep "alterations"
>> That were my thoughts, too.
>> But I ascribe more importance to Peter's
>> opinion (as a native speaker)
>> than to mine, so
>> it is difficult for me to decide now...
>
> Is 'alteration' an American English term? I've never heard it in British English. But our languages diverge... Are there any US speakers in this discussion? Wikipedia tends to have a US bias IMHO.

+1, with respect to accidentals.  I'm an en_GB speaker.
>
> 'Alteration' does not appear at all as a heading in the Oxford Companion to Music. However, 'accidental' is defined as a 'sign used in musical notation', which rather leaves open the question of how to describe a change to a note in the abstract. Something I've not really thought about. Hmmm...

From a speed-reading of Gould, it appears that she uses the verb "alter" and the adjective "altered", but _not_ the noun "alteration" in this context.

It is worth noting that "alteration" has a very specific and well-established meaning in early music.  This meaning has nothing whatsoever to do with pitch.  I've, ahem, altered that Wikipedia disambiguation page accordingly.

The original section header in the LM seemed fine to me, but if it needs to change, how about "Note names and use of accidentals" ?  It seems to me that a user wanting to use the document to figure out how to specify an accidental, is quite likely to search for that word.

>
> But this leaves me very unhappy about NR 1.1.1.4, which is called 'accidentals' when the first sentence is describing alterations: cis in D major is an alteration, not an accidental.
>
>>>
>>> Probably:
>>> @notation{note names} and their @notation{alterations},
>>>
>>> https://codereview.appspot.com/579280043/


12