New feature suggestion
A new accidental for entering natural notes would be useful. In English, this would be 'n', as in 'bn4' or 'gn2'. These would have exactly the same effect as 'b4' or 'g2', but would be easier to debug. If the user is entering or editing music in the key of F, or some other key where B is normally flat, it is often not clear if 'b4' was intended to be B-natural, or if someone just forgot to flat it. If the note is written as 'bn4', the note was clearly meant to be B-natural. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
"David Winfrey" wrote in message news:loom.20140822t182826-...@post.gmane.org... A new accidental for entering natural notes would be useful. In English, this would be 'n', as in 'bn4' or 'gn2'. These would have exactly the same effect as 'b4' or 'g2', but would be easier to debug. If the user is entering or editing music in the key of F, or some other key where B is normally flat, it is often not clear if 'b4' was intended to be B-natural, or if someone just forgot to flat it. If the note is written as 'bn4', the note was clearly meant to be B-natural. But if you enter b4 in F major, you'll get a natural typeset, so there can be no confusion. It seems like you're effectively proposing that b4 is a b natural I've entered accidentally, but bn4 is one I've entered deliberately. How would Lily show the difference? -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
Phil Holmes philholmes.net> writes: > "David Winfrey" patriot.net> wrote in message > news:loom.20140822T182826-365 post.gmane.org... > > > > A new accidental for entering natural notes would be useful. > > > > In English, this would be 'n', as in 'bn4' or 'gn2'. > > > > These would have exactly the same effect as 'b4' or 'g2', > > but would be easier to debug. > > > > If the user is entering or editing music in the key of F, > > or some other key where B is normally flat, it is often > > not clear if 'b4' was intended to be B-natural, or if > > someone just forgot to flat it. > > > > If the note is written as 'bn4', the note was clearly > > meant to be B-natural. > > But if you enter b4 in F major, you'll get a natural typeset, so there can > be no confusion. It seems like you're effectively proposing that b4 is a b > natural I've entered accidentally, but bn4 is one I've entered deliberately. > How would Lily show the difference? > As I understand David, Lily need not show any difference. Accepting the explicit bn helps the user read his own input. If you learned the note-names as referring generically to scale steps, with B being the general term, B-natural and B-sharp the specific terms, and say things like "in F major the Bs are flattened", then LilyPonds names for natural notes seem frustratingly ambiguous. LilyPond uses the Dutch way of thinking, that B is the name of a pitch, Bes the name of another pitch, and you would say "B is not in the F major mode; Bes is." ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
Keith OHara oco.net> writes: > > Phil Holmes philholmes.net> writes: > > > > But if you enter b4 in F major, you'll get a natural typeset, so there > can > > be no confusion. It seems like you're effectively proposing that b4 is a > b > > natural I've entered accidentally, but bn4 is one I've entered > deliberately. > > How would Lily show the difference? > > > > As I understand David, Lily need not show any difference. > Accepting the explicit bn helps the user read his own input. > This is what I meant; there would be no difference in the output. The Lilypond parser would simply ignore 'n' if it finds 'n' when it expects an accidental or note. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
David Winfrey writes: > Keith OHara oco.net> writes: >> >> Phil Holmes philholmes.net> writes: >> > >> > But if you enter b4 in F major, you'll get a natural typeset, so there >> can >> > be no confusion. It seems like you're effectively proposing that b4 is a >> b >> > natural I've entered accidentally, but bn4 is one I've entered >> deliberately. >> > How would Lily show the difference? >> > >> >> As I understand David, Lily need not show any difference. >> Accepting the explicit bn helps the user read his own input. > > This is what I meant; there would be no difference in the output. > The Lilypond parser would simply ignore 'n' if it finds 'n' when > it expects an accidental or note. As my musical education and practice is from a different note language, I cannot really say much about the motivation of that approach. In my country one would never call a "cis" just "c" when talking about music, not even informally (but then nobody wants to get caught being informal anyway). Is this really significantly different in English? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
On Sat, Aug 23, 2014 at 11:57 AM, David Kastrup wrote: > David Winfrey writes: > > > Keith OHara oco.net> writes: > >> > >> Phil Holmes philholmes.net> writes: > >> > > >> > But if you enter b4 in F major, you'll get a natural typeset, so there > >> can > >> > be no confusion. It seems like you're effectively proposing that b4 > is a > >> b > >> > natural I've entered accidentally, but bn4 is one I've entered > >> deliberately. > >> > How would Lily show the difference? > >> > > >> > >> As I understand David, Lily need not show any difference. > >> Accepting the explicit bn helps the user read his own input. > > > > This is what I meant; there would be no difference in the output. > > The Lilypond parser would simply ignore 'n' if it finds 'n' when > > it expects an accidental or note. > > As my musical education and practice is from a different note language, > I cannot really say much about the motivation of that approach. In my > country one would never call a "cis" just "c" when talking about music, > not even informally (but then nobody wants to get caught being informal > anyway). Is this really significantly different in English? > > In the US, I hear people calling "c-sharp" "c" often enough. This usage is certainly not good practice in music theory classes (where I correct it whenever I can). I can't say anything about informal usage. --David ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
> As my musical education and practice is from a different note > language, I cannot really say much about the motivation of that > approach. In my country one would never call a "cis" just "c" when > talking about music, not even informally (but then nobody wants to > get caught being informal anyway). Is this really significantly > different in English? Yes, it is, AFAIK. A similar situation exists in countries where solmisation is common. If you use do, re, mi, for singing a melody, accidentals are normally omitted. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
"Werner LEMBERG" wrote in message news:20140823.201350.355342913...@gnu.org... As my musical education and practice is from a different note language, I cannot really say much about the motivation of that approach. In my country one would never call a "cis" just "c" when talking about music, not even informally (but then nobody wants to get caught being informal anyway). Is this really significantly different in English? Yes, it is, AFAIK. A similar situation exists in countries where solmisation is common. If you use do, re, mi, for singing a melody, accidentals are normally omitted. In England, people who don't understand music would refer to a note on the top line of a treble staff in G major as an F. Musicians would always, always, call it an F sharp. -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
2014-08-23 6:57 GMT+02:00 Keith OHara : > As I understand David, Lily need not show any difference. > Accepting the explicit bn helps the user read his own input. > > If you learned the note-names as referring generically to scale steps, > with B being the general term, B-natural and B-sharp the specific terms, > and say things like "in F major the Bs are flattened", then LilyPonds > names for natural notes seem frustratingly ambiguous. > > LilyPond uses the Dutch way of thinking, that B is the name of a pitch, > Bes the name of another pitch, and you would say "B is not in the F major > mode; Bes is." This is IMO a helpful explanation of a problem that appears on the list from time to time - i think it may be worth to add this to Learning Manual. Btw, "bn" would also help people who have to switch between german and dutch/english naming often (e.g. me). cheers, Janek ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
David Winfrey patriot.net> writes: > A new accidental for entering natural notes would be useful. > > In English, this would be 'n', as in 'bn4' or 'gn2'. > This is in the bug tracker as http://code.google.com/p/lilypond/issues/detail?id=4076 It is easy to add an alternate name for a pitch, just like we already have csharp and cs. If anyone defined variables names 'an', 'bn', etc. their files will fail if we treat bn as a note-name, but if they run convert-ly on their input files those variables can be automatically renamed to something like 'renamed_an' etc. Can anyone think of other downsides to adding 'bn' as a note name ? Should languages using the moveable-do system, French, Spanish, etc., have a similar alternate name for the accidental natural pitches ? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
David Nalesnik gmail.com> writes: > In the US, I hear people calling "c-sharp" "c" often enough. This usage is > certainly not good practice in music theory classes (where I correct it > whenever I can). I can't say anything about informal usage. The original question here was about calling, in the key of D major, the note c-natural by the name "c-natural". Here I think we would not require the student to say "c", in English. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
Keith OHara writes: > David Nalesnik gmail.com> writes: > >> In the US, I hear people calling "c-sharp" "c" often enough. This usage is >> certainly not good practice in music theory classes (where I correct it >> whenever I can). I can't say anything about informal usage. > > The original question here was about calling, in the key of D major, > the note c-natural by the name "c-natural". So far the proposal was about "cn" only, not "cnatural". What would be up with the latter? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
On Sun, 2014-08-24 at 00:03 +0200, Janek Warchoł wrote: > Btw, "bn" would also help people who have to switch between german and > dutch/english naming often (e.g. me). Janek makes a good point, but I'm not sure whether the problem to which he refers is caused by the existence of different national conventions in real life, or the existence of alternative syntaxes in lilypond source. If the latter, we might be about to compound the problem: We already have language-specific suffixes for sharp and flat (originally, -is and -es) so presumably a suffix for naturals would need that too. If we continue down that path, is there not a risk that, eventually, source code written in one localisation will become hard (harder?) to understand in another? And of course either the present syntax would need to be preserved as an option for compatibility, or convert-ly would need to impose the new syntax. Perhaps we could have translate-ly to translate lilypond source between localisations? This thread is making me a bit uneasy. Genesis 11:1-9 applies. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
On Tue, Aug 26, 2014 at 2:11 AM, Keith OHara wrote: > David Nalesnik gmail.com> writes: > > > In the US, I hear people calling "c-sharp" "c" often enough. This usage > is > > certainly not good practice in music theory classes (where I correct it > > whenever I can). I can't say anything about informal usage. > > The original question here was about calling, in the key of D major, > the note c-natural by the name "c-natural". > Here I think we would not require the student to say "c", in English. > Of course not. Sorry, I think I was responding to the tendency of students to call C sharp in the key of D major "C," which is obviously wrong! "cn" is nice--I would say "C natural," and why not make it explicit? --David ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
Just my two cent's worth: Adding an "n" modifier isn't saying that C Sharp is C Natural, it's an assertion. "Yes, I really mean natural. No, I didn't just forget the sharp." Knute Snortum (via Gmail) On Tue, Aug 26, 2014 at 5:22 AM, David Nalesnik wrote: > On Tue, Aug 26, 2014 at 2:11 AM, Keith OHara wrote: > > > David Nalesnik gmail.com> writes: > > > > > In the US, I hear people calling "c-sharp" "c" often enough. This > usage > > is > > > certainly not good practice in music theory classes (where I correct it > > > whenever I can). I can't say anything about informal usage. > > > > The original question here was about calling, in the key of D major, > > the note c-natural by the name "c-natural". > > Here I think we would not require the student to say "c", in English. > > > > Of course not. > > Sorry, I think I was responding to the tendency of students to call C sharp > in the key of D major "C," which is obviously wrong! > > "cn" is nice--I would say "C natural," and why not make it explicit? > > --David > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
Knute Snortum gmail.com> writes: > Just my two cent's worth: > > Adding an "n" modifier isn't saying that C Sharp is C Natural, it's an > assertion. "Yes, I really mean natural. No, I didn't just forget the > sharp." That sounds like a benefit, but I would think that people who value "cn" for that reason would prefer a language definition that did not include plain "c", so that Lilypond would not even produce output based on such an error. -- Dan ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
On Tue, Aug 26, 2014 at 8:41 PM, Dan Eble wrote: > Knute Snortum gmail.com> writes: > > > Just my two cent's worth: > > > > Adding an "n" modifier isn't saying that C Sharp is C Natural, it's an > > assertion. "Yes, I really mean natural. No, I didn't just forget the > > sharp." > > That sounds like a benefit, but I would think that people who value > "cn" for that reason would prefer a language definition that did not > include plain "c", so that Lilypond would not even produce output > based on such an error. > > The "cn" would be used presumably to reflect the fact that the output will have a natural sign. Requiring that C in C major be notated as "cn"--if I'm understanding you correctly--doesn't make sense. --David ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
On Aug 26, 2014, at 21:56 , David Nalesnik wrote: > On Tue, Aug 26, 2014 at 8:41 PM, Dan Eble wrote: > Knute Snortum gmail.com> writes: > > > Adding an "n" modifier isn't saying that C Sharp is C Natural, it's an > > assertion. "Yes, I really mean natural. No, I didn't just forget the > > sharp." > > That sounds like a benefit, but I would think that people who value > "cn" for that reason would prefer a language definition that did not > include plain "c", so that Lilypond would not even produce output > based on such an error. > > > The "cn" would be used presumably to reflect the fact that the output will > have a natural sign. Requiring that C in C major be notated as "cn"--if I'm > understanding you correctly--doesn't make sense. > > —David OK, but my general point is the same. If “x” and “xn” are not intended to be used interchangeably, involving the computer will be more successful than continuing to rely on the human alone to detect mistakes. — Dan ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New feature suggestion
Dan Eble writes: > On Aug 26, 2014, at 21:56 , David Nalesnik wrote: > >> On Tue, Aug 26, 2014 at 8:41 PM, Dan Eble wrote: >> Knute Snortum gmail.com> writes: >> >> > Adding an "n" modifier isn't saying that C Sharp is C Natural, it's an >> > assertion. "Yes, I really mean natural. No, I didn't just forget the >> > sharp." >> >> That sounds like a benefit, but I would think that people who value >> "cn" for that reason would prefer a language definition that did not >> include plain "c", so that Lilypond would not even produce output >> based on such an error. >> >> >> The "cn" would be used presumably to reflect the fact that the >> output will have a natural sign. Requiring that C in C major be >> notated as "cn"--if I'm understanding you correctly--doesn't make >> sense. >> >> —David > > OK, but my general point is the same. If “x” and “xn” are not > intended to be used interchangeably, involving the computer will be > more successful than continuing to rely on the human alone to detect > mistakes. There are no plans on making x and xn distinguishable in any manner that would engage the attention of LilyPond. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
