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

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


> Le 15 mai 2020 à 10:45, Hans Åberg <[hidden email]> a écrit :
>
>
>> On 15 May 2020, at 00:38, Karlin High <[hidden email]> 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♭!
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Hans Åberg-2
It was mentioned on TwoSetViolin.


> On 15 May 2020, at 10:50, Jacques Menu <[hidden email]> wrote:
>
> Excellent Hans, sending that pun to our flute player, think she’s from Texas…
>
>
>> Le 15 mai 2020 à 10:45, Hans Åberg <[hidden email]> a écrit :
>>
>>
>>> On 15 May 2020, at 00:38, Karlin High <[hidden email]> 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♭!
>>



Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Plmcky
In reply to this post by David Wright
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Kastrup
Paul McKay <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Gianmaria Lari
In reply to this post by Plmcky
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 bs 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.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Kastrup
Gianmaria Lari <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Urs Liska-3
Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:

> Gianmaria Lari <[hidden email]> 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&paste 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



Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Shane Brandes-2
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 <[hidden email]> wrote:
Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
> Gianmaria Lari <[hidden email]> 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&paste 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



Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

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

Re: Suggestion to make sharps and flats persistent

David Kastrup
In reply to this post by Urs Liska-3
Urs Liska <[hidden email]> writes:

> Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
>> Gianmaria Lari <[hidden email]> 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

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 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Urs Liska-3
In reply to this post by David Kastrup


Am 18. Mai 2020 18:48:04 MESZ schrieb David Kastrup <[hidden email]>:

>Urs Liska <[hidden email]> writes:
>
>> Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
>>> Gianmaria Lari <[hidden email]> 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.

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 David Kastrup
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.
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Urs Liska-3
In reply to this post by Kieren MacMillan-4


Am 18. Mai 2020 18:33:09 MESZ schrieb Kieren MacMillan <[hidden email]>:

>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.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

David Nalesnik
In reply to this post by Urs Liska-3
On Mon, May 18, 2020 at 11:17 AM Urs Liska <[hidden email]> 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&paste 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

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,
>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion to make sharps and flats persistent

Gianmaria Lari
In reply to this post by Kieren MacMillan-4

[...]. 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

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

Re: Suggestion to make sharps and flats persistent

antlists
In reply to this post by Kieren MacMillan-4
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
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

  <pseudo>
     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.
123