Re: Tools for harmonic analysis (Riemann style)

[Urs Liska]

Hi Lukas and all,

Am 26.04.19 um 23:15 schrieb Lukas-Fabian Moser:

Hi,

but I have to some degree lost track of
much of the discussion of the last 20 years, and when I actively worked
with that kind of written harmonic analysis (while at the
Musikhochschule) I didn't have much of a scholarly mind-set. So in fact.
I was *not* aware of all this...

at the Musikhochschule Mannheim, we were only taught some basic roman
numeral stuff. IMO, that's a shame. Now being a high school teacher, I know
what I was missing back then.
OK, enough complaining...  ;-)

If this was a "Schulmusik" course (music education for aspiring high school teachers), at least your instructors probably could assume a fairly even-distributed amount and flavour of prerequisites in the participants, so it was easy for them: They could simply teach the style the liked most :-). Not that I would endorse this...

(I'd be interested in what you're missing and at which point in your high school teaching you feel the need for the respective harmonic analysis tools, but maybe that's a matter for a private conversation.)

In my teaching for students majoring in their respective instruments, I almost always have very international classes, and I make a habit of letting them explain to me the way they learned harmony in their respective home countries. The general tendency seems to be that in most countries, roman numerals are used (with differences with respect to whether there's an upper-/lowercase distinction and how inversions are being expressed - IIb vs. II6 vs. ii6 and so on), and that people from German-speaking countries have either i) no previous knowledge at all or ii) are acquainted with "German" (Malerian) function symbols. But there's lots of other variants - a student from China once showed me "his" symbols that were something like S ii 56 (hence, combining functional analysis, roman numeral and figured bass symbols in one huge symbol), and someone from the Baltic states showed my a flavour of "Riemannian" functional symbols with lots of juxtapositions ("ST" with strikethrough) that I never saw anywhere else...

I think the problem with most students' (and of course also scholars') point of view is that many (most?) people don't consider the system they grew up with as what it is: an (one out of many) attempt at rationalizing musical reality in an analytical system. Each of these systems has their pros and cons, and most systems are tailored to specific repertoires against which they were developed. In my experience people from the "German" fraction look down to the roman numerals because they seem like mere descriptions without interpretation of the harmony's "functional" relation to the surrounding music. Seen from the other side functional analysis suffers from *pretending* such a clear functional relation to be present and tangible.

Back to topic: I think it would be a reasonable first step to try and get an overview of some important existing variaties of analysis symbols and try to decide which of them should be supported in what way. This is a project I'd volunteer to be involved in - but I warn that, at least in Germany, each author tends to invent his/her special symbols...

Having followed this conversation that I started I came to the conclusion that I would like to see a new module in openLilyLib's `analysis` package (complementing `arrows` and `frames`). In order to be generally useful this would have to have the following features:

• Provide a reasonable set of "major modes" (e.g. roman numerals vs. Malerian function symbols)
• Of course provide a convenient input syntax
  
• Be configurable in detail, e.g. let the user either choose or design the style of strikethrough, or the exact positioning of double characters.
• Be extensible to allow custom extensions or custom symbols to be integrated

I would vote for a LilyPond-based solution, with markups and/or stencil overrides (or probably both), with the expressed intent to provide a parallel development for LaTeX. I'll comment on that separately.

In order to be useful I agree that it should start with collecting and discussing the styles one might need to address, only then can we reasonably think about how the basic coverage and the extensibility should be structured.

I'm not fully clear about the best way this discussion should be structured, but probably the best *place* is https://github.com/openlilylib/analysis, the issue tracker, maybe the Wiki?, and a "project" I've created (https://github.com/openlilylib/analysis/projects/1). This discussion should definitely not be limited to the LilyPond community and mailing list, so when we have an initial place it would be good to reach out to other communities, which will provide us with valuable input - and at the same time give an opportunity to engage with these communities and have them talk about LilyPond ...

One personal caveat: while I actually need some of that right now the project I'm needing it for must have absolute priority for the next about three months, so I definitely can't engage with substantial amounts of time. I hope the project is able to attract enough people so it doesn't depend on me pushing it forward...

Best
Urs

Lukas


_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user