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
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
