Quantitative Gesualdo

To further my investigations into Gesualdo's use of accidentals, I've
written a Python script to do the conversion from 12 pitch classes to note
names. It uses the following rules:

1) Gamut from Gb to B#
2) For each chord, choose the version with the smallest span on the spiral
of fifths.
3) Where more than one equally good chord lies within the gamut, choose
the one which has the smallest average interval on the spiral of fifths
between it and the previous chord.
4) Seed with a D for rule 3.

These are rough equivalents of the rules I gave before, when I forgot
about the last one. They're expressed differently to be easier to
program.

Gesualdo used a gamut of Cb to B#. I had to leave out the Cb to get the
cadence of Merce grido piangendo to work. This is a fudge. The Bb chord
would more logically be an A#, but that Cx lies outside the gamut. The B
chord that follows would then prefer to be a Cb after the B. Probably
chords that would prefer to be outside the gamut would have to be given
special treatment, but there's only this one example so far.

About the ending of Merce grido piangendo. The words are "Io moro, io
moro". Of the 11 "moro"s, 5 are a chromatic semitone and 3 a minor third.
There's only one diatonic semitone, D#-E in the bass, where "io mo-" is
a chromatic semitone. There are also a couple of whole tone "moro"s,
where "io...ro" is a chromatic semitone. So I think Gesualdo may have
been deliberately aiming for chromatic semitones here. There are also a
couple on "mora" in the comma pump. And a couple more on "morte" in an
interesting passage from another piece (although he also uses a lot of
diatonic semitones there, including the only run of two diatonic semitones
I've seen so far). There seems to be a pattern...

There's no need to tell the program about 5-limit harmony: the spiral of
fifths is enough.

Rule 3 barely works. The last chord in the Merce grido piangendo diesis
pump was originally tuned wrong when I had it as G#-B#-D# after E-G-B.
Changing it to G B E B then G# D# G# B# fixed this because the minor third
G#-B dominated the wolf G-B#. I hadn't noticed that wolf before.

I had much less trouble with Margo's examples. So if Paul thinks he has
one that breaks my rules, I suggest he supply it. Anything with a Cb or
an augmented sixth would break the current rules. I can supply the Python
code on request, but won't here so it doesn't fill everybody's mailboxes.

Note that the same algorithm could be used to tune MIDI files into quarter
comma meantone. It might work better if it could look forwards as well as
backwards, and maybe an existing at-leisure algorithm could be hacked to
do that.

Graham

--- In tuning@y..., graham@m... wrote:
> To further my investigations into Gesualdo's use of accidentals,
I've
> written a Python script to do the conversion from 12 pitch classes
to note
> names. It uses the following rules:
>
> 1) Gamut from Gb to B#
> 2) For each chord, choose the version with the smallest span on the
spiral
> of fifths.
> 3) Where more than one equally good chord lies within the gamut,
choose
> the one which has the smallest average interval on the spiral of
fifths
> between it and the previous chord.
> 4) Seed with a D for rule 3.

My adaptive meantone algorithm differs in several ways.

1. It doesn't limit the gamut in advance. But it takes Eb to G# as the
seed and then shifts its choice of 12 notes up and down the chain
according to certain rules. It assumes the 12 remain contiguous on
the chain (no gaps). At the end of the piece you could of course look
back and see what the gamut was. It is quite possible that the actual
gamut did not span more than 12 notes, although the algorithm's choice
of 12 had shifted back and forth several times.

2. We only compare chord spans with the current choice of 12 and the
two either side. We reject any that result in a chromatic semitone (or
inversion or octave extension thereof). I refer to the presence of a
simultaneous chromatic semitone in the code as the "overloading" of a
nominal.

So we try to eliminate chromatic semitones, and the only way they can
get thru is if their elimination would require shifting our choice of
12 by more than 2 fifths up or down. Of course this maximum key-shift
is a parameter that can easily be changed.

3. When equally good (small span, no overloads) chords are available
within a keyshift of +-2 then those that require the smallest shift
are favoured, and for shifts of the same amount, a shift up (by a
fifth) is favoured over a shift down.

4. The _state_ of the algorithm may dependent on more than just the
previous chord.

To a first approximation the state is what diatonic key we are in. But
it is more general than merely major or minor (melodic or harmonic or
sharp IV). What it records as is the last modifier (natural, sharp,
flat, double-sharp etc) that it applied to each of the 7 nominals.
These will not necessarily be a contiguous 7 notes on the chain of
fifths, but they will be within a contiguous chain of 12.

So in a sense it assumes that at any point in time the composer has
some heptatonic scale in mind. The consequences of it really being
_less_ than heptatonic (e.g. pentatonic) are insignificant. The
consequences of it really being _more_ than heptatonic are at least a
graceful degradation the more notes you add. Of course totally
chromatic 12 note pieces will result in total confusion and
ridiculous excursions on the chain of fifths.

...
> There's no need to tell the program about 5-limit harmony: the
spiral of
> fifths is enough.

I decided this too.

...
> Note that the same algorithm could be used to tune MIDI files into
quarter
> comma meantone. It might work better if it could look forwards as
well as
> backwards, and maybe an existing at-leisure algorithm could be
hacked to
> do that.

Mine's not at-leisure, but you might be interested to try it.

It's written in C at
http://dkeenan.com/Music/Sweetener.cp.txt

The routine of interest is called "AdaptForChord".

It will help to know that wherever the word "fifth" occurs in a
variable or function name, it stands for "position of a note on the
chain of fifths relative to D=0".

Regards,
-- Dave Keenan

Dave Keenan wrote:

> My adaptive meantone algorithm differs in several ways.
>
> 1. It doesn't limit the gamut in advance. But it takes Eb to G# as
the
> seed and then shifts its choice of 12 notes up and down the chain
> according to certain rules. It assumes the 12 remain contiguous on
> the chain (no gaps). At the end of the piece you could of course
look
> back and see what the gamut was. It is quite possible that the
actual
> gamut did not span more than 12 notes, although the algorithm's
choice
> of 12 had shifted back and forth several times.

I need to limit the gamut to give a Bb chord at the start of bar 32 or
Merce grido piangendo. And also, once that's tuned to Bb, for the
next chord to be a B.

A more sophisticated algorithm may be able to overcome this fudge. I
note that between the Bb an B, the second highest voice moves from D
to B. So if you constrain chords such that each part moves by direct
intervals no more complex than an chromatic semitone, that should fix
it. I haven't done this as my program doesn't know about parts, and
would be more complex if it did.

In MIDI terms, a part would be a track in the file or a channel in the
live input.

You also have to know about rests. The middle voice moves by a
augmented second in bar 28 of Merce grido piangendo, but rests for a
semibreve in between.

The F#m-Bb progression might work if the cadence from bar 30 were
constrained to begin with G and and with E. That would require some
notion of key center, and the ability to work backwards.

> 2. We only compare chord spans with the current choice of 12 and the
> two either side. We reject any that result in a chromatic semitone
(or
> inversion or octave extension thereof). I refer to the presence of a
> simultaneous chromatic semitone in the code as the "overloading" of
a
> nominal.

Minimizing the span on the spiral of fifths would also tend to avoid
chromatic semitones.

> 3. When equally good (small span, no overloads) chords are available
> within a keyshift of +-2 then those that require the smallest shift
> are favoured, and for shifts of the same amount, a shift up (by a
> fifth) is favoured over a shift down.

This is relative to the "state" below?

> So in a sense it assumes that at any point in time the composer has
> some heptatonic scale in mind. The consequences of it really being
> _less_ than heptatonic (e.g. pentatonic) are insignificant. The
> consequences of it really being _more_ than heptatonic are at least
a
> graceful degradation the more notes you add. Of course totally
> chromatic 12 note pieces will result in total confusion and
> ridiculous excursions on the chain of fifths.

As Gesualdo does use enharmonic equivalents fairly close together, I
was assuming this kind of thing wouldn't work. Indeed, I'm not sure
if those diesis pumps would work with your method. The music is
chromatic, but not arbitrarily so. Otherwise, a neat meantone
solution may not exist.

Okay, take G-Am7-Em-G7-Em-G#. There's no C in that progression, so
what's to stop the G# being written G#-C-D#? It wouldn't lead to a
chromatic semitone anywhere.

My rules are sort of what I'd expect for 5-limit meantone, but
optmised to get Gesualdo to work. The simpest method, especially for
real-time operation, would be to remember the key center as a weighted
average. For each new note, take the spot on the spiral of fifths
nearest to that center, and adjust the average to take account of the
new note. This wouldn't work for Gesualdo, as you would get different
results depending on which notes were played first in a chord.

Adding the 7-ness does seem to complicate the algorithm. As you're
working with MIDI data, you shouldn't need to worry about note names
at all.

> > Note that the same algorithm could be used to tune MIDI files into
> quarter
> > comma meantone. It might work better if it could look forwards as
> well as
> > backwards, and maybe an existing at-leisure algorithm could be
> hacked to
> > do that.
>
> Mine's not at-leisure, but you might be interested to try it.
>
> It's written in C at
> http://dkeenan.com/Music/Sweetener.cp.txt

It looks like it could be hacked to work with UNIX MIDI, but still
needs a specific synthesizer to receive the pitch bends. I might be
able to write the same kind of thing from scratch, but I'll see how
you're collating MIDI data into chord.

I've placed my code at <http://x31eq.com/gesualdo.zip>.
It's shorter, but then it doesn't have to do any MIDIness.

> The routine of interest is called "AdaptForChord".
>
> It will help to know that wherever the word "fifth" occurs in a
> variable or function name, it stands for "position of a note on the
> chain of fifths relative to D=0".

That's the same measure I'm using, which should make the methods
comparable. I'll see if I can plug your algorithm into my script and
test it on the Gesualdo examples.

Graham

--- In tuning@y..., "Graham Breed" <graham@m...> wrote:
> I need to limit the gamut to give a Bb chord at the start of bar 32
or
> Merce grido piangendo. And also, once that's tuned to Bb, for the
> next chord to be a B.

I should point out that I haven't looked at any Gesualdo piece and
don't really have time to start. But if you want to feed me some
tricky chord sequences I'll see if I can explain how my algorithm
would handle them. That is, if you don't manage to insert my algorithm
into your existing framework and let it speak for itself.

My algorithm has had very little testing.

> In MIDI terms, a part would be a track in the file or a channel in
the
> live input.

My code currently assumes it's getting live data from a keyboard on a
single channel.

> You also have to know about rests.

My intention was to detect short periods of no activity and if the key
centre (middle-fifth, e.g D in C major) is more than 7 fifths away
from D, to pull it back by 12 (an enharmonic whatsit) so it's less
than 5 away.

> Minimizing the span on the spiral of fifths would also tend to avoid
> chromatic semitones.

Sure. But I think sometimes it doesn't, and I am willing to _increase_
the span of a chord if I have to, to get rid of chromatic semitones.

> > 3. When equally good (small span, no overloads) chords are
available
> > within a keyshift of +-2 then those that require the smallest
shift
> > are favoured, and for shifts of the same amount, a shift up (by a
> > fifth) is favoured over a shift down.
>
> This is relative to the "state" below?

Yes. In my algorithm, the most important summary of the "state" (the
imagined heptatonic scale) is the "midfifth", which is not the mean of
the seven, but approximately the median (rounding 0.5's down), with
some messy exceptions (See the start of "AdaptForFifth").

> As Gesualdo does use enharmonic equivalents fairly close together, I
> was assuming this kind of thing wouldn't work.

Maybe not. Gimme a chord/note sequence.

> Indeed, I'm not sure
> if those diesis pumps would work with your method.

Ah, no. Diesis pumps will send if off the end every time, unless it
can use a rest to fall back towards the D centre. Why would one want
to tune music with diesis pumps in meantone?

My algorithm doesn't do 31-tET wraparound since it assumes the
tone-generator's tuning table can't handle more than +-64 cents. But
it could be modified to do so. Does Gesualdo require it?

> The music is
> chromatic, but not arbitrarily so. Otherwise, a neat meantone
> solution may not exist.

Indeed.

> Okay, take G-Am7-Em-G7-Em-G#. There's no C in that progression,

Err. What about in the Am7? Are you saying he spells its third as B#,
or does he omit the third? Or did you mean to say there's no C#?

My algorithm would give the same result whether you have a C in there
or not, because there is an F which never gets replaced (in the
heptatonic "state") by an F#, and F is lower on the chain of fifths
than C.

It will also give the same result whether there's a C# in there or
not.

> so
> what's to stop the G# being written G#-C-D#? It wouldn't lead to a
> chromatic semitone anywhere.

When we come to the G# chord, the lowest "fifth" in the "state" is F
and the highest is G#, so midfifth is E and our choice of 12 is F to
A#. We only need to move our centre up by 2 positions to encompass the
B# and so the algorithm _does_ discover that it can reduce the span of
the chord by spelling it G#-B#-D#.

It doesn't care that there's a chromatic semitone between the B in the
previous chord and the B#.

After the G# chord our minfifth is F (-3) and maxfifth is B# (10) so
midfifth will be B (3) and the choice of 12 is (always 6 up and 5 down
from midfifth) C thru E#. So although we decided to use a B# for that
chord, a repetition of that note alone would still be rendered as C.
It's the fact that we still haven't seen an F# that holds us back.

> My rules are sort of what I'd expect for 5-limit meantone, but
> optmised to get Gesualdo to work. The simpest method, especially
for
> real-time operation, would be to remember the key center as a
weighted
> average. For each new note, take the spot on the spiral of fifths
> nearest to that center, and adjust the average to take account of
the
> new note.

I fear this is too simple to work for much at all.

>This wouldn't work for Gesualdo, as you would get
different
> results depending on which notes were played first in a chord.

Yes. Chords need to be treated as a whole.

> Adding the 7-ness does seem to complicate the algorithm.

Next-to-impossible because of the ambiguity of the tritone.

> As you're
> working with MIDI data, you shouldn't need to worry about note names
> at all.

Not sure what you mean here.

> It looks like it could be hacked to work with UNIX MIDI, but still
> needs a specific synthesizer to receive the pitch bends.

Why not just make it spit out the spellings in ASCII. There's already
code there to do that (used in testing)

> I might be
> able to write the same kind of thing from scratch, but I'll see how
> you're collating MIDI data into chord.

Hmm. Don't assume that what I did actually works properly.

> I've placed my code at <http://x31eq.com/gesualdo.zip>.
> It's shorter, but then it doesn't have to do any MIDIness.

I haven't looked at yours yet. Maybe you could just write some code so
you can feed my algorithm notes in ASCII (e.g. chord per line) and get
the
spellings out in ASCII.

>I'll see if I can plug your algorithm into my script
and
> test it on the Gesualdo examples.

Thanks. That would be much appreciated. Don't hesitate to ask for
clarifications by email. I know how much I hate having to read other
people's code.

Regards,
-- Dave Keenan

Dave Keenan wrote:

> I should point out that I haven't looked at any Gesualdo piece and
> don't really have time to start. But if you want to feed me some
> tricky chord sequences I'll see if I can explain how my algorithm
> would handle them. That is, if you don't manage to insert my
algorithm
> into your existing framework and let it speak for itself.

They're in the zip file with the program.

> > Minimizing the span on the spiral of fifths would also tend to
avoid
> > chromatic semitones.
>
> Sure. But I think sometimes it doesn't, and I am willing to
_increase_
> the span of a chord if I have to, to get rid of chromatic semitones.

I'm sure I've see examples of such chords in sheet music. I'll keep
my eyes open from now on. Maybe in Wagner. You never get actual
chromatic semitones, but sometimes diminished or augmented octaves. I
might even have seen one in Gesualdo, but not in one of the passages I
have a copy of. I didn't take much notice of it, as I was only
interested in mistuned consonances at that time. I didn't have an
algorithm that cared about the spellings of dissonances.

> Yes. In my algorithm, the most important summary of the "state" (the
> imagined heptatonic scale) is the "midfifth", which is not the mean
of
> the seven, but approximately the median (rounding 0.5's down), with
> some messy exceptions (See the start of "AdaptForFifth").

So that will tend to a diatonic scale.

> > Indeed, I'm not sure
> > if those diesis pumps would work with your method.
>
> Ah, no. Diesis pumps will send if off the end every time, unless it
> can use a rest to fall back towards the D centre. Why would one want
> to tune music with diesis pumps in meantone?

I should point out that only one voice moves by a diesis in these
progressions. So they're not really analagous to comma pumps.

> My algorithm doesn't do 31-tET wraparound since it assumes the
> tone-generator's tuning table can't handle more than +-64 cents. But
> it could be modified to do so. Does Gesualdo require it?

Oh no, it can work fine as an open spiral of fifths for <ducks> 12
pitch classes.

> > Okay, take G-Am7-Em-G7-Em-G#. There's no C in that progression,
>
> Err. What about in the Am7?

<shuffling of paper>

Yes, there it is. Of course, it's the note that forms the diesis with
the B# later on.

> My algorithm would give the same result whether you have a C in
there
> or not, because there is an F which never gets replaced (in the
> heptatonic "state") by an F#, and F is lower on the chain of fifths
> than C.

Ah, so it's still a chain of fifths thing.

> > so
> > what's to stop the G# being written G#-C-D#? It wouldn't lead to
a
> > chromatic semitone anywhere.
>
> When we come to the G# chord, the lowest "fifth" in the "state" is F
> and the highest is G#, so midfifth is E and our choice of 12 is F to
> A#. We only need to move our centre up by 2 positions to encompass
the
> B# and so the algorithm _does_ discover that it can reduce the span
of
> the chord by spelling it G#-B#-D#.

That sounds similar to what I'm doing.

> It doesn't care that there's a chromatic semitone between the B in
the
> previous chord and the B#.

Would it care that Ab-C-Eb is closer on the spiral of fifths?

Ab-Eb-Bb-F--C--G--D--A--E--B--F#-C#-G#-D#-A#-E#-B#
1 1* 1 2 2* 2 3 3* 3

I suppose not if the *s refer to the median fifths. I knew I could
fudge it if I taught the program about root progressions. The median
fifth seems to be a good simplification.

> After the G# chord our minfifth is F (-3) and maxfifth is B# (10) so
> midfifth will be B (3) and the choice of 12 is (always 6 up and 5
down
> from midfifth) C thru E#. So although we decided to use a B# for
that
> chord, a repetition of that note alone would still be rendered as C.
> It's the fact that we still haven't seen an F# that holds us back.

Oh, but this is min and max fifth. That doesn't always work, and can
be ambiguous (there's an example in Anchor che per amarti). Which is
why I average the fifths instead. But that's only for one chord at a
time, right? So you do this *and* check for overloads. I take all
chords with the smallest span, and then use the previous chord to
choose between them.

> > Adding the 7-ness does seem to complicate the algorithm.
>
> Next-to-impossible because of the ambiguity of the tritone.
>
> > As you're
> > working with MIDI data, you shouldn't need to worry about note
names
> > at all.
>
> Not sure what you mean here.

I mean the 7 note scales shouldn't be needed. Although the stuff in
your code about note names seems to be for something else.

> > It looks like it could be hacked to work with UNIX MIDI, but still
> > needs a specific synthesizer to receive the pitch bends.
>
> Why not just make it spit out the spellings in ASCII. There's
already
> code there to do that (used in testing)

If it could read them in as well, that'd be perfect.

> > I've placed my code at <http://x31eq.com/gesualdo.zip>.
> > It's shorter, but then it doesn't have to do any MIDIness.
>
> I haven't looked at yours yet. Maybe you could just write some code
so
> you can feed my algorithm notes in ASCII (e.g. chord per line) and
get
> the
> spellings out in ASCII.

Chord per line is what I already work with.

> >I'll see if I can plug your algorithm into my script
> and
> > test it on the Gesualdo examples.
>
> Thanks. That would be much appreciated. Don't hesitate to ask for
> clarifications by email. I know how much I hate having to read other
> people's code.

I'll see if I get time. It's looking like, although the method of
choosing chords is different, that won't be important until I find
chords that would naturally be degenerate. If the next bit is to
compare the medians, presumably I need to put the steps on the spiral
of fifths into a list, remove duplicates, sort it, and take the middle
one. If there are an even number of notes, take the nearest of the
middle pair to the mean. Would that work?

Graham

--- In tuning@y..., "Graham Breed" <graham@m...> wrote:
> They're in the zip file with the program.

Ok. Got'em.

> > > Minimizing the span on the spiral of fifths would also tend to
> avoid
> > > chromatic semitones.
> >
> > Sure. But I think sometimes it doesn't, and I am willing to
> _increase_
> > the span of a chord if I have to, to get rid of chromatic
semitones.
>
> I'm sure I've see examples of such chords in sheet music.

There's one in bar 85 of Fur Elise for what that's worth. A-G#-D-F. It
would span less if it were spelled A-Ab-D-F, but my algorithm wont
allow it if the G# is in reach (i.e. no more than two fifths outside
the current choice of 12).

> > Yes. In my algorithm, the most important summary of the "state"
(the
> > imagined heptatonic scale) is the "midfifth", which is not the
mean
> of
> > the seven, but approximately the median (rounding 0.5's down),
with
> > some messy exceptions (See the start of "AdaptForFifth").
>
> So that will tend to a diatonic scale.

Not sure what you mean here. The "state" will usually correspond to a
diatonic, yes. But quite often it will represent a "melodic" minor.
i.e. Am with the G# instead of the G (and no F#). And it also seems
common to have what I call a #IV minor. e.g. Am with G# and D# instead
of G and D (and no F#). But it can be any kind of bizarre heptatonic
having no chromatic semitones.

> I should point out that only one voice moves by a diesis in these
> progressions. So they're not really analagous to comma pumps.

Ok. That should be fine then.

> Ah, so it's still a chain of fifths thing.

Oh sure. Sorry I didn't make that clear.

> That sounds similar to what I'm doing.

Yes. It's very similar, I only outlined the differences.

> Would it care that Ab-C-Eb is closer on the spiral of fifths?

Oops! I goofed. It _will_ choose Ab-C-Eb. When I manually converted
G-Am7-Em-G7-Em-G# to sets of notes I wrote G#'s in the Em's for some
dumb reason. So I thought my algorithm had already seen a G# before it
got to the G# chord. This would have placed the median fifth of the
"state" (the current chromatic-free heptatonic scale) closer to
G#-B#-D#. But without that, it has to shift up 4 places to find
G#-B#-D# but only down 1 place to find Ab-C-Eb.

It seems to me that any reasonable algorithm would choose Ab in this
case. What _is_ the argument for choosing G# (other than "That's what
Gesualdo did")?

> Oh, but this is min and max fifth. That doesn't always work, and
can
> be ambiguous (there's an example in Anchor che per amarti).

I was referring to the max and min fifths in the current "state", not
the chord. Sorry I don't have time to explain it better.

> Which
is
> why I average the fifths instead. But that's only for one chord at
a
> time, right? So you do this *and* check for overloads.

I compare spans *and* check for overloads. Yes.

>If the next bit is to
> compare the medians, presumably I need to put the steps on the
spiral
> of fifths into a list, remove duplicates, sort it, and take the
middle
> one. If there are an even number of notes, take the nearest of the
> middle pair to the mean. Would that work?

I think you might be misunderstanding me here.

I'll see if I can find time to hand-simulate my algorithm on those
Gesualdo segments you have provided. Is there a particular one you'd
like me to do next?

Here's Anchor che per amarti

Gesualdo My algorithm
F# F# C# A# F# F# C# A#
G E B B G E B B
Bb E G D A# E G D
Bb D G D A# D G D
A E A C# A E A C#

Mine wont find the smaller-spanning Bb in the third and fourth chords
unless I increase the allowable key-shift (when looking for smaller
spans) from +-2 up to +-3. This may be an argument for doing so.

-- Dave Keenan

Dave Keenan wrote:

> Not sure what you mean here. The "state" will usually correspond to
a
> diatonic, yes. But quite often it will represent a "melodic" minor.
> i.e. Am with the G# instead of the G (and no F#). And it also seems
> common to have what I call a #IV minor. e.g. Am with G# and D#
instead
> of G and D (and no F#). But it can be any kind of bizarre heptatonic
> having no chromatic semitones.

If "midfifth" is the most important part of the state, that will give
a diatonic scale as the nearest pitches. I can't work out how else
the state is specified.

> > Would it care that Ab-C-Eb is closer on the spiral of fifths?
>
> Oops! I goofed. It _will_ choose Ab-C-Eb. When I manually converted
> G-Am7-Em-G7-Em-G# to sets of notes I wrote G#'s in the Em's for some
> dumb reason. So I thought my algorithm had already seen a G# before
it
> got to the G# chord. This would have placed the median fifth of the
> "state" (the current chromatic-free heptatonic scale) closer to
> G#-B#-D#. But without that, it has to shift up 4 places to find
> G#-B#-D# but only down 1 place to find Ab-C-Eb.
>
> It seems to me that any reasonable algorithm would choose Ab in this
> case. What _is_ the argument for choosing G# (other than "That's
what
> Gesualdo did")?

When I originally looked at the score, I didn't even realize this was
ambiguous.

I'll name the voices bottom to top as bass, baritone, tenor, alto,
soprano. They might be wrong, but I can't keep on saying "second
voice up" and the like.

The tenor and alto both move by a major third. B-D# and E-G#
respectively. The baritone and soprano move by chromatic semitones,
and the bass is silent. All you need is to stop voices moving by more
complex intervals than a chromatic semitone.

My algorithm happens to get it right because B is doubled in the first
chord, and G# in the second. So the minor third G#-B dominates the
progression. Originally, I programmed the progression from the chord
names instead of the score, and it was wrong.

If you put it on a 5-limit lattice

B#
/ \
G#--D#
/ \ /
E---B
/ \ /
C---G
/ \ /
Ab--Eb

it's merely ambiguous: three connections each.

It would come out right if you counted thirds as more important than
fifths. That's a bit ad-hoc, but it works surprisingly often.
Probably because thirds are more likely to be direct intervals in a
single voice.

> >If the next bit is to
> > compare the medians, presumably I need to put the steps on the
> spiral
> > of fifths into a list, remove duplicates, sort it, and take the
> middle
> > one. If there are an even number of notes, take the nearest of
the
> > middle pair to the mean. Would that work?
>
> I think you might be misunderstanding me here.

Yes, which is a shame because it came out right.

> I'll see if I can find time to hand-simulate my algorithm on those
> Gesualdo segments you have provided. Is there a particular one you'd
> like me to do next?

Merce grido is the real challenge.

> Here's Anchor che per amarti
>
> Gesualdo My algorithm
> F# F# C# A# F# F# C# A#
> G E B B G E B B
> Bb E G D A# E G D
> Bb D G D A# D G D
> A E A C# A E A C#
>
> Mine wont find the smaller-spanning Bb in the third and fourth
chords
> unless I increase the allowable key-shift (when looking for smaller
> spans) from +-2 up to +-3. This may be an argument for doing so.

It's actually Tu piangi filli mia that has the ambiguous progression.
Take

D A D F
B B D# F#

The second chord could be Cb Cb Eb Gb. Taking the spans on the spiral
of fifths, they're equidistant.

Cb-Gb-Db-Ab-Eb-Bb-F--C--G--D--A--E--B--F#-C#-G#-D#
* * * 0 0 0 + + +

I stopped using the span because an integer measure will always give
this ambiguity. You said you resolved it by preferring steps up to
steps down, which will work here (right?). I decided to take the
mean, so it isn't an integer and less likely to be ambiguous. The
median I misunderstood you as suggesting also gives the right answer.

Considering only 5-limit intervals makes it obvious that the right
answer really is right!

Graham