Re: Suggestion to make sharps and flats persistent

[David Kastrup]

"Fr. Samuel Springuel"  writes:

>> On 20 May, 2020, at 10:22 AM, David Kastrup  wrote:
>> 
>> myNames = \language-pitch-names.english
>> myNames.do = c
>> myNames.re = d
>> myNames.mi = e
>> myNames.fa = f
>> myNames.sol = g
>> myNames.la = a
>> myNames.ta = bes
>> myNames.ti = b
>> language-pitch-names.solfegenglish = \myNames
>> \language "solfegenglish"
>> 
>
> Is that a recent change to the syntax?  It definitely looks much nicer
> than what I had lying around.

It's pulling together a few things regarding language syntax.  Actually
only the very first line is 2.19+ material I think: all the rest would
have worked in 2.18, possibly 2.16.  But it has become more natural to
think of such stuff in terms of dotted lists recently.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Fr. Samuel Springuel]

> On 20 May, 2020, at 10:22 AM, David Kastrup  wrote:
> 
> myNames = \language-pitch-names.english
> myNames.do = c
> myNames.re = d
> myNames.mi = e
> myNames.fa = f
> myNames.sol = g
> myNames.la = a
> myNames.ta = bes
> myNames.ti = b
> language-pitch-names.solfegenglish = \myNames
> \language "solfegenglish"
> 

Is that a recent change to the syntax?  It definitely looks much nicer than 
what I had lying around. 


✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036

PAX ☧ ΧΡΙΣΤΟΣ

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

"Fr. Samuel Springuel"  writes:

>> On 20 May, 2020, at 9:43 AM, Paul McKay  wrote:
>> 
>> Todays thoughts are: when you specify \language, then part of what
>> you are doing is setting up the parser to understand which character
>> sequence should indicate an f-sharp. I would like to be able to
>> temporarily reconfigure this so that as well as mapping ‘fs’ to
>> f-sharp you can ask it to map ‘F’ to f-sharp. I imagine that the
>> parser is a finite state machine and that at the appropriate point
>> it looks up a list. Normally this would say that ‘fs’ means f-sharp
>> (or ‘fes’ means f-sharp if you were in another language). I guess it
>> looks up a list of pitch names to check whether the current token is
>> a pitch as expected and, if so, which one. If that list might have
>> ‘F’ added at the beginning of the search order, then the parser
>> would recognize the letter ‘F’ as meaning the pitch f-sharp. Later
>> on, you could ask to remove the ‘F’ entry from that list. Removing
>> it would automatically revert to the default behaviour because the
>> list would still contain the entry to say that ‘fs’ means
>> f-sharp. To avoid confusion, the request to add an item to the list
>> would have the form (newName, pitchNameInOriginalLanguage).
>
> I’ve done something like this for transcribing solfege music (while retaining 
> English note names for other purposes):
>
> myNames = #(append (assoc-get 'english language-pitch-names)
>   `(
> (do . ,(ly:make-pitch -1 0 NATURAL))
> (re . ,(ly:make-pitch -1 1 NATURAL))
> (mi . ,(ly:make-pitch -1 2 NATURAL))
> (fa . ,(ly:make-pitch -1 3 NATURAL))
> (sol . ,(ly:make-pitch -1 4 NATURAL))
> (la . ,(ly:make-pitch -1 5 NATURAL))
> (ta . ,(ly:make-pitch -1 6 FLAT))
> (ti . ,(ly:make-pitch -1 6 NATURAL))
>   ))
>
> solfegenglish = \myNames
> #(ly:parser-set-note-names solfegenglish)

You can write this as

myNames = \language-pitch-names.english
myNames.do = c
myNames.re = d
myNames.mi = e
myNames.fa = f
myNames.sol = g
myNames.la = a
myNames.ta = bes
myNames.ti = b
language-pitch-names.solfegenglish = \myNames
\language "solfegenglish"

{ c' d' ta' ti' }

> You should be able to adapt this for any particular set of note names you 
> want.

One problem is that programs like Frescobaldi will stop knowing what
you are talking about.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Fr. Samuel Springuel]

> On 20 May, 2020, at 9:43 AM, Paul McKay  wrote:
> 
> Todays thoughts are: when you specify \language, then part of what you are 
> doing is setting up the parser to understand which character sequence should 
> indicate an f-sharp. I would like to be able to temporarily reconfigure this 
> so that as well as mapping ‘fs’  to f-sharp you can ask it to map ‘F’ to 
> f-sharp. I imagine that the parser is a finite state machine and that at the 
> appropriate point it looks up a list. Normally this would say that ‘fs’ means 
> f-sharp (or ‘fes’ means f-sharp if you were in another language). I guess it 
> looks up a list of pitch names to check whether the current token is a pitch 
> as expected and, if so, which one. If that list might have ‘F’ added at the 
> beginning of the search order, then the parser would recognize the letter ‘F’ 
> as meaning the pitch f-sharp. Later on, you could ask to remove the ‘F’ entry 
> from that list. Removing it would automatically revert to the default 
> behaviour because the list would still contain the entry to say that ‘fs’ 
> means f-sharp. To avoid confusion, the request to add an item to the list 
> would have the form (newName, pitchNameInOriginalLanguage).

I’ve done something like this for transcribing solfege music (while retaining 
English note names for other purposes):

myNames = #(append (assoc-get 'english language-pitch-names)
  `(
(do . ,(ly:make-pitch -1 0 NATURAL))
(re . ,(ly:make-pitch -1 1 NATURAL))
(mi . ,(ly:make-pitch -1 2 NATURAL))
(fa . ,(ly:make-pitch -1 3 NATURAL))
(sol . ,(ly:make-pitch -1 4 NATURAL))
(la . ,(ly:make-pitch -1 5 NATURAL))
(ta . ,(ly:make-pitch -1 6 FLAT))
(ti . ,(ly:make-pitch -1 6 NATURAL))
  ))

solfegenglish = \myNames
#(ly:parser-set-note-names solfegenglish)


You should be able to adapt this for any particular set of note names you want.


✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036

PAX ☧ ΧΡΙΣΤΟΣ

Re: Suggestion to make sharps and flats persistent

[Paul McKay]

Hi guys

Many thanks for taking such an interest in this. I have been thinking. I
can see that using the key signature to automatically donate sharps and
flats is going to be a lot of work and cause problems.

Todays thoughts are: when you specify \language, then part of what you are
doing is setting up the parser to understand which character sequence
should indicate an f-sharp. I would like to be able to temporarily
reconfigure this so that as well as mapping ‘fs’  to f-sharp you can ask it
to map ‘F’ to f-sharp. I imagine that the parser is a finite state machine
and that at the appropriate point it looks up a list. Normally this would
say that ‘fs’ means f-sharp (or ‘fes’ means f-sharp if you were in another
language). I guess it looks up a list of pitch names to check whether the
current token is a pitch as expected and, if so, which one. If that list
might have ‘F’ added at the beginning of the search order, then the parser
would recognize the letter ‘F’ as meaning the pitch f-sharp. Later on, you
could ask to remove the ‘F’ entry from that list. Removing it would
automatically revert to the default behaviour because the list would still
contain the entry to say that ‘fs’ means f-sharp. To avoid confusion, the
request to add an item to the list would have the form (*newName,
pitchNameInOriginalLanguage)*.

I believe this would allow me to do what I originally wanted (to avoid
having to type the accidentals when I’m working with music which is
resolutely in one key) and would not raise any consequential problems.
Granted one could get a headache if you mapped  ‘e’ to mean f-sharp, but
you’d deserve it. People who like quarter-tones might also enjoy being able
to name them. This doesn’t seem to me like a big change.

Gianmaria: It might possibly be doable in Frescobaldi but I don’t think it
belongs there. One would end up with a source file which contained both
LilyPond and Frescobaldi code. This is not an insuperable problem, but I
don’t think it’s the right answer for this.

Urs: I am always encoding a pitch as it is: but am asking that I get to
give the pitch another name.

Re the discussion about minor keys, in A minor you could set G to map to
g-sharp and save keystrokes (unless you count the shift key as a keystroke
in which case you might use ‘h’.)

On Mon, 18 May 2020 at 18:24, Gianmaria Lari 
wrote:

>
> [...]. That being said…
>>
>> Are not
>>
>> \relative f'
>>
>> and
>>
>> \fixed c'''
>>
>> just "feature requests for laziness with resulting opaqueness"?  ;)
>
>  [...]
>
>>
>
> We (well… modulo me LOL) don’t get this worked up about how \relative
>> makes cut-and-paste a nightmare. Why start now?  ;)
>
>
> Some lilypond users get vaccinated against \relative issues and they are
> using it without any problem (it's not my case). So looks pretty clear you
> can live and get profit from \relative.
>
> Personally I really don't like \relative: it always cause problems to me
> but maybe there are also aesthetic reasons for my aversion.
>
> As I previously said (few months ago) \relative is another thing that in
> my opinion should be handle by the editor.
>
> Copy and paste issues with relative is only another bad things but for me
> it's not the main one.  For example I consider perfectly acceptable copy
> and paste issues with Python indention because the benefits largely
> outweigh the drawbacks imho.
> G.
>

Re: Suggestion to make sharps and flats persistent

[Carl Sorensen]

On Tue, May 19, 2020 at 4:13 PM David Kastrup  wrote:

> Carl Sorensen  writes:
>
> >> -- Forwarded message --
> >> From: Kieren MacMillan 
> >> To: David Nalesnik 
> >> Cc: Lilypond-User Mailing List 
> >> Bcc:
> >> Date: Tue, 19 May 2020 10:22:15 -0400
> >> Subject: Re: Suggestion to make sharps and flats persistent
> >> Hi David,
> >>
> >> > But minor-mode music is often a conglomeration of the "forms" of the
> >> > minor scale which makes them of limited separate utility.  Nothing is
> >> > in "harmonic minor."  Notating something in minor by J. S. Bach could
> >> > be terrifying.
> >>
> >> Oh, I totally agree with "terrifying" (and, in my opinion, unhelpful).
> =)
> >> I’m just pointing out that it’s not difficult to figure out how to make
> > it work for people who don’t mind living in terror.
> >>
> >
> > But if we support terrifying modes, then we have to deal with all of the
> > issues that come fom people having difficulty with terrifying modes.
> >
> > I'm a firm believer in the simple statement that in LilyPond, you type
> the
> > pitch you hear,
>
> Well, no.  There are enharmonics.  The same pitch you hear has different
> spellings for writing.
>

That's true.  I probably should have said "You type the desired spelling of
the pitch you hear."


>
> > and the software is responsible for getting the display correct
> > (strictly speaking, this means that I should oppose relative mode,
> > although I admit I'm inconsistent here).
>
>
> > Supporting difficult syntax is harder stil -- it'a an ongoing expense.
> >  That's why I'm so appreciative of David K's work to simplify and
> > rationalize our syntax so it (almost) always works the way one thinks it
> > should.
>
> Anecdote: in January there was the note typesetting conference in
> Salzburg and I typed up some example along the lines of
>
> \override NoteHead.color = #red
>
> and then Han-Wen interrupted (or took me aside afterwards or something,
> I don't quite remember) and said that I needed to write
>
> \override NoteHead color = #red
>
> instead.  LilyPond actual still does accept that syntax for
> compatibility reasons.  But since things like NoteHead.color have now
> gained the Scheme representation of #'(NoteHead color) and a whole
> number of user-level functions make use of that, it completely threw me
> for a loop to get the suggestion of writing something that no longer
> fits the way I have come to think about NoteHead.color : not as some
> arbitrary syntax but something conveying a meaning also represented in
> Scheme.
>
> I wonder for how many other old users of LilyPond these changes in
> meaning that have become the natural view for me (and hopefully new
> users) just did not happen since a whole lot of the old syntax of
> LilyPond continues to work well enough without viewing it in terms of
> structuring concepts that came after the fact.
>

I'm an old user of LilyPond, and I don't really have the Scheme
representation built into my understanding of the new syntax, but I love
the new syntax because it makes it painless for me to burrow down into some
complicated alist structure and just get the individual property I want.

I realize that this is due to the Scheme structure being what it is, but I
don't think about the Scheme structure any more, most of the time.  I just
think about the . operator being the equivalent to a member property (just
as it is in Visual Basic).  Losing track of the Scheme representation means
I have to remind myself of it when I want to write some Scheme, but when I
just want to write LilyPond I can ignore the Scheme representation.  And
that is convenient for me.

So thanks!

Carl

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Carl Sorensen  writes:

>> -- Forwarded message --
>> From: Kieren MacMillan 
>> To: David Nalesnik 
>> Cc: Lilypond-User Mailing List 
>> Bcc:
>> Date: Tue, 19 May 2020 10:22:15 -0400
>> Subject: Re: Suggestion to make sharps and flats persistent
>> Hi David,
>>
>> > But minor-mode music is often a conglomeration of the "forms" of the
>> > minor scale which makes them of limited separate utility.  Nothing is
>> > in "harmonic minor."  Notating something in minor by J. S. Bach could
>> > be terrifying.
>>
>> Oh, I totally agree with "terrifying" (and, in my opinion, unhelpful).  =)
>> I’m just pointing out that it’s not difficult to figure out how to make
> it work for people who don’t mind living in terror.
>>
>
> But if we support terrifying modes, then we have to deal with all of the
> issues that come fom people having difficulty with terrifying modes.
>
> I'm a firm believer in the simple statement that in LilyPond, you type the
> pitch you hear,

Well, no.  There are enharmonics.  The same pitch you hear has different
spellings for writing.

> and the software is responsible for getting the display correct
> (strictly speaking, this means that I should oppose relative mode,
> although I admit I'm inconsistent here).


> Supporting difficult syntax is harder stil -- it'a an ongoing expense.
>  That's why I'm so appreciative of David K's work to simplify and
> rationalize our syntax so it (almost) always works the way one thinks it
> should.

Anecdote: in January there was the note typesetting conference in
Salzburg and I typed up some example along the lines of

\override NoteHead.color = #red

and then Han-Wen interrupted (or took me aside afterwards or something,
I don't quite remember) and said that I needed to write

\override NoteHead color = #red

instead.  LilyPond actual still does accept that syntax for
compatibility reasons.  But since things like NoteHead.color have now
gained the Scheme representation of #'(NoteHead color) and a whole
number of user-level functions make use of that, it completely threw me
for a loop to get the suggestion of writing something that no longer
fits the way I have come to think about NoteHead.color : not as some
arbitrary syntax but something conveying a meaning also represented in
Scheme.

I wonder for how many other old users of LilyPond these changes in
meaning that have become the natural view for me (and hopefully new
users) just did not happen since a whole lot of the old syntax of
LilyPond continues to work well enough without viewing it in terms of
structuring concepts that came after the fact.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Carl Sorensen]

> -- Forwarded message --
> From: Kieren MacMillan 
> To: David Nalesnik 
> Cc: Lilypond-User Mailing List 
> Bcc:
> Date: Tue, 19 May 2020 10:22:15 -0400
> Subject: Re: Suggestion to make sharps and flats persistent
> Hi David,
>
> > But minor-mode music is often a conglomeration of the "forms" of the
> > minor scale which makes them of limited separate utility.  Nothing is
> > in "harmonic minor."  Notating something in minor by J. S. Bach could
> > be terrifying.
>
> Oh, I totally agree with "terrifying" (and, in my opinion, unhelpful).  =)
> I’m just pointing out that it’s not difficult to figure out how to make
it work for people who don’t mind living in terror.
>

But if we support terrifying modes, then we have to deal with all of the
issues that come fom people having difficulty with terrifying modes.

I'm a firm believer in the simple statement that in LilyPond, you type the
pitch you hear, and the software is responsible for getting the display
correct (strictly speaking, this means that I should oppose relative mode,
although I admit I'm inconsistent here).

Making up a syntax is easy.

Implementing the syntax is harder -- there are lots of corner cases.

Supporting difficult syntax is harder stil -- it'a an ongoing expense.
 That's why I'm so appreciative of David K's work to simplify and
rationalize our syntax so it (almost) always works the way one thinks it
should.

A user could certainly write a music function that would allow the entry of
"what you see" instead of "what you hear".  And if they did so, it could be
added to the LSR.

But I would be against adding this to the official LilyPond distribution.

Thansk,

Carl

Re: Suggestion to make sharps and flats persistent

[antlists]

On 19/05/2020 16:04, David Kastrup wrote:

All because people think "it's not difficult to figure out how to make
it work" when actually it is once you aim for more than a "mostly
working" determination and keep shuffling around just which 10% you are
willing to let fall apart.


Too many people try to solve the immediate problem, without asking 
themselves what the real problem is.


If you work out what the state table is, it's fine solving just your bit 
of it. But if you don't know what the state table is, (trying to) solve 
your bit just leaves a big mess for the next guy who needs a different 
bit solved.


Cheers,
Wol

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> But minor-mode music is often a conglomeration of the "forms" of the
>> minor scale which makes them of limited separate utility.  Nothing is
>> in "harmonic minor."  Notating something in minor by J. S. Bach could
>> be terrifying.
>
> Oh, I totally agree with "terrifying" (and, in my opinion, unhelpful).  =)
> I’m just pointing out that it’s not difficult to figure out how to
> make it work for people who don’t mind living in terror.

They come back to haunt you.  Try removing some functionality when it
becomes clear that it is broken by design and cannot possibly do what
its hand-waving definition and implementation calls for, and receive all
the flak for it.

I had to fix repeat chords (which were not amenable to work under
\relative or \transposition), nested property overrides (which were not
designed to be able to distinguish overriding an encompassing alist from
overriding a subproperty), embedded scheme code (which would not allow
for closures and had weird syntax for admitting variables) and a few
other things that had gained popularity while being inherently broken
and in requirement of much more complex implementations.

All because people think "it's not difficult to figure out how to make
it work" when actually it is once you aim for more than a "mostly
working" determination and keep shuffling around just which 10% you are
willing to let fall apart.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[David Nalesnik]

Kieren,

On Tue, May 19, 2020 at 9:22 AM Kieren MacMillan
 wrote:
>
> Hi David,
>
> > But minor-mode music is often a conglomeration of the "forms" of the
> > minor scale which makes them of limited separate utility.  Nothing is
> > in "harmonic minor."  Notating something in minor by J. S. Bach could
> > be terrifying.
>
> Oh, I totally agree with "terrifying" (and, in my opinion, unhelpful).  =)
> I’m just pointing out that it’s not difficult to figure out how to make it 
> work for people who don’t mind living in terror.
>

Possibly one could treat minor mode as the natural form with variable
^6 and ^7.  Dispense with "natural," "melodic," and "harmonic."  This
would be more realistic.  But...I don't see the need and I don't want
to be the one to figure out an implementation :)

My vote will always be on the side of notating by what something *is*
and not what it appears because of accidents of key signature.

What of the tonal music where the key is ambiguous/constantly
shifting?  And what of those spots in Chopin and Schubert in, say,
F-flat major?

"Well, then, don't use the sticky pitches!"  In my opinion, the pitch
entry should conceptually consistent whether you are notating
something in A minor entirely devoid of accidentals or dodecaphonic
music.

DN

Re: Suggestion to make sharps and flats persistent

[Kieren MacMillan]

Hi David,

> But minor-mode music is often a conglomeration of the "forms" of the
> minor scale which makes them of limited separate utility.  Nothing is
> in "harmonic minor."  Notating something in minor by J. S. Bach could
> be terrifying.

Oh, I totally agree with "terrifying" (and, in my opinion, unhelpful).  =)
I’m just pointing out that it’s not difficult to figure out how to make it work 
for people who don’t mind living in terror.

Cheers,
Kieren.

Re: Suggestion to make sharps and flats persistent

[David Nalesnik]

On Mon, May 18, 2020 at 8:20 PM Kieren MacMillan
 wrote:
>
> Hi Wol,
>
> > how is lilypond supposed to know whether the g and f are supposed to be 
> > sharpened? :-)
>
> \keyed \a \harmonicminor { a g g+ a }
>
> Is it really that difficult to figure out a rational input syntax?
> I could come up with a dozen completely different ones without breaking a 
> sweat.
>

But minor-mode music is often a conglomeration of the "forms" of the
minor scale which makes them of limited separate utility.  Nothing is
in "harmonic minor."  Notating something in minor by J. S. Bach could
be terrifying.

David N

Re: Suggestion to make sharps and flats persistent

[Kieren MacMillan]

Hi Wol,

> how is lilypond supposed to know whether the g and f are supposed to be 
> sharpened? :-)

\keyed \a \harmonicminor { a g g+ a }

Is it really that difficult to figure out a rational input syntax?
I could come up with a dozen completely different ones without breaking a sweat.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

RE: Suggestion to make sharps and flats persistent

[Mark Stephen Mrotek]

Lilypond doesn't know. Somewhere along the line human knowledge/input is 
required.

Mark

-Original Message-
From: antlists [mailto:antli...@youngman.org.uk] 
Sent: Monday, May 18, 2020 4:33 PM
To: Mark Stephen Mrotek ; lilypond-user@gnu.org
Subject: Re: Suggestion to make sharps and flats persistent

On 18/05/2020 22:15, Mark Stephen Mrotek wrote:
> The natural a minor scale does not contain any sharps.

But is it a natural scale?

> The harmonic a minor scale has the f sharp.

or a harmonic scale?

> The melodic a minor scale has the g sharp and the f sharp.
> 
But it also has g and f. So my point remains - ESPECIALLY if it's the melodic 
scale - how is lilypond supposed to know whether the g and f are supposed to be 
sharpened? :-)

> Mark
> 
Cheers,
Wol

> -Original Message-
> From: lilypond-user 
> [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf 
> Of antlists
> Sent: Monday, May 18, 2020 12:22 PM
> To: lilypond-user@gnu.org
> Subject: Re: Suggestion to make sharps and flats persistent
> 
> On 18/05/2020 17:33, Kieren MacMillan wrote:
>> We (well… modulo me LOL) don’t get this worked up about how \relative 
>> makes cut-and-paste a nightmare. Why start now?;)
> 
> Those of us who only use \relative (just me?) don't have any problems with 
> cut-n-paste. Or is it just that my workflow is more likely to use "\repeat 
> unfold"?
> 
> I've got no problem with \keyed, but there is a fly in the ointment 
> here ... \keyed a \minor { a b c d e f g a g f e d c b a }
> 
> Now is that a g-natural or g-sharp? Likewise the f.
> 
> Cheers,
> Wol
> 

Re: Suggestion to make sharps and flats persistent

[antlists]

On 18/05/2020 22:15, Mark Stephen Mrotek wrote:

The natural a minor scale does not contain any sharps.


But is it a natural scale?


The harmonic a minor scale has the f sharp.


or a harmonic scale?


The melodic a minor scale has the g sharp and the f sharp.

But it also has g and f. So my point remains - ESPECIALLY if it's the 
melodic scale - how is lilypond supposed to know whether the g and f are 
supposed to be sharpened? :-)



Mark


Cheers,
Wol


-Original Message-
From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of antlists
Sent: Monday, May 18, 2020 12:22 PM
To: lilypond-user@gnu.org
Subject: Re: Suggestion to make sharps and flats persistent

On 18/05/2020 17:33, Kieren MacMillan wrote:

We (well… modulo me LOL) don’t get this worked up about how \relative
makes cut-and-paste a nightmare. Why start now?;)


Those of us who only use \relative (just me?) don't have any problems with cut-n-paste. 
Or is it just that my workflow is more likely to use "\repeat unfold"?

I've got no problem with \keyed, but there is a fly in the ointment here ... 
\keyed a \minor { a b c d e f g a g f e d c b a }

Now is that a g-natural or g-sharp? Likewise the f.

Cheers,
Wol

Re: Suggestion to make sharps and flats persistent

[Kieren MacMillan]

Hi Elaine,

> Use of \relative is always fine if you realize that you need to explicitly 
> define it every time you break it up.

If you have any desire to reuse small bits, that means you need to have dozens 
(maybe hundreds?) of pre-defined bits.
I can’t imagine wanting to go through that effort, when absolute mode is so 
easy to use (especially with MIDI input).

> If G# is in your key signature, and you are using "g" to represent G#, then 
> how do you represent G natural?  gn?  Sure, there could be some syntax for 
> it. 

g+ raises the "keyed" version, g- lowers it?  ;)


> Personally, I don't see the benefit.  With more complicated and transposing 
> music, remembering when I need to say gs vs g  or g vs gn would become 
> annoying quickly.  

+1^100
(and, yes, I understand the mathematical irony there LOL)

Cheers,
Kieren.

Re: Suggestion to make sharps and flats persistent

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: antlists 
> To: lilypond-user@gnu.org
> Cc:
> Bcc:
> Date: Mon, 18 May 2020 20:21:32 +0100
> Subject: Re: Suggestion to make sharps and flats persistent
> On 18/05/2020 17:33, Kieren MacMillan wrote:
> > We (well… modulo me LOL) don’t get this worked up about how \relative
> makes cut-and-paste a nightmare. Why start now?;)
>
> Those of us who only use \relative (just me?) don't have any problems
> with cut-n-paste. Or is it just that my workflow is more likely to use
> "\repeat unfold"?
>
> I've got no problem with \keyed, but there is a fly in the ointment here
> ... \keyed a \minor { a b c d e f g a g f e d c b a }
>
> Now is that a g-natural or g-sharp? Likewise the f.
>
> Cheers,
> Wol
>
>
The problems with \relative come when you copy *only the notes* from within
a \relative expression and paste them into another, and omit the context .

Use of \relative is always fine if you realize that you need to explicitly
define it every time you break it up.

So, if you have 16 measures to reuse, you structure it:
beforeReused = \relative c' { ...}
toReuse = \relative c'' { ... }
afterReuse = \relative c'{ ... }

mySong = {
\beforeReused
\toReuse
\afterReuse
\toReuse
}

And, if you decide to also put raw notes in mySong = \relative c' { }, the
other sections you put in will NOT affect the octave of the notes in
mySong.  I would still advise against that.  But at least it reduces
problems that come from pasting in only notes, which includes both those
notes being in the wrong octave, and messing up the octaves of material
following the notes you paste in.

Likewise for non-sequential music, such music with endings.  That is, in
lazy use of \relative, the octave at the beginning of a 2nd ending will not
come from what precedes it musically (the section in \repeat), but by what
comes before it on the page, which is the 1st ending.  Again, you just need
to use \relative as necessary:

\repeat volta 2 { ... }
\alternative {
\relative { ... }
\relative { ... }
}


On the other matter, that this thread is actually about, the only "problem"
with  the \keyed suggestion by Kieren, is that you have to define names for
the accidentals.

The case of minor keys is simply one illustration of this.

If G# is in your key signature, and you are using "g" to represent G#, then
how do you represent G natural?  gn?  Sure, there could be some syntax for
it.

Personally, I don't see the benefit.  With more complicated and transposing
music, remembering when I need to say gs vs g  or g vs gn would become
annoying quickly.


Cheers,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

RE: Suggestion to make sharps and flats persistent

[Mark Stephen Mrotek]

The natural a minor scale does not contain any sharps.
The harmonic a minor scale has the f sharp.
The melodic a minor scale has the g sharp and the f sharp.

Mark

-Original Message-
From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of antlists
Sent: Monday, May 18, 2020 12:22 PM
To: lilypond-user@gnu.org
Subject: Re: Suggestion to make sharps and flats persistent

On 18/05/2020 17:33, Kieren MacMillan wrote:
> We (well… modulo me LOL) don’t get this worked up about how \relative 
> makes cut-and-paste a nightmare. Why start now?;)

Those of us who only use \relative (just me?) don't have any problems with 
cut-n-paste. Or is it just that my workflow is more likely to use "\repeat 
unfold"?

I've got no problem with \keyed, but there is a fly in the ointment here ... 
\keyed a \minor { a b c d e f g a g f e d c b a }

Now is that a g-natural or g-sharp? Likewise the f.

Cheers,
Wol

Re: Suggestion to make sharps and flats persistent

[Kieren MacMillan]

Hi Wol,

> Those of us who only use \relative (just me?) don't have any problems with 
> cut-n-paste. Or is it just that my workflow is more likely to use "\repeat 
> unfold"?

Let’s say you’re writing a piece in sonata form (or even just engraving an 
existing one!).
You want to [re]use mm. 100-120, mm. 146-152, and mm. 190–203 from the 
exposition in the recapitulation.
Good luck pulling those out and plopping them down without doing extra work 
(octave checks, multiple compilations).

Now… you compile [in relative mode] and realize you missed a 16-measure chunk.
You try to add the new music, but forget what octave the relative mode is 
currently in.

ugh I’ve got a headache just thinking about it.  LOL

> I've got no problem with \keyed, but there is a fly in the ointment here ... 
> \keyed a \minor { a b c d e f g a g f e d c b a }
> Now is that a g-natural or g-sharp? Likewise the f.

Details, details…  ;)

\keyed #'(a bf css d e f gs) { a b c d e f g a g f e d c b a }

Then a little sugar lets you do something like

  
 kierenskey = #'(a bf css d e f gs)
 \keyed \kierenskey { a b c d e f g a g f e d c b a }
  <\pseudo>

Look… I’m not recommending this — to me, it all sounds just as painful as 
\relative — but I have yet to be convinced that a rational implementation of it 
would be rocket-science-or-greater.

Cheers,
Kieren.

Re: Suggestion to make sharps and flats persistent

[antlists]

On 18/05/2020 17:33, Kieren MacMillan wrote:

We (well… modulo me LOL) don’t get this worked up about how \relative makes 
cut-and-paste a nightmare. Why start now?;)


Those of us who only use \relative (just me?) don't have any problems 
with cut-n-paste. Or is it just that my workflow is more likely to use 
"\repeat unfold"?


I've got no problem with \keyed, but there is a fly in the ointment here 
... \keyed a \minor { a b c d e f g a g f e d c b a }


Now is that a g-natural or g-sharp? Likewise the f.

Cheers,
Wol

Re: Suggestion to make sharps and flats persistent

[Gianmaria Lari]

My apologies for the text formatting of my last mail. I wrote the message
on my mobile phone and didn't notice the formatting issue.

>

Re: Suggestion to make sharps and flats persistent

[Gianmaria Lari]

> [...]. That being said…
>
> Are not
>
> \relative f'
>
> and
>
> \fixed c'''
>
> just "feature requests for laziness with resulting opaqueness"?  ;)

 [...]

>

We (well… modulo me LOL) don’t get this worked up about how \relative makes
> cut-and-paste a nightmare. Why start now?  ;)


Some lilypond users get vaccinated against \relative issues and they are
using it without any problem (it's not my case). So looks pretty clear you
can live and get profit from \relative.

Personally I really don't like \relative: it always cause problems to me
but maybe there are also aesthetic reasons for my aversion.

As I previously said (few months ago) \relative is another thing that in my
opinion should be handle by the editor.

Copy and paste issues with relative is only another bad things but for me
it's not the main one.  For example I consider perfectly acceptable copy
and paste issues with Python indention because the benefits largely
outweigh the drawbacks imho.
G.

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> LilyPond's input language has no representation for c-natural
>> as opposed to c-unkeyed-yet. Any kind of implementation would be doomed 
>> without
>> that, anyway.  Once you have that, it really becomes a tricky question
>> of where c-unkeyed-yet would get its final pitch.  And how this is
>> supposed to behave with regard to transposition: transposing half a step
>> up and down again should be a do-nothing, so you'd actually also need a
>> cis-unkeyed-yet .  Do we have a headache yet?
>
> \relative gives me a headache.
>
> My point is how is this really different, for those who want to give
> themselves headaches?
> Your answer doesn’t convince me it’s all that different — only unadvisable.

Before you get to implement something, you need to figure out its
semantics.  Otherwise you end up fixing stuff back and forth directed by
what feels "right" and "wrong" when actually there is no consistent rule
that could distinguish right from wrong and do only what is right.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Urs Liska]

Am 18. Mai 2020 18:33:09 MESZ schrieb Kieren MacMillan 
:
>Hi all,
>
>> This is just a feature request for laziness with resulting
>opaqueness. I think it has been requested several times over the years
>because of other program's bad habits.
>
>I agree with this 100%. That being said…
>
>Are not
>
>\relative f'
>
>and
>
>\fixed c'''
>
>just "feature requests for laziness with resulting opaqueness"?  ;)
>
>More productively: Why couldn’t we add some sugar for those who want
>it, e.g.
>
>\keyed d \major { d f e c d }
>
>would result in
>
>{ d f# e c# d }
>
>??

I think this would be consistent (so a vague +1). But different from the OP's 
request.

>
>We (well… modulo me LOL) don’t get this worked up about how \relative
>makes cut-and-paste a nightmare. Why start now?  ;)

Touché ;-)

Urs
>
>Cheers,
>Kieren.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Kieren MacMillan  writes:

> Hi all,
>
>> This is just a feature request for laziness with resulting
> opaqueness. I think it has been requested several times over the years
> because of other program's bad habits.
>
> I agree with this 100%. That being said…
>
> Are not
>
> \relative f'
>
> and
>
> \fixed c'''
>
> just "feature requests for laziness with resulting opaqueness"?  ;)
>
> More productively: Why couldn’t we add some sugar for those who want it, e.g.
>
> \keyed d \major { d f e c d }
>
> would result in
>
> { d f# e c# d }
>
> ??

LilyPond's input language has no representation for c-natural as opposed
to c-unkeyed-yet .  Any kind of implementation would be doomed without
that, anyway.  Once you have that, it really becomes a tricky question
of where c-unkeyed-yet would get its final pitch.  And how this is
supposed to behave with regard to transposition: transposing half a step
up and down again should be a do-nothing, so you'd actually also need a
cis-unkeyed-yet .  Do we have a headache yet?

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[David Nalesnik]

On Mon, May 18, 2020 at 11:17 AM Urs Liska  wrote:
[...]
> I think there are only two reliable (and therefore reasonable)
> approaches. Either you encode a pitch at what it "is" (a f sharp is
> always an f sharp) or you encode it at how it is printed (a note in the
> first staff space of a treble clef is encoded as "f" and will be
> rendered as an f in c major but as an f sharp in d major. I really
> dislike this idea but it is done so for example in MEI,

In MEI, true, but actually messier:
@accid Captures a written accidental.
@accid.ges Records the performed pitch inflection.

So, to create valid MIDI output from a MEI document, an F-sharp which
appears with no sharp because there's a sharp in the key signature
would need
to be encoded with @accid.ges.

(Rather annoying if you are creating MEI files programmatically.)

> also Amadeus'
> input language works that way, and a power user insisted to me it is
> superior because it doesn't cause ambiguity but substantially less
> keystrokes).
>
> But having "f" behave depending on what has been encoded before is
> begging for disaster. Copy has already been mentioned, but I
> think it is already harder to *read* in the input file. This by far
> outweighs the saved keystrokes IMHO.
>
> My 2cts
> Urs
>
>

Best,
David Nalesnik

Re: Suggestion to make sharps and flats persistent

[Kieren MacMillan]

Hi David,

> LilyPond's input language has no representation for c-natural
> as opposed to c-unkeyed-yet. Any kind of implementation would be doomed 
> without
> that, anyway.  Once you have that, it really becomes a tricky question
> of where c-unkeyed-yet would get its final pitch.  And how this is
> supposed to behave with regard to transposition: transposing half a step
> up and down again should be a do-nothing, so you'd actually also need a
> cis-unkeyed-yet .  Do we have a headache yet?

\relative gives me a headache.

My point is how is this really different, for those who want to give themselves 
headaches?
Your answer doesn’t convince me it’s all that different — only unadvisable.

Cheers,
Kieren.

Re: Suggestion to make sharps and flats persistent

[Urs Liska]

Am 18. Mai 2020 18:48:04 MESZ schrieb David Kastrup :
>Urs Liska  writes:
>
>> Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
>>> Gianmaria Lari  writes:
>>> 
>>> > I don't know "how much Frescobaldi knows" of the lilypond code the
>>> > user is editing. If it has a logical representation of the source
>>> > code it could be Frescobaldi (and not lilypond) to handle this
>>> > feature and offering to autocorrect, according the key signature
>>> > indicated in the source code, the note you write while you write
>>> > it.  You are in F, you write b and it propose bes.  Maybe with
>>> > different language (never used english for lilypond note input)
>>> > this would be more difficult.
>>> 
>>> As an editing feature, this makes a lot more sense in my book: you
>>> see the effects it has and have the means to correct them
>>> immediately, like with actual graphic input.  But for a batch
>>> processor, this kind of second-thinking is a recipe for trouble, and
>>> the more second-thinking there is, the harder it is to reliably get
>>> results without the corresponding visual feedback.
>>> 
>>
>> I think there are only two reliable (and therefore reasonable)
>> approaches. Either you encode a pitch at what it "is" (a f sharp is
>> always an f sharp) or you encode it at how it is printed (a note in
>> the first staff space of a treble clef is encoded as "f" and will be
>> rendered as an f in c major but as an f sharp in d major. I really
>> dislike this idea but it is done so for example in MEI, also Amadeus'
>> input language works that way, and a power user insisted to me it is
>> superior because it doesn't cause ambiguity but substantially less
>> keystrokes).
>
>It may be superior if you encode a particular graphical output.  But
>LilyPond rather encodes music.  Other outputs are, for example, Midi,
>and coding input in terms of the graphical representation rather than
>the actual music then becomes a problem.  What if the Midi
>interpretation corresponds to a different accidental convention than
>what you imagine your input to be?

Exactly.
Even worse, the argument "encode what you see" makes no sense. You don't see a 
f thst is contextually an f sharp. You see a note head contextualized by a key 
and a clef. And many other conventions if you'd be consequent.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Urs Liska  writes:

> Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
>> Gianmaria Lari  writes:
>> 
>> > I don't know "how much Frescobaldi knows" of the lilypond code the
>> > user is editing. If it has a logical representation of the source
>> > code it could be Frescobaldi (and not lilypond) to handle this
>> > feature and offering to autocorrect, according the key signature
>> > indicated in the source code, the note you write while you write
>> > it.  You are in F, you write b and it propose bes.  Maybe with
>> > different language (never used english for lilypond note input)
>> > this would be more difficult.
>> 
>> As an editing feature, this makes a lot more sense in my book: you
>> see the effects it has and have the means to correct them
>> immediately, like with actual graphic input.  But for a batch
>> processor, this kind of second-thinking is a recipe for trouble, and
>> the more second-thinking there is, the harder it is to reliably get
>> results without the corresponding visual feedback.
>> 
>
> I think there are only two reliable (and therefore reasonable)
> approaches. Either you encode a pitch at what it "is" (a f sharp is
> always an f sharp) or you encode it at how it is printed (a note in
> the first staff space of a treble clef is encoded as "f" and will be
> rendered as an f in c major but as an f sharp in d major. I really
> dislike this idea but it is done so for example in MEI, also Amadeus'
> input language works that way, and a power user insisted to me it is
> superior because it doesn't cause ambiguity but substantially less
> keystrokes).

It may be superior if you encode a particular graphical output.  But
LilyPond rather encodes music.  Other outputs are, for example, Midi,
and coding input in terms of the graphical representation rather than
the actual music then becomes a problem.  What if the Midi
interpretation corresponds to a different accidental convention than
what you imagine your input to be?

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Kieren MacMillan]

Hi all,

> This is just a feature request for laziness with resulting opaqueness. I 
> think it has been requested several times over the years because of other 
> program's bad habits.

I agree with this 100%. That being said…

Are not

\relative f'

and

\fixed c'''

just "feature requests for laziness with resulting opaqueness"?  ;)

More productively: Why couldn’t we add some sugar for those who want it, e.g.

\keyed d \major { d f e c d }

would result in

{ d f# e c# d }

??

We (well… modulo me LOL) don’t get this worked up about how \relative makes 
cut-and-paste a nightmare. Why start now?  ;)

Cheers,
Kieren.

Re: Suggestion to make sharps and flats persistent

[Shane Brandes]

This is just a feature request for laziness with resulting opaqueness. I
think it has been requested several times over the years because of other
program's bad habits.

Shane

On Mon, May 18, 2020 at 12:17 PM Urs Liska  wrote:

> Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
> > Gianmaria Lari  writes:
> >
> > > Hello Paul,
> > >
> > >
> > > > [...]If I'm writing music in F, then I suggest that I be able to
> > > > use *bF*
> > > > as a pitch instead of *bf*. The *F* would indicate that all
> > > > subsequent *b*s
> > > > would be flattened until one is encountered with a different
> > > > accidental or
> > > > until the end of the current music expression. It should have the
> > > > same
> > > > scope as \stemUp or similar. [...]
> > > >
> > >
> > > I don't know "how much Frescobaldi knows" of the lilypond code the
> > > user is
> > > editing. If it has a logical representation of the source code it
> > > could be
> > > Frescobaldi (and not lilypond) to handle this feature and offering
> > > to
> > > autocorrect, according the key signature indicated in the source
> > > code, the
> > > note you write while you write it.
> > > You are in F, you write b and it propose bes.
> > > Maybe with different language (never used english for lilypond note
> > > input)
> > > this would be more difficult.
> >
> > As an editing feature, this makes a lot more sense in my book: you
> > see
> > the effects it has and have the means to correct them immediately,
> > like
> > with actual graphic input.  But for a batch processor, this kind of
> > second-thinking is a recipe for trouble, and the more second-thinking
> > there is, the harder it is to reliably get results without the
> > corresponding visual feedback.
> >
>
> I think there are only two reliable (and therefore reasonable)
> approaches. Either you encode a pitch at what it "is" (a f sharp is
> always an f sharp) or you encode it at how it is printed (a note in the
> first staff space of a treble clef is encoded as "f" and will be
> rendered as an f in c major but as an f sharp in d major. I really
> dislike this idea but it is done so for example in MEI, also Amadeus'
> input language works that way, and a power user insisted to me it is
> superior because it doesn't cause ambiguity but substantially less
> keystrokes).
>
> But having "f" behave depending on what has been encoded before is
> begging for disaster. Copy has already been mentioned, but I
> think it is already harder to *read* in the input file. This by far
> outweighs the saved keystrokes IMHO.
>
> My 2cts
> Urs
>
>
>
>

Re: Suggestion to make sharps and flats persistent

[Urs Liska]

Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
> Gianmaria Lari  writes:
> 
> > Hello Paul,
> > 
> > 
> > > [...]If I'm writing music in F, then I suggest that I be able to
> > > use *bF*
> > > as a pitch instead of *bf*. The *F* would indicate that all
> > > subsequent *b*s
> > > would be flattened until one is encountered with a different
> > > accidental or
> > > until the end of the current music expression. It should have the
> > > same
> > > scope as \stemUp or similar. [...]
> > > 
> > 
> > I don't know "how much Frescobaldi knows" of the lilypond code the
> > user is
> > editing. If it has a logical representation of the source code it
> > could be
> > Frescobaldi (and not lilypond) to handle this feature and offering
> > to
> > autocorrect, according the key signature indicated in the source
> > code, the
> > note you write while you write it.
> > You are in F, you write b and it propose bes.
> > Maybe with different language (never used english for lilypond note
> > input)
> > this would be more difficult.
> 
> As an editing feature, this makes a lot more sense in my book: you
> see
> the effects it has and have the means to correct them immediately,
> like
> with actual graphic input.  But for a batch processor, this kind of
> second-thinking is a recipe for trouble, and the more second-thinking
> there is, the harder it is to reliably get results without the
> corresponding visual feedback.
> 

I think there are only two reliable (and therefore reasonable)
approaches. Either you encode a pitch at what it "is" (a f sharp is
always an f sharp) or you encode it at how it is printed (a note in the
first staff space of a treble clef is encoded as "f" and will be
rendered as an f in c major but as an f sharp in d major. I really
dislike this idea but it is done so for example in MEI, also Amadeus'
input language works that way, and a power user insisted to me it is
superior because it doesn't cause ambiguity but substantially less
keystrokes).

But having "f" behave depending on what has been encoded before is
begging for disaster. Copy has already been mentioned, but I
think it is already harder to *read* in the input file. This by far
outweighs the saved keystrokes IMHO.

My 2cts
Urs

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Gianmaria Lari  writes:

> Hello Paul,
>
>
>> [...]If I'm writing music in F, then I suggest that I be able to use *bF*
>> as a pitch instead of *bf*. The *F* would indicate that all subsequent *b*s
>> would be flattened until one is encountered with a different accidental or
>> until the end of the current music expression. It should have the same
>> scope as \stemUp or similar. [...]
>>
>
> I don't know "how much Frescobaldi knows" of the lilypond code the user is
> editing. If it has a logical representation of the source code it could be
> Frescobaldi (and not lilypond) to handle this feature and offering to
> autocorrect, according the key signature indicated in the source code, the
> note you write while you write it.
> You are in F, you write b and it propose bes.
> Maybe with different language (never used english for lilypond note input)
> this would be more difficult.

As an editing feature, this makes a lot more sense in my book: you see
the effects it has and have the means to correct them immediately, like
with actual graphic input.  But for a batch processor, this kind of
second-thinking is a recipe for trouble, and the more second-thinking
there is, the harder it is to reliably get results without the
corresponding visual feedback.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Gianmaria Lari]

Hello Paul,


> [...]If I'm writing music in F, then I suggest that I be able to use *bF*
> as a pitch instead of *bf*. The *F* would indicate that all subsequent *b*s
> would be flattened until one is encountered with a different accidental or
> until the end of the current music expression. It should have the same
> scope as \stemUp or similar. [...]
>

I don't know "how much Frescobaldi knows" of the lilypond code the user is
editing. If it has a logical representation of the source code it could be
Frescobaldi (and not lilypond) to handle this feature and offering to
autocorrect, according the key signature indicated in the source code, the
note you write while you write it.
You are in F, you write b and it propose bes.
Maybe with different language (never used english for lilypond note input)
this would be more difficult.

Ciao, g.

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Paul McKay  writes:

> Hi David
> I agree that searching backwards would be horrific. I was not thinking it
> would be implemented that way. Suppose one could write something like the
> following:
>
> itsInDmajor = { \override Voice.pitchTweaks = #( (f fs) (c cs) )
>
> music = { \ itsInDmajor d4 f a c d }
>
> and implement it where *pitchTweaks* is a list property of Voice or perhaps
> Score too. If missing or empty, it would do nothing. There would need to be
> 3 methods on this object: *addOrReplace(pitchInput, pitchOutput);
> remove(pitchInput); *and *tweaked Pitch(pitchInput);*
> The *tweakedPitch* method would return the *pitchInput* unless that pitch
> was in the list.
>
> As soon as the parser has recognized something as an input pitch it would
> substitute the tweaked  pitch. Putting fS in the music would be syntactic
> sugar for:
>
>- create  Voice.pitchTweaks if necessary
>- Voice.pitchTweaks.addOrReplace(f, fs)
>
> I can't program Scheme or Python and don't know the internals of LilyPond
> so I'm sure to have got some syntax errors in the above, but I hope it
> explains better what I've been thinking.

Putting aside that we are not talking about "syntax errors" but a lot of
misconceptions about parser and interpretation, we could boil the
essentials down to a pitch's alteration having the ability to not just
be numerical (like 0, 1/2, -1/2) but also "unspecified" (like #f or so),
with the ultimate assignment happening at music execution time.

This would be a complete nightmare for transposition (turning
transposition into some weird key-dependent mixture of ordinary and
modal transposition), tablature, thematic variation (transposing by a
fourth would only work if you also changed key signature, and nobody
does that), pitch comparison (is f-unspecified higher or lower than
e-sharp ?) and a number of other things.  The situation of how input is
done in WYSIWYG programs is somewhat different: generally the program
will have a concept of the actual pitch and changing a key signature
will consequently add/remove/change accidentals of the covered music.

When this is not the case (and if I remember correctly, it wasn't even
in the text-based input of ancient "SCORE"), automated transposition of
motives is not really feasible, nor is changing of accidental notation
conventions (like LilyPond's \accidentalStyle does).

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Paul McKay]

Hi David
I agree that searching backwards would be horrific. I was not thinking it
would be implemented that way. Suppose one could write something like the
following:

itsInDmajor = { \override Voice.pitchTweaks = #( (f fs) (c cs) )

music = { \ itsInDmajor d4 f a c d }

and implement it where *pitchTweaks* is a list property of Voice or perhaps
Score too. If missing or empty, it would do nothing. There would need to be
3 methods on this object: *addOrReplace(pitchInput, pitchOutput);
remove(pitchInput); *and *tweaked Pitch(pitchInput);*
The *tweakedPitch* method would return the *pitchInput* unless that pitch
was in the list.

As soon as the parser has recognized something as an input pitch it would
substitute the tweaked  pitch. Putting fS in the music would be syntactic
sugar for:

   - create  Voice.pitchTweaks if necessary
   - Voice.pitchTweaks.addOrReplace(f, fs)

I can't program Scheme or Python and don't know the internals of LilyPond
so I'm sure to have got some syntax errors in the above, but I hope it
explains better what I've been thinking.
Paul

On Wed, 13 May 2020 at 15:32, David Wright 
wrote:

> On Wed 13 May 2020 at 14:59:10 (+0100), Paul McKay wrote:
>
> > If I'm writing music in F, then I suggest that I be able to use *bF*  as
> a
> > pitch instead of *bf*. The *F* would indicate that all subsequent *b*s
> > would be flattened until one is encountered with a different accidental
> or
> > until the end of the current music expression. It should have the same
> > scope as \stemUp or similar.
>
> The problem with that is that to find out what any particular "b"
> represents, you have to search backwards, note-by-note, looking for
> any such modification that might have been made to a "b" earlier.
>
> Any copy-and-paste manipulations become potential nightmares.
>
> Cheers,
> David.
>

Re: Suggestion to make sharps and flats persistent

[Hans Åberg]

It was mentioned on TwoSetViolin.


> On 15 May 2020, at 10:50, Jacques Menu  wrote:
> 
> Excellent Hans, sending that pun to our flute player, think she’s from Texas…
> 
> 
>> Le 15 mai 2020 à 10:45, Hans Åberg  a écrit :
>> 
>> 
>>> On 15 May 2020, at 00:38, Karlin High  wrote:
>>> 
>>> On 5/14/2020 5:32 PM, antlists wrote:
 Because Americans like to think they speak English (but they are 
 mistaken!). I play crotchets, not quarter-notes. I don't know what other 
 weird language habits the Americans have ... :-)
>>> 
>>> You really don't know? I'm almost certain you'd have some good guesses, 
>>> though. ;-)
>> 
>> The Americans live in an apartment, whereas the British live in A♭!
>> 

Re: Suggestion to make sharps and flats persistent

[Jacques Menu]

Excellent Hans, sending that pun to our flute player, think she’s from Texas…


> Le 15 mai 2020 à 10:45, Hans Åberg  a écrit :
> 
> 
>> On 15 May 2020, at 00:38, Karlin High  wrote:
>> 
>> On 5/14/2020 5:32 PM, antlists wrote:
>>> Because Americans like to think they speak English (but they are 
>>> mistaken!). I play crotchets, not quarter-notes. I don't know what other 
>>> weird language habits the Americans have ... :-)
>> 
>> You really don't know? I'm almost certain you'd have some good guesses, 
>> though. ;-)
> 
> The Americans live in an apartment, whereas the British live in A♭!
> 
> 
> 

Re: Suggestion to make sharps and flats persistent

[Hans Åberg]

> On 15 May 2020, at 00:38, Karlin High  wrote:
> 
> On 5/14/2020 5:32 PM, antlists wrote:
>> Because Americans like to think they speak English (but they are mistaken!). 
>> I play crotchets, not quarter-notes. I don't know what other weird language 
>> habits the Americans have ... :-)
> 
> You really don't know? I'm almost certain you'd have some good guesses, 
> though. ;-)

The Americans live in an apartment, whereas the British live in A♭!

Re: Suggestion to make sharps and flats persistent

[antlists]

On 14/05/2020 23:38, Karlin High wrote:

On 5/14/2020 5:32 PM, antlists wrote:
Because Americans like to think they speak English (but they are 
mistaken!). I play crotchets, not quarter-notes. I don't know what 
other weird language habits the Americans have ... :-)


You really don't know? I'm almost certain you'd have some good guesses, 
though. ;-)


I'm sure they'd love to table our eraser ... :-)

Cheers,
Wol

Re: Suggestion to make sharps and flats persistent

[Karlin High]

On 5/14/2020 5:32 PM, antlists wrote:
Because Americans like to think they speak English (but they are 
mistaken!). I play crotchets, not quarter-notes. I don't know what other 
weird language habits the Americans have ... :-)


You really don't know? I'm almost certain you'd have some good guesses, 
though. ;-)

--
Karlin High
Missouri, USA

Re: Suggestion to make sharps and flats persistent

[antlists]

On 14/05/2020 19:46, David Wright wrote:

Wol gave these "b" people the benefit of the doubt as being "b/h"
people (but why was the American tongue mentioned?).


Because Americans like to think they speak English (but they are 
mistaken!). I play crotchets, not quarter-notes. I don't know what other 
weird language habits the Americans have ... :-)


Cheers,
Wol

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

David Nalesnik  writes:

> I can really only speak of the Midwest, and of undergraduate music
> students.  It is my observation that the habit of calling F-sharps "F"
> goes along with mistakes in sight-reading and in chord spelling.

Let's talk about sharps in order not to think b/h is involved.  I think
it is noteworthy that you can ask "is the F sharp?" in English, but
there is no way you could ask "Ist das F ein Fis?" in German in the same
way.  You can ask that question, but it is like "Is David actually
Paul?" rather than "Is David David Nalesnik?".  Basically the question
is not asking for what kind of F is there but whether mistakenly F had
been written instead of F sharp.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[David Nalesnik]

On Thu, May 14, 2020 at 1:47 PM David Wright  wrote:
>
> On Thu 14 May 2020 at 10:38:59 (+0200), Hans Åberg wrote:
> > > On 14 May 2020, at 03:38, David Wright  wrote:
> > >
> > > I can't say that I've met
> > > English speakers in either the UK or US who use b and h for Bflat and B.
> > > Under what circumstances do you hear it: amateur choirs and orchestral
> > > players, professionals, or in academic duscussions of German music?
> >
> > In general, there is a divide in musical notation in Europe, one is 
> > Germany, and to the north and south and east, and the other, the countries 
> > to the west, France, England, etc.
> >
> > One difference is the note names, H and B in the Germanic tradition [1], 
> > and J.S. Bach used it [2].
>
> Thank you, very useful.
>
> On Thu 14 May 2020 at 07:45:23 (-0500), David Nalesnik wrote:
> > On Wed, May 13, 2020 at 8:39 PM David Wright  
> > wrote:
> > > On Wed 13 May 2020 at 16:35:48 (-0500), David Nalesnik wrote:
> > > > On Wed, May 13, 2020 at 3:34 PM antlists  
> > > > wrote:
> > > > > On 13/05/2020 16:38, David Kastrup wrote:
> > > > > > Given the number of English-speaking LilyPond users who all share 
> > > > > > the
> > > > > > somewhat strange habit of calling a b-flat "b" if there is a flat 
> > > > > > in the
> > > > > > key signature, it is sort of a safe bet that you are not the first 
> > > > > > to
> > > > > > make this kind of proposal.
> > > > >
> > > > > Are these the same ones who call b an h?
> > > > >
> > > > > Certainly for someone who's mother tongue is English (NOT American) 
> > > > > I'd
> > > > > never call b-flat a b because how would I tell whether it's flat or 
> > > > > not :-)
> > > >
> > > > ! hear it a lot in the US.  (And it's often correlated with losing
> > > > sight of the key signature...)
> > >
> > > Assuming ! stands for "I" and not negation, I can't say that I've met
> > > English speakers in either the UK or US who use b and h for Bflat and B.
> > > Under what circumstances do you hear it: amateur choirs and orchestral
> > > players, professionals, or in academic duscussions of German music?
> >
> > Hi David Wright,
> >
> > Once again the name "David" rears its head!  You are mixing my
> > response with David Kastrup's
>
> I think I would have as much difficulty doing that as my email client would.
>
> AIUI David Kastrup lives in Germany, in b/h land, but without any
> context, I don't know whether this meant that he thought
> English-speaking LilyPond users were steeped in the Germanic
> tradition, or just being polite¹, confused², confusing³, or
> just plain incompetent (perhaps implied by "strange habit").

I know that David Kastrup has commented more fully on this topic on
this list before.
>
> Wol gave these "b" people the benefit of the doubt as being "b/h"
> people (but why was the American tongue mentioned?).

I think the choice of b and b-fIat has something to do with the
confusing nature of this thread.  I read Wol's comment about calling
b-flat "b" as a reflection on speakers of English, nothing to "b" and
"h" in German.   David Kastrup's observation about the "somewhat
strange habit of calling a b-flat 'b' if there is a flat in the
key signature" likewise--nothing to do with German practice.
>
> When you, David Nalesnik, wrote "! hear it a lot in the US",
> I wondered where, specifically. I think the main difference
> over here is note and rest lengths. As you might gather from
> the combination of my email domain and my timezone (and yours),
> I take an interest in such differences, even if only as
> post-rehearsal pub-chat⁴.
>

I can really only speak of the Midwest, and of undergraduate music
students.  It is my observation that the habit of calling F-sharps "F"
goes along with mistakes in sight-reading and in chord spelling.

> So I was perplexed by your post about my mixing up your response with
> David K's. Perhaps you might explain the referent of "it", if it's
> not ‘calling a b-flat "b"’.

Sorry!  I misinterpreted you and only added to the confusion!

> Cheers,
> David.

RE: Suggestion to make sharps and flats persistent

[Mark Stephen Mrotek]

Gentlepersons,

Without the "h" would we have Liszt's Fantasy and Fugue on BACH or Schumann's 
Six Fugues on  BACH?

Mark

-Original Message-
From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of David Wright
Sent: Thursday, May 14, 2020 11:46 AM
To: Hans Åberg ; David Nalesnik 
Cc: lilypond-user@gnu.org
Subject: Re: Suggestion to make sharps and flats persistent

On Thu 14 May 2020 at 10:38:59 (+0200), Hans Åberg wrote:
> > On 14 May 2020, at 03:38, David Wright  wrote:
> > 
> > I can't say that I've met
> > English speakers in either the UK or US who use b and h for Bflat and B.
> > Under what circumstances do you hear it: amateur choirs and 
> > orchestral players, professionals, or in academic duscussions of German 
> > music?
> 
> In general, there is a divide in musical notation in Europe, one is Germany, 
> and to the north and south and east, and the other, the countries to the 
> west, France, England, etc.
> 
> One difference is the note names, H and B in the Germanic tradition [1], and 
> J.S. Bach used it [2].

Thank you, very useful.

On Thu 14 May 2020 at 07:45:23 (-0500), David Nalesnik wrote:
> On Wed, May 13, 2020 at 8:39 PM David Wright  
> wrote:
> > On Wed 13 May 2020 at 16:35:48 (-0500), David Nalesnik wrote:
> > > On Wed, May 13, 2020 at 3:34 PM antlists  wrote:
> > > > On 13/05/2020 16:38, David Kastrup wrote:
> > > > > Given the number of English-speaking LilyPond users who all 
> > > > > share the somewhat strange habit of calling a b-flat "b" if 
> > > > > there is a flat in the key signature, it is sort of a safe bet 
> > > > > that you are not the first to make this kind of proposal.
> > > >
> > > > Are these the same ones who call b an h?
> > > >
> > > > Certainly for someone who's mother tongue is English (NOT 
> > > > American) I'd never call b-flat a b because how would I tell 
> > > > whether it's flat or not :-)
> > >
> > > ! hear it a lot in the US.  (And it's often correlated with losing 
> > > sight of the key signature...)
> >
> > Assuming ! stands for "I" and not negation, I can't say that I've 
> > met English speakers in either the UK or US who use b and h for Bflat and B.
> > Under what circumstances do you hear it: amateur choirs and 
> > orchestral players, professionals, or in academic duscussions of German 
> > music?
> 
> Hi David Wright,
> 
> Once again the name "David" rears its head!  You are mixing my 
> response with David Kastrup's

I think I would have as much difficulty doing that as my email client would.

AIUI David Kastrup lives in Germany, in b/h land, but without any context, I 
don't know whether this meant that he thought English-speaking LilyPond users 
were steeped in the Germanic tradition, or just being polite¹, confused², 
confusing³, or just plain incompetent (perhaps implied by "strange habit").

Wol gave these "b" people the benefit of the doubt as being "b/h"
people (but why was the American tongue mentioned?).

When you, David Nalesnik, wrote "! hear it a lot in the US", I wondered where, 
specifically. I think the main difference over here is note and rest lengths. 
As you might gather from the combination of my email domain and my timezone 
(and yours), I take an interest in such differences, even if only as 
post-rehearsal pub-chat⁴.

So I was perplexed by your post about my mixing up your response with David 
K's. Perhaps you might explain the referent of "it", if it's not ‘calling a 
b-flat "b"’.

¹ When in Rome …
² Accidentally switching between bf/b and b/h inappropriately.
³ Calling notes by staff position without regard to key signature.
⁴ Assuming we sing again and pubs are still in business.

Cheers,
David.

Re: Suggestion to make sharps and flats persistent

[David Wright]

On Thu 14 May 2020 at 10:38:59 (+0200), Hans Åberg wrote:
> > On 14 May 2020, at 03:38, David Wright  wrote:
> > 
> > I can't say that I've met
> > English speakers in either the UK or US who use b and h for Bflat and B.
> > Under what circumstances do you hear it: amateur choirs and orchestral
> > players, professionals, or in academic duscussions of German music?
> 
> In general, there is a divide in musical notation in Europe, one is Germany, 
> and to the north and south and east, and the other, the countries to the 
> west, France, England, etc.
> 
> One difference is the note names, H and B in the Germanic tradition [1], and 
> J.S. Bach used it [2].

Thank you, very useful.

On Thu 14 May 2020 at 07:45:23 (-0500), David Nalesnik wrote:
> On Wed, May 13, 2020 at 8:39 PM David Wright  
> wrote:
> > On Wed 13 May 2020 at 16:35:48 (-0500), David Nalesnik wrote:
> > > On Wed, May 13, 2020 at 3:34 PM antlists  wrote:
> > > > On 13/05/2020 16:38, David Kastrup wrote:
> > > > > Given the number of English-speaking LilyPond users who all share the
> > > > > somewhat strange habit of calling a b-flat "b" if there is a flat in 
> > > > > the
> > > > > key signature, it is sort of a safe bet that you are not the first to
> > > > > make this kind of proposal.
> > > >
> > > > Are these the same ones who call b an h?
> > > >
> > > > Certainly for someone who's mother tongue is English (NOT American) I'd
> > > > never call b-flat a b because how would I tell whether it's flat or not 
> > > > :-)
> > >
> > > ! hear it a lot in the US.  (And it's often correlated with losing
> > > sight of the key signature...)
> >
> > Assuming ! stands for "I" and not negation, I can't say that I've met
> > English speakers in either the UK or US who use b and h for Bflat and B.
> > Under what circumstances do you hear it: amateur choirs and orchestral
> > players, professionals, or in academic duscussions of German music?
> 
> Hi David Wright,
> 
> Once again the name "David" rears its head!  You are mixing my
> response with David Kastrup's

I think I would have as much difficulty doing that as my email client would.

AIUI David Kastrup lives in Germany, in b/h land, but without any
context, I don't know whether this meant that he thought
English-speaking LilyPond users were steeped in the Germanic
tradition, or just being polite¹, confused², confusing³, or
just plain incompetent (perhaps implied by "strange habit").

Wol gave these "b" people the benefit of the doubt as being "b/h"
people (but why was the American tongue mentioned?).

When you, David Nalesnik, wrote "! hear it a lot in the US",
I wondered where, specifically. I think the main difference
over here is note and rest lengths. As you might gather from
the combination of my email domain and my timezone (and yours),
I take an interest in such differences, even if only as
post-rehearsal pub-chat⁴.

So I was perplexed by your post about my mixing up your response with
David K's. Perhaps you might explain the referent of "it", if it's
not ‘calling a b-flat "b"’.

¹ When in Rome …
² Accidentally switching between bf/b and b/h inappropriately.
³ Calling notes by staff position without regard to key signature.
⁴ Assuming we sing again and pubs are still in business.

Cheers,
David.

Re: [OT] Camp David (was "Re: Suggestion to make sharps and flats persistent")

[Kevin Cole]

And this, of course, reminds me of...

(Soft knocks at the door)
CHONG: Who is it?
CHEECH: It's me, Dave. Open up, man, I got the stuff.
(More knocks)
CHONG: Who is it?
CHEECH: It's me, Dave, man. Open up, I got the stuff.
CHONG: Who?
CHEECH: It's, Dave, man. Open up, I think the cops saw me come in here.
(More knocks)
CHONG: Who is it?
CHEECH: It's, Dave, man. Will you open up, I got the stuff with me.
CHONG: Who?
CHEECH: Dave, man. Open up.
CHONG: Dave?
CHEECH: Yeah, Dave. C'mon, man, open up, I think the cops saw me.
CHONG: Dave's not here.
CHEECH: No, man, I'm Dave, man.
(Sharp knocks at the door)
CHEECH: Hey, c'mon, man.
CHONG: Who is it?
CHEECH: It's Dave, man. Will you open up? I got the stuff with me.
CHONG: Who?
CHEECH: Dave, man. Open up.
CHONG: Dave?
CHEECH: Yeah, Dave.
CHONG: Dave's not here.
CHEECH: What the hell? No, man, I am Dave, man. Will you...
(More knocks)
CHEECH: C'mon! Open up the door, will you? I got the stuff with me, I
think the cops saw me.
CHONG: Who is it?
CHEECH: Oh, what the hell is it... c'mon. Open up the door! It's Dave!
CHONG: Who?
CHEECH: Dave! D-A-V-E! Will you open up the goddam door!
CHONG: Dave?
CHEECH: Yeah, Dave!
CHONG: Dave?
CHEECH: Right, man. Dave. Now will you open up the door?
CHONG: Dave's not here

Re: [OT] Camp David (was "Re: Suggestion to make sharps and flats persistent")

[Karlin High]

On 5/14/2020 8:12 AM, Kieren MacMillan wrote:

If I remember correctly, there were 16 Davids (17, if you count the counselor).


Only 6 more, and they could have had an enactment of the Dr. Seuss "Too 
Many Daves" poem.



--
Karlin High
Missouri, USA

[OT] Camp David (was "Re: Suggestion to make sharps and flats persistent")

[Kieren MacMillan]

Hi David(s),

> Once again the name "David" rears its head!  You are mixing my
> response with David Kastrup's
> 
> This all reminds me of my undergraduate days in the late 80s/early
> 90s.  I remember feeling a little affronted by a flyer for a party
> that started "Hey Dave!" since of course I turned to look...  There
> were so many "Davids" on campus.  (Apparently it was the most common
> US name in my birth year.)

I attended the Interlochen Arts Camp. One summer, in the late 1970s (before my 
time there), the office manager in the High School Boys Division decided to 
play a joke on a cabin counselor named David: they filled his cabin entirely 
with campers named David! If I remember correctly, there were 16 Davids (17, if 
you count the counselor). They called it "Camp David". There’s still a board 
mounted in that cabin signed by all the Davids.

Cheers,
Kieren.

Re: Suggestion to make sharps and flats persistent

[David Nalesnik]

On Wed, May 13, 2020 at 8:39 PM David Wright  wrote:
>
> On Wed 13 May 2020 at 16:35:48 (-0500), David Nalesnik wrote:
> > On Wed, May 13, 2020 at 3:34 PM antlists  wrote:
> > >
> > > On 13/05/2020 16:38, David Kastrup wrote:
> > > > Given the number of English-speaking LilyPond users who all share the
> > > > somewhat strange habit of calling a b-flat "b" if there is a flat in the
> > > > key signature, it is sort of a safe bet that you are not the first to
> > > > make this kind of proposal.
> > >
> > > Are these the same ones who call b an h?
> > >
> > > Certainly for someone who's mother tongue is English (NOT American) I'd
> > > never call b-flat a b because how would I tell whether it's flat or not 
> > > :-)
> > >
> >
> > ! hear it a lot in the US.  (And it's often correlated with losing
> > sight of the key signature...)
>
> Assuming ! stands for "I" and not negation, I can't say that I've met
> English speakers in either the UK or US who use b and h for Bflat and B.
> Under what circumstances do you hear it: amateur choirs and orchestral
> players, professionals, or in academic duscussions of German music?
>
> Cheers,
> David.

Hi David Wright,

Once again the name "David" rears its head!  You are mixing my
response with David Kastrup's

This all reminds me of my undergraduate days in the late 80s/early
90s.  I remember feeling a little affronted by a flyer for a party
that started "Hey Dave!" since of course I turned to look...  There
were so many "Davids" on campus.  (Apparently it was the most common
US name in my birth year.)

Best,
David Nalesnik

Re: Suggestion to make sharps and flats persistent

[Hans Åberg]

> On 14 May 2020, at 03:38, David Wright  wrote:
> 
> I can't say that I've met
> English speakers in either the UK or US who use b and h for Bflat and B.
> Under what circumstances do you hear it: amateur choirs and orchestral
> players, professionals, or in academic duscussions of German music?

In general, there is a divide in musical notation in Europe, one is Germany, 
and to the north and south and east, and the other, the countries to the west, 
France, England, etc.

One difference is the note names, H and B in the Germanic tradition [1], and 
J.S. Bach used it [2].

Another is how to name meters, duple and triple.

1. https://en.wikipedia.org/wiki/B_(musical_note)
2. https://en.wikipedia.org/wiki/BACH_motif

Re: Suggestion to make sharps and flats persistent

[David Wright]

On Wed 13 May 2020 at 16:35:48 (-0500), David Nalesnik wrote:
> On Wed, May 13, 2020 at 3:34 PM antlists  wrote:
> >
> > On 13/05/2020 16:38, David Kastrup wrote:
> > > Given the number of English-speaking LilyPond users who all share the
> > > somewhat strange habit of calling a b-flat "b" if there is a flat in the
> > > key signature, it is sort of a safe bet that you are not the first to
> > > make this kind of proposal.
> >
> > Are these the same ones who call b an h?
> >
> > Certainly for someone who's mother tongue is English (NOT American) I'd
> > never call b-flat a b because how would I tell whether it's flat or not :-)
> >
> 
> ! hear it a lot in the US.  (And it's often correlated with losing
> sight of the key signature...)

Assuming ! stands for "I" and not negation, I can't say that I've met
English speakers in either the UK or US who use b and h for Bflat and B.
Under what circumstances do you hear it: amateur choirs and orchestral
players, professionals, or in academic duscussions of German music?

Cheers,
David.

Re: Suggestion to make sharps and flats persistent

[David Nalesnik]

On Wed, May 13, 2020 at 3:34 PM antlists  wrote:
>
> On 13/05/2020 16:38, David Kastrup wrote:
> > Given the number of English-speaking LilyPond users who all share the
> > somewhat strange habit of calling a b-flat "b" if there is a flat in the
> > key signature, it is sort of a safe bet that you are not the first to
> > make this kind of proposal.
>
> Are these the same ones who call b an h?
>
> Certainly for someone who's mother tongue is English (NOT American) I'd
> never call b-flat a b because how would I tell whether it's flat or not :-)
>

! hear it a lot in the US.  (And it's often correlated with losing
sight of the key signature...)

Interestingly, a separation between "note name" and "alteration" is
part of LilyPond internals:

Function: ly:make-pitch octave note alter
octave is specified by an integer, zero for the octave containing
middle C. note is a number indexing the global default scale, with 0
corresponding to pitch C and 6 usually corresponding to pitch B.
Optional alter is a rational number of 200-cent whole tones for
alteration

David N.

Re: Suggestion to make sharps and flats persistent

[antlists]

On 13/05/2020 16:38, David Kastrup wrote:

Given the number of English-speaking LilyPond users who all share the
somewhat strange habit of calling a b-flat "b" if there is a flat in the
key signature, it is sort of a safe bet that you are not the first to
make this kind of proposal.


Are these the same ones who call b an h?

Certainly for someone who's mother tongue is English (NOT American) I'd 
never call b-flat a b because how would I tell whether it's flat or not :-)


Cheers,
Wol

Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Paul McKay  writes:

> Hi
> I can't help thinking that this has probably been suggested before, but in
> case it hasn't I've set out my thoughts here. In the past I've used
> Sibelius and I like the way that it applies sharps and flats from the key
> signature automatically. This really doesn't seem to conform to the way
> Lilypond does things, but my suggested change, I think, should do much the
> same. I habitually use English as the Lilypond \language, so please bear
> with me.
>
> If I'm writing music in F, then I suggest that I be able to use *bF*  as a
> pitch instead of *bf*. The *F* would indicate that all subsequent *b*s
> would be flattened until one is encountered with a different accidental or
> until the end of the current music expression.

<< \new Staff \new Voice { b { b \repeat unfold bF b } b } { b } >>

What is the current music expression?  Where does it end?

> It should have the same scope as \stemUp or similar.

\stemUp does not have a scope.  It is an override.  Its effects are
bound to the current _context_ which may extend into music expressions
defined arbitrarily far behind or before the current music expression.

The effects of a \key statement extend to the current _Staff_ context
even if given only in a single Voice.  It decides during iteration which
of the pitches in the music is in need of an accidental and which not,
according to accidental rules.

> As I see it, the changes in the parser would be small: we would need
> to introduce an explicit 'natural' indication and to recognize
> capitalized accidentals. (In the case of accidentals with more than
> one letter, then I leave it to the implementors to decide whether all
> need to be capitalized or just one.)

Before one even states "the changes in the parser would be small", one
has to figure out whether it is in the interest of the user to implement
this kind of thing in the _parser_: typesetting transposition is
implemented as a music function and thus basically operates during
parsing parser, midi transposition happens during iteration, repeat
chords and pitching of unpitched rhythms happens during scorification,
relative mode works via a music function and consequently during
parsing, pitches without duration get the default duration
parser-internally and so on: this is half a dozen can of worms that is
comparatively tricky to distribute across LilyPond in a manner where it
tends not to interfere with user expectations all too much.


What's with

music = { b a c bS }

{ b bF \music b b }

for example?  Which b should be natural? Which b should be sharp ?
Which flat?

> You will notice that although the key signature will be the most
> probable reason for using this idea, I'm simply suggesting an
> extension to the way of expressing which pitches I want in a way which
> is independent of key signature and in keeping with the way Lilypond
> does this (at least the way I use it  ) It also means that all
> current scores continue to work without modifications.

Given the number of English-speaking LilyPond users who all share the
somewhat strange habit of calling a b-flat "b" if there is a flat in the
key signature, it is sort of a safe bet that you are not the first to
make this kind of proposal.

I will not rule out that at some point of time LilyPond's notename
implementation will be flexible enough that one could implement one
basic version of that idea on top of it.  It would not make it less of a
bad idea, however.

-- 
David Kastrup

Re: Suggestion to make sharps and flats persistent

[Valentin Villenave]

On 5/13/20, Paul McKay  wrote:
> If I'm writing music in F, then I suggest that I be able to use *bF*  as a
> pitch instead of *bf*. The *F* would indicate that all subsequent *b*s
> would be flattened until one is encountered with a different accidental or
> until the end of the current music expression.

Interesting.  It’s never been The LilyPond Way® too assume what the
user means (much like you wouldn’t expect a simple notepad to fix your
spelling for you, although I’m sure Microsoft has thought of it at
some point).

Something similar to what you’re suggesting could be implemented
without modifying the parser, for example with a fairly simple music
function or a Scheme engraver:



persistentAccidentals =
#(define-music-function (music) (ly:music?)
   (let ((alt-alist '())
 (m (ly:music-deep-copy music)))
 (music-map
  (lambda (note)
(let ((pitch (ly:music-property note 'pitch))
  (force? (ly:music-property note 'force-accidental)))
  (if (ly:pitch? pitch)
  (let* ((alt (ly:pitch-alteration pitch))
 (n (ly:pitch-notename pitch))
 (o (ly:pitch-octave pitch))
 (mem-alt (assoc-get n alt-alist)))
(if (eq? force? #t)
(set! alt-alist
  (assoc-remove! alt-alist n))

(if (= alt 0)
(if mem-alt
(ly:music-set-property!
 note 'pitch
 (ly:make-pitch o n mem-alt)))
(set! alt-alist
  (assoc-set! alt-alist n alt))
  note))
  m)
 m))

\persistentAccidentals \relative c' {
  c des e fis g f e f! e d' g, d
}



#(define Persistent_accidentals_translator
   (lambda (context)
 (let ((alt-alist '()))
   (make-engraver
(listeners
 ((note-event engraver event)
  (let ((note (ly:prob-property event 'music-cause)))
(if (ly:music? note)
(let ((pitch (ly:music-property note 'pitch))
  (force? (ly:music-property note 'force-accidental)))
  (if (ly:pitch? pitch)
  (let* ((alt (ly:pitch-alteration pitch))
 (n (ly:pitch-notename pitch))
 (o (ly:pitch-octave pitch))
 (mem-alt (assoc-get n alt-alist)))
(if (eq? force? #t)
(set! alt-alist
  (assoc-remove! alt-alist n))
(if (= alt 0)
(if mem-alt
(ly:music-set-property!
 note 'pitch
 (ly:make-pitch o n mem-alt)))
(set! alt-alist
  (assoc-set! alt-alist n alt))
  note)

\score {
  \new Staff \relative c' { c des e fis g f e f! e d' g, d }
  \layout {
\context {
  \Voice
  \consists #Persistent_accidentals_translator
}
  }
}



V.

Re: Suggestion to make sharps and flats persistent

[David Wright]

On Wed 13 May 2020 at 14:59:10 (+0100), Paul McKay wrote:

> If I'm writing music in F, then I suggest that I be able to use *bF*  as a
> pitch instead of *bf*. The *F* would indicate that all subsequent *b*s
> would be flattened until one is encountered with a different accidental or
> until the end of the current music expression. It should have the same
> scope as \stemUp or similar.

The problem with that is that to find out what any particular "b"
represents, you have to search backwards, note-by-note, looking for
any such modification that might have been made to a "b" earlier.

Any copy-and-paste manipulations become potential nightmares.

Cheers,
David.

Suggestion to make sharps and flats persistent

[Paul McKay]

Hi
I can't help thinking that this has probably been suggested before, but in
case it hasn't I've set out my thoughts here. In the past I've used
Sibelius and I like the way that it applies sharps and flats from the key
signature automatically. This really doesn't seem to conform to the way
Lilypond does things, but my suggested change, I think, should do much the
same. I habitually use English as the Lilypond \language, so please bear
with me.

If I'm writing music in F, then I suggest that I be able to use *bF*  as a
pitch instead of *bf*. The *F* would indicate that all subsequent *b*s
would be flattened until one is encountered with a different accidental or
until the end of the current music expression. It should have the same
scope as \stemUp or similar.

As I see it, the changes in the parser would be small: we would need to
introduce an explicit 'natural' indication and to recognize capitalized
accidentals. (In the case of accidentals with more than one letter, then I
leave it to the implementors to decide whether all need to be capitalized
or just one.)

You will notice that although the key signature will be the most probable
reason for using this idea, I'm simply suggesting an  extension to the way
of expressing which pitches I want in a way which is independent of key
signature and in keeping with the way Lilypond does this (at least the way
I use it  ) It also means that all current scores continue to work
without modifications.

Paul McKay