Suggestion to make sharps and flats persistent

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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=[hidden email]] On Behalf Of antlists
Sent: Monday, May 18, 2020 12:22 PM
To: [hidden email]
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


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Flaming Hakama by Elaine
In reply to this post by Plmcky
---------- Forwarded message ----------
From: antlists <[hidden email]>
To: [hidden email]
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"
[hidden email]
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Kieren MacMillan-4
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^1000000
(and, yes, I understand the mathematical irony there LOL)

Cheers,
Kieren.
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

antlists
In reply to this post by Mark Stephen Mrotek
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=[hidden email]] On Behalf Of antlists
> Sent: Monday, May 18, 2020 12:22 PM
> To: [hidden email]
> 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
>

Reply | Threaded
Open this post in threaded view
|

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:[hidden email]]
Sent: Monday, May 18, 2020 4:33 PM
To: Mark Stephen Mrotek <[hidden email]>; [hidden email]
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=[hidden email]] On Behalf
> Of antlists
> Sent: Monday, May 18, 2020 12:22 PM
> To: [hidden email]
> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Kieren MacMillan-4
In reply to this post by antlists
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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Nalesnik
On Mon, May 18, 2020 at 8:20 PM Kieren MacMillan
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Kieren MacMillan-4
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.
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Nalesnik
Kieren,

On Tue, May 19, 2020 at 9:22 AM Kieren MacMillan
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Kastrup
In reply to this post by Kieren MacMillan-4
Kieren MacMillan <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Carl Sorensen
In reply to this post by Plmcky



> ---------- Forwarded message ----------
> From: Kieren MacMillan <[hidden email]>
> To: David Nalesnik <[hidden email]>
> Cc: Lilypond-User Mailing List <[hidden email]>
> 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




Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Kastrup
Carl Sorensen <[hidden email]> writes:

>> ---------- Forwarded message ----------
>> From: Kieren MacMillan <[hidden email]>
>> To: David Nalesnik <[hidden email]>
>> Cc: Lilypond-User Mailing List <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Carl Sorensen


On Tue, May 19, 2020 at 4:13 PM David Kastrup <[hidden email]> wrote:
Carl Sorensen <[hidden email]> writes:

>> ---------- Forwarded message ----------
>> From: Kieren MacMillan <[hidden email]>
>> To: David Nalesnik <[hidden email]>
>> Cc: Lilypond-User Mailing List <[hidden email]>
>> 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
 
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Plmcky
In reply to this post by Gianmaria Lari

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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Fr. Samuel Springuel
> On 20 May, 2020, at 9:43 AM, Paul McKay <[hidden email]> 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 ☧ ΧΡΙΣΤΟΣ


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Kastrup
"Fr. Samuel Springuel" <[hidden email]> writes:

>> On 20 May, 2020, at 9:43 AM, Paul McKay <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Fr. Samuel Springuel


> On 20 May, 2020, at 10:22 AM, David Kastrup <[hidden email]> 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 ☧ ΧΡΙΣΤΟΣ


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Kastrup
"Fr. Samuel Springuel" <[hidden email]> writes:

>> On 20 May, 2020, at 10:22 AM, David Kastrup <[hidden email]> 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

123