Issue 579280043: Doc: Some miscellaneous suggestions from Peter Toye
|
Created:
4 years, 2 months ago by michael.kaeppler Modified:
4 years, 2 months ago Reviewers:
xmichael-k, wl, carl.d.sorensen, lemzwerg, lilypond, Dan Eble, dak, thomasmorley651, Jean-Charles CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionDoc: 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.
Patch Set 1 #
Total comments: 2
Patch Set 2 : Remove note about MIDI and bar number checks, combine Werner's and Peter's notes on variable names #Patch Set 3 : Further adjustments in consequence of Peter's comments in https://lists.gnu.org/archive/html/lilypo… #
Total comments: 1
Patch Set 4 : Remove non-working cyrillic example #
Total comments: 1
Patch Set 5 : Explain note name parts, remove questionable occurrence of term 'accidental' #
Total comments: 1
Patch Set 6 : Use singular form for index entries #
MessagesTotal messages: 40
Sign in to reply to this message.
https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... File Documentation/notation/rhythms.itely (right): https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... 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/ .
Sign in to reply to this message.
A nit. https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... File Documentation/notation/input.itely (right): https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... 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"}.
Sign in to reply to this message.
On 2020/02/05 14:14:47, Dan Eble wrote: > https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... > File Documentation/notation/rhythms.itely (right): > > https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... > 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.
Sign in to reply to this message.
On 2020/02/05 14:51:03, lemzwerg wrote: > A nit. > > https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... > File Documentation/notation/input.itely (right): > > https://codereview.appspot.com/579280043/diff/579290043/Documentation/notatio... > 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
Sign in to reply to this message.
Remove note about MIDI and bar number checks, combine Werner's and Peter's notes on variable names
Sign in to reply to this message.
Further adjustments in consequence of Peter's comments in https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg00265.html
Sign in to reply to this message.
An important nit to check... Besides this, LGTM, thanks! https://codereview.appspot.com/579280043/diff/567170044/Documentation/notatio... File Documentation/notation/input.itely (right): https://codereview.appspot.com/579280043/diff/567170044/Documentation/notatio... 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!
Sign in to reply to this message.
------------------------- 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/notatio... > File Documentation/notation/input.itely (right): > https://codereview.appspot.com/579280043/diff/567170044/Documentation/notatio... > 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/
Sign in to reply to this message.
Remove non-working cyrillic example
Sign in to reply to this message.
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/notatio... > File Documentation/notation/input.itely (right): > > https://codereview.appspot.com/579280043/diff/567170044/Documentation/notatio... > 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.
Sign in to reply to this message.
https://codereview.appspot.com/579280043/diff/563480043/Documentation/learnin... File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/579280043/diff/563480043/Documentation/learnin... 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},
Sign in to reply to this message.
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/notatio... >> File Documentation/notation/input.itely (right): >> >> > https://codereview.appspot.com/579280043/diff/567170044/Documentation/notatio... >> 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
Sign in to reply to this message.
Am 06.02.2020 um 22:55 schrieb thomasmorley65@gmail.com: > https://codereview.appspot.com/579280043/diff/563480043/Documentation/learnin... > File Documentation/learning/common-notation.itely (right): > > https://codereview.appspot.com/579280043/diff/563480043/Documentation/learnin... > 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/ >
Sign in to reply to this message.
> Теноры
> 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
Sign in to reply to this message.
------------------------- 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
Sign in to reply to this message.
>>> 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.
Sign in to reply to this message.
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.
Sign in to reply to this message.
I'd love to see more opinions about comments #12 and #14. Otherwise I'd object to this part of the patch
Sign in to reply to this message.
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
Sign in to reply to this message.
> > 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
Sign in to reply to this message.
------------------------- Friday, February 7, 2020, 8:39:36 PM, you wrote: > Am 06.02.2020 um 22:55 schrieb > thomasmorley65@gmail.com: >> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learnin... >> File Documentation/learning/common-notation.itely (right): >> >> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learnin... >> 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/ >>
Sign in to reply to this message.
I'm a native US speaker. The following is my opinion. Alteration is a change in pitch from the base pitch. Base pitch is C, alteration is sharp, actual pitch is C#. Accidental is a change in pitch from the standard scale pitch. As mentioned by Peter, C# in a D major scale is not an accidental, although it is an alteration. I would totally support cleaning up this in NR 1.1.1 Accidentals (Note -- we don't have 1.1.1.4 in the NR; the lowest level of headings is not numbered). Carl
Sign in to reply to this message.
Sunday, February 9, 2020, 2:16:50 PM, you wrote: > I'm a native US speaker. The following is my opinion. > Alteration is a change in pitch from the base > pitch. Base pitch is C, > alteration is sharp, actual pitch is C#. > Accidental is a change in pitch from the > standard scale pitch. As > mentioned by Peter, C# in a D major scale is > not an accidental, although > it is an alteration. Surely "standard scale pitch or previously altered pitch". In D major: "cis c cis" the first note is an alteration but not an accidental, the second is an accidental but not an alteration, the third is both. Now I'm really splitting hairs. I'm beginning to think that this is all getting too theologial. I'm a practising musician, not a theorist, and I raised the point as I'd never heard of 'alteration' used in this rather technical sense. If people are happy with the distinction let's just keep it and I withdraw my suggestion. > I would totally support cleaning up this in NR 1.1.1 Accidentals (Note > -- we don't have 1.1.1.4 in the NR; the lowest > level of headings is not > numbered). I agree with the last sentence, but it was the easiest way of describing the subsubsubsection in the time available. > Carl > https://codereview.appspot.com/579280043/ Peter
Sign in to reply to this message.
On 2020/02/09 15:32:14, lilypond_ptoye.com wrote: > Sunday, February 9, 2020, 2:16:50 PM, you wrote: > > > I'm a native US speaker. The following is my opinion. > > > Alteration is a change in pitch from the base > > pitch. Base pitch is C, > > alteration is sharp, actual pitch is C#. > > > Accidental is a change in pitch from the > > standard scale pitch. As > > mentioned by Peter, C# in a D major scale is > > not an accidental, although > > it is an alteration. > > Surely "standard scale pitch or previously altered pitch". In D major: "cis c > cis" the first note is an alteration but not an accidental, the second is an > accidental but not an alteration, the third is both. Now I'm really splitting > hairs. > > I'm beginning to think that this is all getting too theologial. I'm a practising > musician, not a theorist, and I raised the point as I'd never heard of > 'alteration' used in this rather technical sense. If people are happy with the > distinction let's just keep it and I withdraw my suggestion. I guess, strictly speaking, in lilypond we input a pitch that consists of a base pitch, an optional alteration, and an octave (which in relative music is most often omitted to accept the default octave). Then the display (or lack thereof) of an accidental is governed by the accidental display rules and any overrides we add. Interestingly, as you correctly pointed out, a natural can be an accidental (overriding a sharp or flat in the key signature). And we don't add anything to the input stream to indicate a natural. I can see that this is all potentially a bit confusing, but I think it's captured pretty easily by example. So we should probably just make sure we don't say things that are blatantly false. Carl
Sign in to reply to this message.
On 2020/02/09 15:32:14, lilypond_ptoye.com wrote: > Surely "standard scale pitch or previously altered pitch". In D major: "cis c > cis" the first note is an alteration but not an accidental, the second is an > accidental but not an alteration, the third is both. Now I'm really splitting > hairs. I read this as "In D major the note c _is_ an accidental". Or did you mean _has_ an accidental? > I'm beginning to think that this is all getting too theologial. I'm a practising > musician, not a theorist, and I raised the point as I'd never heard of > 'alteration' used in this rather technical sense. If people are happy with the > distinction let's just keep it and I withdraw my suggestion. Wait. If we try to improve the docs we need to care about best wordings, so that people speaking different language and with different musical education understand what we want to express. Furthermore we need to explain how we do things in LilyPond. Look at: mus = { \key d \major cis'4 } #(display-scheme-music (car (music-pitches mus))) #(display-scheme-music (ly:pitch-alteration (car (music-pitches mus)))) => (ly:make-pitch 0 0 1/2) 1/2 First how the cis is seen in LilyPond, second the alteration. (ofcourse no Accidental is printed in pdf) Do the same with note c and you see no alteration, i.e. 0 (ofcourse an Accidental is printed) Do similar with c and cis (and you see the alteration for cis again and an accidental for cis is printed) This is absolutely inline with my thinking. Though, c itself in D major can't be called an accidental. In my book an Accidental is always the printed ♯-sign or ♭-sign or natural or double-sharp/flat, nothing else, never the note itself. Furthermore in german we have the distinction between "Vorzeichen" and "Versetzungszeichen", in lilypond that would be the accidental-grobs from KeySignature and the additional "on the fly" Accidentals in music. I think it's worth the discussion.
Sign in to reply to this message.
Sunday, February 9, 2020, 4:15:53 PM, you wrote: > On 2020/02/09 15:32:14, lilypond_ptoye.com wrote: >> Surely "standard scale pitch or previously altered pitch". In D major: > "cis c >> cis" the first note is an alteration but not an accidental, the second > is an >> accidental but not an alteration, the third is both. Now I'm really > splitting >> hairs. > I read this as "In D major the note c _is_ an accidental". > Or did you mean _has_ an accidental? Er, yes. >> I'm beginning to think that this is all getting too theologial. I'm a > practising >> musician, not a theorist, and I raised the point as I'd never heard of >> 'alteration' used in this rather technical sense. If people are happy > with the >> distinction let's just keep it and I withdraw my suggestion. > Wait. If we try to improve the docs we need to > care about best wordings, > so that people speaking different language and with different musical > education understand what we want to express. > Furthermore we need to explain how we do things in LilyPond. > Look at: > mus = { \key d \major cis'4 } > #(display-scheme-music (car (music-pitches mus))) > #(display-scheme-music (ly:pitch-alteration > (car (music-pitches mus)))) =>> > (ly:make-pitch 0 0 1/2) > 1/2 > First how the cis is seen in LilyPond, second > the alteration. (ofcourse > no Accidental is printed in pdf) > Do the same with note c and you see no > alteration, i.e. 0 (ofcourse an > Accidental is printed) > Do similar with c and cis (and you see the > alteration for cis again and > an accidental for cis is printed) > This is absolutely inline with my thinking. > Though, c itself in D major can't be called an accidental. > In my book an Accidental is always the printed ♯-sign or ♭-sign or > natural or double-sharp/flat, nothing else, never the note itself. > Furthermore in german we have the distinction > between "Vorzeichen" and > "Versetzungszeichen", in lilypond that would be the accidental-grobs > from KeySignature and the additional "on the > fly" Accidentals in music. > I think it's worth the discussion. Thanks - I'm not a German speaker so was totally unaware of the distinction. But my original point was that I've never heard of 'alteration' being used in a technical sense for what I suppose could be called the 'black notes'. Now - there's an idea for the section heading :) Peter > https://codereview.appspot.com/579280043/
Sign in to reply to this message.
On 2020/02/09 14:16:51, Carl wrote: > I'm a native US speaker. The following is my opinion. > > Alteration is a change in pitch from the base pitch. Base pitch is C, > alteration is sharp, actual pitch is C#. > > Accidental is a change in pitch from the standard scale pitch. As mentioned by > Peter, C# in a D major scale is not an accidental, although it is an alteration. From my point of view a note can never _be_ an accidental, it can only _have_ an accidental attached to it. But maybe this is a misunderstanding of the English terms... > > I would totally support cleaning up this in NR 1.1.1 Accidentals (Note -- we > don't have 1.1.1.4 in the NR; the lowest level of headings is not numbered). It seems to me that this section does mix up "Entering pitches" and "Displaying pitches". The question whether a note is altered is decided within input. The question whether this note will show up with an accidental is decided during typesetting and depends on the key signature, the accidental-style and so on. It is difficult to split up this topics clearly, however, because any example of pitch entry will include displaying the pitches, too. > > Carl
Sign in to reply to this message.
On 2020/02/09 16:15:53, thomasmorley651 wrote: > On 2020/02/09 15:32:14, http://lilypond_ptoye.com wrote: > > > Surely "standard scale pitch or previously altered pitch". In D major: "cis c > > cis" the first note is an alteration but not an accidental, the second is an > > accidental but not an alteration, the third is both. Now I'm really splitting > > hairs. > > I read this as "In D major the note c _is_ an accidental". > Or did you mean _has_ an accidental? > > > I'm beginning to think that this is all getting too theologial. I'm a > practising > > musician, not a theorist, and I raised the point as I'd never heard of > > 'alteration' used in this rather technical sense. If people are happy with the > > distinction let's just keep it and I withdraw my suggestion. > > Wait. If we try to improve the docs we need to care about best wordings, so that > people speaking different language and with different musical education > understand what we want to express. +1 > > Furthermore we need to explain how we do things in LilyPond. > Look at: > mus = { \key d \major cis'4 } > #(display-scheme-music (car (music-pitches mus))) > #(display-scheme-music (ly:pitch-alteration (car (music-pitches mus)))) > => > (ly:make-pitch 0 0 1/2) > 1/2 > > First how the cis is seen in LilyPond, second the alteration. (ofcourse no > Accidental is printed in pdf) > Do the same with note c and you see no alteration, i.e. 0 (ofcourse an > Accidental is printed) > Do similar with c and cis (and you see the alteration for cis again and an > accidental for cis is printed) However, I think that the description of LilyPond's internal pitch data structure is not helpful for this (pretty introductory) part of the docs. The longer I think about it, the more I'm unsure if the term "alteration" makes sense for a basic understanding how pitches are entered in LilyPond. If I think about a, lets say D major scale, I would not say that the pitch 'fis' is an 'altered' note, though it is stored that way in the data structure. 'Alteration' for me always refers to some 'unaltered' form. Our pitch naming system with a 'nucleus' (e.g. 'f') and some suffices (e.g. '-is') OTOH supports the conclusion, that a pitch consists of some base, diatonic pitch and possibles alterations. It is also conclusive, though, that LilyPond uses the C major scale as the base for its pitch structure. > > This is absolutely inline with my thinking. > Though, c itself in D major can't be called an accidental. > In my book an Accidental is always the printed ♯-sign or ♭-sign or natural or > double-sharp/flat, nothing else, never the note itself. +1 > > Furthermore in german we have the distinction between "Vorzeichen" and > "Versetzungszeichen", in lilypond that would be the accidental-grobs from > KeySignature and the additional "on the fly" Accidentals in music. Can you cite sources for this? Being also a practising german musician I've never used the term "Versetzungszeichen" and I thought it to be synonymous with "Vorzeichen". What I know and (rarely) use is the term "Generalvorzeichen". These would be the KeySignature accidentals.
Sign in to reply to this message.
On 2020/02/10 22:00:04, michael.kaeppler wrote: > However, I think that the description of LilyPond's internal pitch data > structure > is not helpful for this (pretty introductory) part of the docs. Agreed. > The longer I think about it, the more I'm unsure if the term "alteration" makes > sense for a basic understanding how pitches are entered in LilyPond. It's an alteration of the basic note name, not of in-scale notes. It corresponds to the spelling of the input. I am not going to meddle with the rest of the discussion.
Sign in to reply to this message.
Monday, February 10, 2020, 9:40:53 PM, you wrote: > On 2020/02/09 14:16:51, Carl wrote: >> I'm a native US speaker. The following is my opinion. >> >> Alteration is a change in pitch from the base pitch. Base pitch is C, >> alteration is sharp, actual pitch is C#. >> >> Accidental is a change in pitch from the standard scale pitch. As > mentioned by >> Peter, C# in a D major scale is not an accidental, although it is an > alteration. > From my point of view a note can never _be_ an accidental, it can > only _have_ an accidental attached to it. But maybe this is a > misunderstanding of the English terms... No- you're right and I'd already replied to Carl Sorenson's correction here. It doesn't affect the argument one jot, though. >> >> I would totally support cleaning up this in NR 1.1.1 Accidentals (Note > -- we >> don't have 1.1.1.4 in the NR; the lowest level of headings is not > numbered). > It seems to me that this section does mix up "Entering pitches" and > "Displaying pitches". > The question whether a note is altered is decided within input. > The question whether this note will show up with an accidental is > decided during > typesetting and depends on the key signature, > the accidental-style and > so on. > It is difficult to split up this topics > clearly, however, because > any example of pitch entry will include > displaying the pitches, too. >> >> Carl > https://codereview.appspot.com/579280043/
Sign in to reply to this message.
Explain note name parts, remove questionable occurrence of term 'accidental'
Sign in to reply to this message.
Have a look at Documentation/HOWTO.index https://codereview.appspot.com/579280043/diff/563510048/Documentation/notatio... File Documentation/notation/input.itely (right): https://codereview.appspot.com/579280043/diff/563510048/Documentation/notatio... Documentation/notation/input.itely:880: @cindex footers, page Index them as singular
Sign in to reply to this message.
Monday, February 10, 2020, 10:00:03 PM, you wrote: > On 2020/02/09 16:15:53, thomasmorley651 wrote: >> On 2020/02/09 15:32:14, http://lilypond_ptoye.com wrote: >> >> > Surely "standard scale pitch or previously altered pitch". In D > major: "cis c >> > cis" the first note is an alteration but not an accidental, the > second is an >> > accidental but not an alteration, the third is both. Now I'm really > splitting >> > hairs. >> >> I read this as "In D major the note c _is_ an accidental". >> Or did you mean _has_ an accidental? >> >> > I'm beginning to think that this is all getting too theologial. I'm > a >> practising musician, not a theorist, and I raised the point as I'd never heard of >> > 'alteration' used in this rather technical sense. If people are > happy with the >> > distinction let's just keep it and I withdraw my suggestion. >> >> Wait. If we try to improve the docs we need to care about best > wordings, so that >> people speaking different language and with different musical > education >> understand what we want to express. > +1 >> >> Furthermore we need to explain how we do things in LilyPond. >> Look at: >> mus = { \key d \major cis'4 } >> #(display-scheme-music (car (music-pitches mus))) >> #(display-scheme-music (ly:pitch-alteration (car (music-pitches > mus)))) >> => >> (ly:make-pitch 0 0 1/2) >> 1/2 >> >> First how the cis is seen in LilyPond, second the alteration. > (ofcourse no >> Accidental is printed in pdf) >> Do the same with note c and you see no alteration, i.e. 0 (ofcourse an >> Accidental is printed) >> Do similar with c and cis (and you see the alteration for cis again > and an >> accidental for cis is printed) > However, I think that the description of > LilyPond's internal pitch data > structure > is not helpful for this (pretty introductory) part of the docs. > The longer I think about it, the more I'm unsure if the term > "alteration" makes > sense for a basic understanding how pitches are entered in LilyPond. > If I think about a, lets say D major scale, I would not say that the > pitch 'fis' is an 'altered' note, though it is stored that way in the > data structure. 'Alteration' for me always > refers to some 'unaltered' > form. > Our pitch naming system with a 'nucleus' (e.g. 'f') and some suffices > (e.g. '-is') OTOH supports the conclusion, that a pitch consists of > some base, diatonic pitch and possibles alterations. > It is also conclusive, though, that LilyPond > uses the C major scale as the base for its pitch structure. The nub of the question is the difference between how a musician thinks of a note name and how it get written/engraved. If I'm working on paper I don't think of 'C sharp' as 'C' modified by 'sharp'. I think of it as a single entity. It's about 70 years since I learnt musical notation, and that was in the English system on the piano, where the white notes have names which are letters, and the black notes have what I was told (somewhat incorrectly) were called 'accidentals'. I think key signatures came later. I discovered about German notation using 'B' for the note one diatonic tone below C much later - so my previous comment about the 'black notes' doesn't work. I've just had a very quick look at musicXML and I have to admit that this seems to take the same view as LilyPond - note plus alteration - and they even use the tag <alter> for the latter. So the use of 'alteration' as a technical term does at least have some justification. But my concern was, and still is, that a newbie coming to Lilypond and needing to check up on exactly how to engrave a C sharp won't find much help in the section headings in the LM. I speak from experience form my early fumblings with LP. We shouldn't discourage new users by hiding what are, in practical terms, the easy bits. >> >> This is absolutely inline with my thinking. >> Though, c itself in D major can't be called an accidental. >> In my book an Accidental is always the printed ♯-sign or ♭-sign or > natural or >> double-sharp/flat, nothing else, never the note itself. > +1 Agreed, it's a note with and accidental natural sign. I've already covered this in other replies here. >> >> Furthermore in german we have the distinction between "Vorzeichen" and >> "Versetzungszeichen", in lilypond that would be the accidental-grobs > from >> KeySignature and the additional "on the fly" Accidentals in music. > Can you cite sources for this? Being also a > practising german musician > I've never used the term "Versetzungszeichen" and I thought it to > be synonymous with "Vorzeichen". What I know and (rarely) use is > the term "Generalvorzeichen". These would be the KeySignature > accidentals. > https://codereview.appspot.com/579280043/
Sign in to reply to this message.
Use singular form for index entries
Sign in to reply to this message.
On 2020/02/11 11:04:59, Jean-Charles wrote: > Have a look at Documentation/HOWTO.index > > https://codereview.appspot.com/579280043/diff/563510048/Documentation/notatio... > File Documentation/notation/input.itely (right): > > https://codereview.appspot.com/579280043/diff/563510048/Documentation/notatio... > Documentation/notation/input.itely:880: @cindex footers, page > Index them as singular Thanks for pointing me to the HOWTO. Done.
Sign in to reply to this message.
On 2020/02/11 11:22:40, lilypond_ptoye.com wrote: > Monday, February 10, 2020, 10:00:03 PM, you wrote: > > > On 2020/02/09 16:15:53, thomasmorley651 wrote: > >> On 2020/02/09 15:32:14, http://lilypond_ptoye.com wrote: > >> > >> > Surely "standard scale pitch or previously altered pitch". In D > > major: "cis c > >> > cis" the first note is an alteration but not an accidental, the > > second is an > >> > accidental but not an alteration, the third is both. Now I'm really > > splitting > >> > hairs. > >> > >> I read this as "In D major the note c _is_ an accidental". > >> Or did you mean _has_ an accidental? > >> > >> > I'm beginning to think that this is all getting too theologial. I'm > > a > >> practising musician, not a theorist, and I raised the point as I'd never > heard of > >> > 'alteration' used in this rather technical sense. If people are > > happy with the > >> > distinction let's just keep it and I withdraw my suggestion. > >> > >> Wait. If we try to improve the docs we need to care about best > > wordings, so that > >> people speaking different language and with different musical > > education > >> understand what we want to express. > > > +1 > > >> > >> Furthermore we need to explain how we do things in LilyPond. > >> Look at: > >> mus = { \key d \major cis'4 } > >> #(display-scheme-music (car (music-pitches mus))) > >> #(display-scheme-music (ly:pitch-alteration (car (music-pitches > > mus)))) > >> => > >> (ly:make-pitch 0 0 1/2) > >> 1/2 > >> > >> First how the cis is seen in LilyPond, second the alteration. > > (ofcourse no > >> Accidental is printed in pdf) > >> Do the same with note c and you see no alteration, i.e. 0 (ofcourse an > >> Accidental is printed) > >> Do similar with c and cis (and you see the alteration for cis again > > and an > >> accidental for cis is printed) > > > However, I think that the description of > > LilyPond's internal pitch data > > structure > > is not helpful for this (pretty introductory) part of the docs. > > The longer I think about it, the more I'm unsure if the term > > "alteration" makes > > sense for a basic understanding how pitches are entered in LilyPond. > > If I think about a, lets say D major scale, I would not say that the > > pitch 'fis' is an 'altered' note, though it is stored that way in the > > data structure. 'Alteration' for me always > > refers to some 'unaltered' > > form. > > Our pitch naming system with a 'nucleus' (e.g. 'f') and some suffices > > (e.g. '-is') OTOH supports the conclusion, that a pitch consists of > > some base, diatonic pitch and possibles alterations. > > It is also conclusive, though, that LilyPond > > uses the C major scale as the base for its pitch structure. > > The nub of the question is the difference between how a musician thinks of a > note name and how it get written/engraved. If I'm working on paper I don't think > of 'C sharp' as 'C' modified by 'sharp'. I think of it as a single entity. It's > about 70 years since I learnt musical notation, and that was in the English > system on the piano, where the white notes have names which are letters, and the > black notes have what I was told (somewhat incorrectly) were called > 'accidentals'. I think key signatures came later. I discovered about German > notation using 'B' for the note one diatonic tone below C much later - so my > previous comment about the 'black notes' doesn't work. I fully agree with this point. I think we have to distinguish the 'normal', colloquial use of the term 'note name' (which refers to the whole note name as an entity) from the internal data structure that uses the term 'note name' for the diatonic nucleus. (As Harm pointed out in #26) There is even a function, called 'ly:pitch-notename' that (IIRC) does not return a string like 'fis' as one could think, but an integer refering to the steps of the default scale. I would propose to use the term 'note name' in the introductory docs only in the former sense. > > I've just had a very quick look at musicXML and I have to admit that this seems > to take the same view as LilyPond - note plus alteration - and they even use the > tag <alter> for the latter. So the use of 'alteration' as a technical term does > at least have some justification. > > But my concern was, and still is, that a newbie coming to Lilypond and needing > to check up on exactly how to engrave a C sharp won't find much help in the > section headings in the LM. I speak from experience form my early fumblings with > LP. We shouldn't discourage new users by hiding what are, in practical terms, > the easy bits. Would it help if we used 'Pitch entry' or 'Entering pitches' for the section in LM 2.1.2, instead of 'Pitch alterations'? This would involve changing of cross-references, though.
Sign in to reply to this message.
Tuesday, February 11, 2020, 11:59:18 AM, you wrote: > On 2020/02/11 11:22:40, lilypond_ptoye.com wrote: >> Monday, February 10, 2020, 10:00:03 PM, you wrote: >> >> > On 2020/02/09 16:15:53, thomasmorley651 wrote: >> >> On 2020/02/09 15:32:14, http://lilypond_ptoye.com wrote: >> >> >> >> > Surely "standard scale pitch or previously altered pitch". In D >> > major: "cis c >> >> > cis" the first note is an alteration but not an accidental, the >> > second is an >> >> > accidental but not an alteration, the third is both. Now I'm > really >> > splitting >> >> > hairs. >> >> >> >> I read this as "In D major the note c _is_ an accidental". >> >> Or did you mean _has_ an accidental? >> >> >> >> > I'm beginning to think that this is all getting too theologial. > I'm >> > a >> >> practising musician, not a theorist, and I raised the point as I'd > never >> heard of >> >> > 'alteration' used in this rather technical sense. If people are >> > happy with the >> >> > distinction let's just keep it and I withdraw my suggestion. >> >> >> >> Wait. If we try to improve the docs we need to care about best >> > wordings, so that >> >> people speaking different language and with different musical >> > education >> >> understand what we want to express. >> >> > +1 >> >> >> >> >> Furthermore we need to explain how we do things in LilyPond. >> >> Look at: >> >> mus = { \key d \major cis'4 } >> >> #(display-scheme-music (car (music-pitches mus))) >> >> #(display-scheme-music (ly:pitch-alteration (car (music-pitches >> > mus)))) >> >> => >> >> (ly:make-pitch 0 0 1/2) >> >> 1/2 >> >> >> >> First how the cis is seen in LilyPond, second the alteration. >> > (ofcourse no >> >> Accidental is printed in pdf) >> >> Do the same with note c and you see no alteration, i.e. 0 (ofcourse > an >> >> Accidental is printed) >> >> Do similar with c and cis (and you see the alteration for cis again >> > and an >> >> accidental for cis is printed) >> >> > However, I think that the description of >> > LilyPond's internal pitch data >> > structure >> > is not helpful for this (pretty introductory) part of the docs. >> > The longer I think about it, the more I'm unsure if the term >> > "alteration" makes >> > sense for a basic understanding how pitches are entered in LilyPond. >> > If I think about a, lets say D major scale, I would not say that the >> > pitch 'fis' is an 'altered' note, though it is stored that way in > the >> > data structure. 'Alteration' for me always >> > refers to some 'unaltered' >> > form. >> > Our pitch naming system with a 'nucleus' (e.g. 'f') and some > suffices >> > (e.g. '-is') OTOH supports the conclusion, that a pitch consists of >> > some base, diatonic pitch and possibles alterations. >> > It is also conclusive, though, that LilyPond >> > uses the C major scale as the base for its pitch structure. >> >> The nub of the question is the difference between how a musician > thinks of a >> note name and how it get written/engraved. If I'm working on paper I > don't think >> of 'C sharp' as 'C' modified by 'sharp'. I think of it as a single > entity. It's >> about 70 years since I learnt musical notation, and that was in the > English >> system on the piano, where the white notes have names which are > letters, and the >> black notes have what I was told (somewhat incorrectly) were called >> 'accidentals'. I think key signatures came later. I discovered about > German >> notation using 'B' for the note one diatonic tone below C much later - > so my >> previous comment about the 'black notes' doesn't work. > I fully agree with this point. I think we have to distinguish > the 'normal', colloquial use of the term 'note name' (which > refers to the whole note name as an entity) from the internal > data structure that uses the term 'note name' for > the diatonic nucleus. (As Harm pointed out in #26) > There is even a function, called 'ly:pitch-notename' > that (IIRC) does not return a string like 'fis' as one could > think, but an integer refering to the steps of the > default scale. > I would propose to use the term 'note name' in the > introductory docs only in the former sense. +1 Keep LP internals well away from the LM. >> >> I've just had a very quick look at musicXML and I have to admit that > this seems >> to take the same view as LilyPond - note plus alteration - and they > even use the >> tag <alter> for the latter. So the use of 'alteration' as a technical > term does >> at least have some justification. >> >> But my concern was, and still is, that a newbie coming to Lilypond and > needing >> to check up on exactly how to engrave a C sharp won't find much help > in the >> section headings in the LM. I speak from experience form my early > fumblings with >> LP. We shouldn't discourage new users by hiding what are, in practical > terms, >> the easy bits. > Would it help if we used 'Pitch entry' or > 'Entering pitches' for the > section > in LM 2.1.2, instead of 'Pitch alterations'? > This would involve changing of > cross-references, though Sounds like a good idea. It seems a bit bizarre that the first thing you read when coming to 'Pitches and key signatures' is 'Pitch alterations' without anything on the unaltered pitches. Of course, there's the short intro in Section 1 on very basic pitch entry. I like this suggestion but it would need a new paragraph (or even subsubsubsection) on basic pitches (and this set of these is different between the languages) first. I'm not well at the moment and don't have energy to write it - this discussion is about as much as I can keep up with at the moment. Very sorry. It needs at least: - A reference to the idea of note names being the letter(s) used for the notes in the user's chosen language. Ref NR for details - A reference to the idea of note names being alterable to adjust the pitch while keeping the same note name (e.g. C sharp), usually in a particular harmonic context. (Are enharmonics too complex at this level?) I think one has to assume that the user has a reasonable grasp of musical grammar, anyway, or they would be using a simpler program - or just recording a MIDI file from the keyboard and getting someone else to engrave it. > https://codereview.appspot.com/579280043/
Sign in to reply to this message.
This patch has already been counted down, however, I would like to have at least one LGTM to the last version of this patch before pushing this. Knowing that this is only an intermediate state and further clarification would help.
Sign in to reply to this message.
On 2020/02/18 10:20:31, michael.kaeppler wrote: > This patch has already been counted down, however, I would > like to have at least one LGTM to the last version of this patch before pushing > this. > Knowing that this is only an intermediate state and further clarification would > help. I skimmed it. LGTM.
Sign in to reply to this message.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
