|
Am Freitag, den 26.06.2020, 13:14 +0200 schrieb Lukas-Fabian Moser:
Hi Urs,
thanks for the improvements to my code! (I tend to stop thinking
about it as soon as it works for my case, which always leaves lots
of room for improvement.)
Seems to be the opposite of my approach. I'm always starting to think in terms of reusability and "packages" right away - leading to working code much later than would be good ;-)
The only remedy I can see right now would be to deal with this in an after-line-breaking stencil. From there we could iterate over the whole system and check the maximum number of actually used layers. The result should be cached so this process is done only once per system. However, this won't always work because the context may not have been pushed sufficiently far down in situations like the attached example.
This exceeds my current understanding of LilyPond coding, I'm
afraid.
I've made a number of improvements to your code:
1) reverseFigures creates a new music _expression_, from which you later retrieve the 'elements, which is unnecessary. (I renamed it to parse- signature
Yes, thank you - I only wanted to "quickly re-use the existing code"
without bothering about possible shortcuts.
2) The figures do have their durations included, so we can retrieve them *here* and reuse that information later when generating the BassFigureEvent for the bass step markup.
Yes, that occurred to me later. However, I think there is still a
problem (I was working on a similar problem when your code
arrived):
2a) Instead of \none I rewrote \scaledeg to accept either a figure signature or a duration. This gives a nice interface where you can just specify a duration for an empty figure.
<<
\new Staff { \clef bass c2 d4 e4~ e f2 g4 }
\figures {
\scaledeg 1 <5 3>2
\scaledeg 2 <6>4
\scaledeg 3 2
\scaledeg 4 <6 5> % Here the user would expect to get a
duration of 2, but gets 4
\scaledeg 4 <6 5>4
}
>>
The parser does not seem to take notice of durations when they
are used as function parameters.
Which is pretty plausible: How should LilyPond know what that duration is used for and whether it should be considered for the next parsed music or not. The function might as well convert that function argument to a label and print it ...
I do not know how to handle this
- it comes down to the question: How to read/write the "current
assumed duration" from the parser?
I would evade the issue by simply stating that one should *always* give an explicit duration.
As for lobbying with the music theory folks:
- They are going to ask for "raised"/"lowered" scale steps.
(Using arrows, flat/sharp etc.) I even used relative solmization
syllables for this in my teching instead of numbers... ("fa with
a 642").
- The set of people interested in using this does not scale well
with physical distance from the Freiburg theory department ;-).
It's not as widespread as one might be induced to believe from
looking at their local practice... But maybe it's becoming more
common over time. At least there's plenty of people with a
Freiburg education getting teaching jobs elsewhere.
Well, my plan for it is to have a growing OLL module analysis.harmony with submodules analysis.harmony.functional, analysis.harmony.förster, analysis.harmony.roman-numerals etc. All of this should live within a consistent user interface, and each module should be appropriately configurable to accomodate the needs of different theorists.
Right now you can imagine that I have an incentive to please the Freiburg incarnation of Förster's scale degree analysis (although I'd in the same effort would provide the "pure" version too (which is of course easier to achieve). The next GMTH congress will probably feature a significant "digital" section or presentation, and I'm interested in LilyPond taking a part in this.
Best
Urs
Best
Lukas
|