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 <lily...@lionunicorn.co.uk>
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.
>
