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 <address@hidden> wrote:

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