search

MarkGotham / When-in-Rome

meta-corpus of and code library for the functional harmonic analysis of music
58 stars 12 forks source link

External analyses: Upstream versions and edits #98

Open mscuthbert opened 6 days ago

mscuthbert commented 6 days ago

Hi! Just curious about a few differences between the chorales here and the version in the m21 corpus (for the 20 there). I'm seeing in n. 17 that m.2 in this corpus begins with ii2 (=42) which is correct if we're assuming the bass was doubled an octave lower in organ or bass viol etc. In the score w/o that assumption it's ii4/3

The music21 corpus reads ii4/3 here. The When-in-Rome reads ii2 -- just wondering which one reflects Dmitri's more recent analysis of the piece and the view of the corpus. Thanks!

And thanks Mark for putting all this together!

MarkGotham commented 4 days ago

Dear Myke ( @mscuthbert ),

Hi!

Thanks for this notes and the 3x PR contributions!

I'll respond to all here as they're closely linked (in my view) under the new issue title.

Bach (DT)

Wrt Bach, Dmitri's analyses are theoretically here, though that link seems to be currently failing. Even when it worked it was (as I recall) a zip file, with no individual file linking possible.

There's also some ambiguity about the relative role of DT and his automation in some of these cases.

That being the case, if you find a clear error then please do go ahead and fix it here.

Corelli, Lizst (DCML)

Turning to your PRs (#99 , #100 , #101 ), as you've noted, these are direct conversions of the DCML analyses. I'm content to merge them, with the following caveats:

  1. You mention low quality source analyses. As these are direct conversions, it would be best for changes to the analysis to take place upstream on the DCML source.
  2. When .txt analyses fail to parse in music21, that's an issue with the converter – the real fix needs to be on the converter and not the individual output files. Naturally, any help with the converter is more than welcome, especially from those of us that co-created it over the years (you, me, and tagging @malcolmsailor in here too).
  3. If there are changes upstream and the converter is re-run, this good work risks being lost.

This is all probably obvious, but good to get documented somewhere.

Summary

In summary, the overall topic here is: (probability of) upstream updates and a local plan for edits.

I can't speak for others but I think the following is the situation:

Ok, that's all for now.

Thanks again for your interest and contributions!

mscuthbert commented 4 days ago

Wow -- we're totally on the same page on all this.

We're at the same conclusion:

(1) there's something valuable for music21 to be able to parse every analysis.txt file -- so that's why I'm seeing merging. Very important, even if sometimes we're going to need to make judgement calls on correct DCML for (a) cadenzas [beat placement] and (b) multiple conflicting labels.

(2) there's an error in the DCML converter about the last beat of some time signatures that weren't the first time-signature in the piece. I took a few seconds to poke around and didn't find the answer. But I'm hoping that the PR files point others (or me later) towards the general problem and perhaps solution. I can only guess that somewhere there's a track of "last beat" (I'm surprised by this, but it's the only conclusion I can think of that fits the evidence) which works 99% of the time but fails on 2nd+ TS in a piece.

(3) there's also a small bug around a section change that involves a TS change (almost always, but not always-always, when the TS change happens mid-measure, like going from 3/4 to 9/8 but the change happening between beats 2 and 3). I looked at the code for a bit, but 9/10 times it was easier (and still correct) to move the Time Signature: 3/X back one measure.

(4) Liszt -- yeah, this was the one place where the fixes weren't completely musically sophisticated because when I looked at neighboring measures I saw tons of mistakes (mostly incorrect--and not "judgement call" incorrect--inversions). I had a hard time locating one (computer) error because none of the down-beat RNs (V7) corresponded to what I saw (mostly V65).

(5) I saw the notes that said "Updated Automatically from ...DCML...tsv... and thought "oh that should go there"...but I hadn't seen enough activity there, and figured this is the project that cares about Music21 parsing, so let me fix it here first, and maybe later I can understand TSV enough to either fix the (Python) systematic error or try to convince Europe that there's a mistake.

I definitely see that there's a need in RomanText specification and then in the m21 implementation to keep tract of ambiguity/different editors. I think that the note.editorial object should be good enough for this, but I'm not sure.

Next message (w/o commentary so it's easier to copy->paste->run -- is my RNText/TSV/etc. to standardized representation updater, which I've been using (in my personal life/spare-time) to find various patterns of chords and generate relative frequency.

MarkGotham commented 4 days ago

Thanks Myke!

Wrt find various patterns of chords and generate relative frequency there's a good bit of functionality here, including some new robust definitions.

FWIW, 'Chromatic chords in theory and practice' reports on much of this:

Contributions (and critique!) welcome!

johentsch commented 4 days ago

DCML: probably open to suggestions, but with Johannes (@johentsch) having left DCML, so the update status is ambiguous there too. Jo, can you update?

Still maintaining the corpora. Issues/PRs under the respective repos always welcome!

mscuthbert commented 4 days ago

Mark: great stuff. The paper link above is wrong I think. It's at https://durham-repository.worktribe.com/OutputFile/2046704 for anyone else reading this.