thinking out loud about a 22-tet adaptive algorithm

...would any one have any ideas about/like to collaborate on a 22-tet adaptive
tuning script in python? my thought would be a simple curses or text based
interface, like a MOD tracker, where one could alter manually any pitches
that the algorithm missed, or ones that one wanted to be deliberately
dissonant, etc.

i know that there are adaptive algorithms out there (like DeLaubenfel's) but
my objections are:

1) they are not open source
2) they are not availble for me on linux, or not available.
3) they are ji centric, and for my purposes, i think it would be easier and
perhaps more desirable to have a 31-equal or 22-equal or 19-equal algorithm.
it would be easier to program for sure, i would think.

i want to be able to have a more productive tool than hand-coding in ASCII
like my existing custom tool, et_compose. i think it would be fun to be able
to improvise something and let an algorithm do most of the work of detuning,
then i could hand prune things.

i would want to start with 22-tet because i want to do weirder more
surprisingly non-typical western sounding stuff first right now.

that's my vision anyway.

-aaron.

> ...would any one have any ideas about/like to collaborate on
> a 22-tet adaptive tuning script in python?

I would.

> 3) they are ji centric, and for my purposes, i think it would
> be easier and perhaps more desirable to have a 31-equal or
> 22-equal or 19-equal algorithm.

Why?

> it would be easier to program for sure, i would think.

Why?

> i would want to start with 22-tet because i want to do weirder
> more surprisingly non-typical western sounding stuff first right
> now.

Maybe we should start by answering the question: What's the
difference between a key-guessing algorithm and an adaptive
tuning algorithm?

On Sunday 02 October 2005 1:19 pm, Carl Lumma wrote:
> > ...would any one have any ideas about/like to collaborate on
> > a 22-tet adaptive tuning script in python?
>
> I would.

excellent!

> > 3) they are ji centric, and for my purposes, i think it would
> > be easier and perhaps more desirable to have a 31-equal or
> > 22-equal or 19-equal algorithm.
>
> Why?

I would think that reducing the potential pitch space to a handful of discreet
equal steps would reduce the drift.

I could be wrong, though.

Anyway, I am also sonically personally more drawn to solving the 22-equal
example; if get JI out of it with minor modifications, that's ok too.

>
> > it would be easier to program for sure, i would think.
>
> Why?
>
> > i would want to start with 22-tet because i want to do weirder
> > more surprisingly non-typical western sounding stuff first right
> > now.
>
> Maybe we should start by answering the question: What's the
> difference between a key-guessing algorithm and an adaptive
> tuning algorithm?

I think that would depend on the type of adaptive algorithm....I would first
want to start simple, perhaps by declaring a scale to the algorithm if it
helps, and maybe just start by feeding it chords, and having it guess the
roots.

My model would be to have two arrays, a 'current' and a 'past' array. The
'current' would contain all the current 'note-on' pitches from analysis of
12-equal MIDI file at a given timestamp, and try to calculate the maximally
consonant interpretation of the simultaneous pitches in the given pitch
space. As a rule, I would like to try not allowing the bending of any pitches
that enter after previous sounding pitches, but instead find the maximully
consonant new note to complement the already sounding notes.

The purpose of the 'past' array would be to hold the last chord or note as a
reference, for comparison, to avoid melodic drift.

It's all just ideas right now, but I'm glad you want to help.

-Aaron.

>>> 3) they are ji centric, and for my purposes, i think it
>>> would be easier and perhaps more desirable to have a
>>> 31-equal or 22-equal or 19-equal algorithm.
>>
>> Why?
>
> I would think that reducing the potential pitch space to a
> handful of discreet equal steps would reduce the drift.

It depends on what kind of progressions you want to play.
In 22-tET the syntonic comma is actually larger than in JI,
so the shift/drift is worse.

> Anyway, I am also sonically personally more drawn to solving
> the 22-equal example; if get JI out of it with minor
> modifications, that's ok too.

I love 22 and would be happy to work on 22-specific solution.
But then, numbers are just numbers to a computer. I feel
like if we formulate the problem correctly, the system would
work for a wide variety of tunings. I could be wrong, though.

>> Maybe we should start by answering the question: What's the
>> difference between a key-guessing algorithm and an adaptive
>> tuning algorithm?
>
> I think that would depend on the type of adaptive algorithm....
> I would first want to start simple, perhaps by declaring a
> scale to the algorithm if it helps, and maybe just start by
> feeding it chords, and having it guess the roots.

That sounds like key-guessing. It lets you squeeze > 12
tones/octave out of a 12-tone instrument, but it won't
address shift/drift as Vicentino's method does.

> My model would be to have two arrays, a 'current' and a
> 'past' array. The 'current' would contain all the current
> 'note-on' pitches from analysis of 12-equal MIDI file at
> a given timestamp, and try to calculate the maximally
> consonant interpretation of the simultaneous pitches in
> the given pitch space. As a rule, I would like to try not
> allowing the bending of any pitches that enter after
> previous sounding pitches, but instead find the maximully
> consonant new note to complement the already sounding notes.

Have you seen...

http://lumma.org/music/theory/Adaptive.txt

?

-Carl

--- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@a...>
wrote:
>
> ...would any one have any ideas about/like to collaborate on a 22-
tet adaptive
> tuning script in python? my thought would be a simple curses

Hey, man, I'd be careful with my language if I were you, even if this
is only a computer processor you're talking to. Cyberbeasts could
get nasty if you set them a bad example. ;-)

> or text based
> interface, like a MOD tracker, where one could alter manually any
pitches
> that the algorithm missed, or ones that one wanted to be
deliberately
> dissonant, etc.

Only a couple of thoughts (see below).

> i know that there are adaptive algorithms out there (like
DeLaubenfel's) but
> my objections are:
>
> 1) they are not open source
> 2) they are not availble for me on linux, or not available.
> 3) they are ji centric, and for my purposes, i think it would be
easier and
> perhaps more desirable to have a 31-equal or 22-equal or 19-equal
algorithm.
> it would be easier to program for sure, i would think.
>
> i want to be able to have a more productive tool than hand-coding
in ASCII
> like my existing custom tool, et_compose. i think it would be fun
to be able
> to improvise something and let an algorithm do most of the work of
detuning,
> then i could hand prune things.
>
> i would want to start with 22-tet because i want to do weirder more
> surprisingly non-typical western sounding stuff first right now.
>
> that's my vision anyway.
>
> -aaron.

You'll probably want to adjust your pitches in increments of a single
small interval, and that would probably be a single degree of an ET
that's a multiple of 22. The lowest multiple of 22 that's 11-limit
consistent is 176; it gets all the 11-limit consonances within 3
cents (and you have to go considerably higher before you find
anything that's clearly better -- such as 836, with 0.236c max
error). One problem with 176 is that it would overcorrect 4:5, so
836 might indeed be better -- note that it's also a multiple of 19.

19 or 31 are more friendly to adaptive JI, since (unlike 22) each one
already contains at least one consonant interval with no more than a
couple of cents error (which would simplify the algorithm
considerably).

--George

--- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@a...> wrote:
>
> ...would any one have any ideas about/like to collaborate on a 22-tet adaptive
> tuning script in python? my thought would be a simple curses or text based
> interface, like a MOD tracker, where one could alter manually any pitches
> that the algorithm missed, or ones that one wanted to be deliberately
> dissonant, etc.
>
> i know that there are adaptive algorithms out there (like DeLaubenfel's) but
> my objections are:
>
> 3) they are ji centric, and for my purposes, i think it would be easier and
> perhaps more desirable to have a 31-equal or 22-equal or 19-equal algorithm.
> it would be easier to program for sure, i would think.

I don't get it. You want to write music in, say, 22-equal, and you'd like to have a program
adaptively retune the chords to . . . 22-equal?

> i would want to start with 22-tet because i want to do weirder more
> surprisingly non-typical western sounding stuff first right now.
>
> that's my vision anyway.

I probably need to catch up on the rest of the posts here before I have a clue . . . so sorry!

> > I would think that reducing the potential pitch space to a
> > handful of discreet equal steps would reduce the drift.
>
> It depends on what kind of progressions you want to play.
> In 22-tET the syntonic comma is actually larger than in JI,
> so the shift/drift is worse.

On the other hand, it could be used in a Vicentino-like
solution to render decatonic music in JI with minimal
shift/drift.

-Carl

--- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@a...> wrote:
> On Sunday 02 October 2005 1:19 pm, Carl Lumma wrote:
> > > ...would any one have any ideas about/like to collaborate on
> > > a 22-tet adaptive tuning script in python?
> >
> > I would.
>
> excellent!
>
> > > 3) they are ji centric, and for my purposes, i think it would
> > > be easier and perhaps more desirable to have a 31-equal or
> > > 22-equal or 19-equal algorithm.
> >
> > Why?
>
> I would think that reducing the potential pitch space to a handful of discreet
> equal steps would reduce the drift.
>
> I could be wrong, though.

This sounds like the kind of thing I'd be interested in . . . I still don't know quite what you
mean, but I'm still reading.

> Anyway, I am also sonically personally more drawn to solving the 22-equal
> example; if get JI out of it with minor modifications, that's ok too.
>
> >
> > > it would be easier to program for sure, i would think.
> >
> > Why?
> >
> > > i would want to start with 22-tet because i want to do weirder
> > > more surprisingly non-typical western sounding stuff first right
> > > now.
> >
> > Maybe we should start by answering the question: What's the
> > difference between a key-guessing algorithm and an adaptive
> > tuning algorithm?
>
> I think that would depend on the type of adaptive algorithm....I would first
> want to start simple, perhaps by declaring a scale to the algorithm if it
> helps, and maybe just start by feeding it chords, and having it guess the
> roots.
>
> My model would be to have two arrays, a 'current' and a 'past' array. The
> 'current' would contain all the current 'note-on' pitches from analysis of
> 12-equal MIDI file at a given timestamp, and try to calculate the maximally
> consonant interpretation of the simultaneous pitches in the given pitch
> space. As a rule, I would like to try not allowing the bending of any pitches
> that enter after previous sounding pitches, but instead find the maximully
> consonant new note to complement the already sounding notes.
>
> The purpose of the 'past' array would be to hold the last chord or note as a
> reference, for comparison, to avoid melodic drift.
>
> It's all just ideas right now, but I'm glad you want to help.
>
> -Aaron.

Hmm . . . I think I'm getting the picture. So if the MIDI file contains a I-vi-IV-ii-V-I
progression, and you put it through this 22-equal adaptive tuning, it will drift by 55 cents.
At what point does the "'past' array" come into play to prevent the drift, and how does it
do so? Or perhaps it doesn't?

On Monday 03 October 2005 6:54 pm, wallyesterpaulrus wrote:
> Hmm . . . I think I'm getting the picture. So if the MIDI file contains a
> I-vi-IV-ii-V-I progression, and you put it through this 22-equal adaptive
> tuning, it will drift by 55 cents. At what point does the "'past' array"
> come into play to prevent the drift, and how does it do so? Or perhaps it
> doesn't?

Good point, to which I would say we can have several options available to the
users of the Python script:

1) drift mode, where chords with held common tones are *allowed* to drift.
2) fixed mode, where all chords are based on a predefined 12-note fixed
baseline scale (ala vicentino)
3) manual mode, where the user can perform surgury on the scripts results,
post-facto, and tweak things to their liking by means of a 'transpose'
feature.

I think there are legitimte reasons to want drift sometimes, and other times
not. The slipperyness of drift is one of the surrealistically appealing
spects of any alternate tuning, in my book.

Fixed mode would also still give some surprising slipperyness for something
like a 22-equal adaptive algorithm. I'm really into playing around in
12-of-22-equal (pythagorean), and I like the unexpected planar shift of
pitch! It would be nice to have more vertical consonant sonorities available,
even if not real-time, and I think a simple fixed algorithm would be a good
start. I realize that there would be weird audible comma shifts, but no one
writes in 22-equal to sound normal! If I wanted to use 1/4-comma Vicentino I
would. I would be going for the wild and wacky ear-candy sound of 22-equal
here on purpose, comma shifts, drifts and all.

My purpose would of course be to be more prolific; hnd coding these things in
"et_compose" is a chore.

What say you?

Best,
Aaron

--- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@a...>
wrote:
> On Monday 03 October 2005 6:54 pm, wallyesterpaulrus wrote:
> > Hmm . . . I think I'm getting the picture. So if the MIDI file
contains a
> > I-vi-IV-ii-V-I progression, and you put it through this 22-equal
adaptive
> > tuning, it will drift by 55 cents. At what point does the "'past'
array"
> > come into play to prevent the drift, and how does it do so? Or
perhaps it
> > doesn't?
>
>
> Good point, to which I would say we can have several options
available to the
> users of the Python script:
>
> 1) drift mode, where chords with held common tones are *allowed* to
drift.
> 2) fixed mode, where all chords are based on a predefined 12-note
fixed
> baseline scale (ala vicentino)

I don't see how that's ala vicentino, nor how this could work here.
What did you have in mind?

> 3) manual mode, where the user can perform surgury on the scripts
results,
> post-facto, and tweak things to their liking by means of
a 'transpose'
> feature.
>
> I think there are legitimte reasons to want drift sometimes, and
other times
> not. The slipperyness of drift is one of the surrealistically
appealing
> spects of any alternate tuning, in my book.
>
> Fixed mode would also still give some surprising slipperyness for
something
> like a 22-equal adaptive algorithm. I'm really into playing around
in
> 12-of-22-equal (pythagorean), and I like the unexpected planar
shift of
> pitch! It would be nice to have more vertical consonant sonorities
available,
> even if not real-time, and I think a simple fixed algorithm would
be a good
> start. I realize that there would be weird audible comma shifts,
but no one
> writes in 22-equal to sound normal!

I think decatonic music in 22-equal sounds normal, but diatonic music
doesn't.

> My purpose would of course be to be more prolific; hnd coding these
things in
> "et_compose" is a chore.
>
> What say you?

My inclination is to say to you, "get set up on a full 22-note
tuning"! It's not that hard, and I believe the compositional rewards
will be immense, and you won't need any software. If nothing else
works, you could spend a couple hundred on an old Ensoniq. Otherwise,
I'd surely still like to help you on this idea of yours, but I think
we'll have to open lots of cans of worms.

On Tuesday 04 October 2005 4:55 pm, wallyesterpaulrus wrote:
> --- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@a...>
>
> wrote:
> > On Monday 03 October 2005 6:54 pm, wallyesterpaulrus wrote:
> > > Hmm . . . I think I'm getting the picture. So if the MIDI file
>
> contains a
>
> > > I-vi-IV-ii-V-I progression, and you put it through this 22-equal
>
> adaptive
>
> > > tuning, it will drift by 55 cents. At what point does the "'past'
>
> array"
>
> > > come into play to prevent the drift, and how does it do so? Or
>
> perhaps it
>
> > > doesn't?
> >
> > Good point, to which I would say we can have several options
>
> available to the
>
> > users of the Python script:
> >
> > 1) drift mode, where chords with held common tones are *allowed* to
>
> drift.
>
> > 2) fixed mode, where all chords are based on a predefined 12-note
>
> fixed
>
> > baseline scale (ala vicentino)
>
> I don't see how that's ala vicentino, nor how this could work here.
> What did you have in mind?

By analogy to Vicentino's algorithm, not literally... a fixed scale (say, 12
of 22). adaptive algorithm correcting vertical sonorities... not a hard
concept, really.

How am I not being clear? Sometimes I think you are trying hard to say you
don't understand when you really do....

> > 3) manual mode, where the user can perform surgury on the scripts
>
> results,
>
> > post-facto, and tweak things to their liking by means of
>
> a 'transpose'
>
> > feature.
> >
> > I think there are legitimte reasons to want drift sometimes, and
>
> other times
>
> > not. The slipperyness of drift is one of the surrealistically
>
> appealing
>
> > spects of any alternate tuning, in my book.
> >
> > Fixed mode would also still give some surprising slipperyness for
>
> something
>
> > like a 22-equal adaptive algorithm. I'm really into playing around
>
> in
>
> > 12-of-22-equal (pythagorean), and I like the unexpected planar
>
> shift of
>
> > pitch! It would be nice to have more vertical consonant sonorities
>
> available,
>
> > even if not real-time, and I think a simple fixed algorithm would
>
> be a good
>
> > start. I realize that there would be weird audible comma shifts,
>
> but no one
>
> > writes in 22-equal to sound normal!
>
> I think decatonic music in 22-equal sounds normal, but diatonic music
> doesn't.

right.....so? I'm missing your point here.

> > My purpose would of course be to be more prolific; hnd coding these
>
> things in
>
> > "et_compose" is a chore.
> >
> > What say you?
>
> My inclination is to say to you, "get set up on a full 22-note
> tuning"! It's not that hard, and I believe the compositional rewards
> will be immense, and you won't need any software. If nothing else
> works, you could spend a couple hundred on an old Ensoniq. Otherwise,
> I'd surely still like to help you on this idea of yours, but I think
> we'll have to open lots of cans of worms.

I don't relish the idea of having to play with 2 hands what I could play with
one, nor having a reduced octave range.

Let's open the can of worms.

Aaron.

--- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@a...>
wrote:
> On Tuesday 04 October 2005 4:55 pm, wallyesterpaulrus wrote:
> > --- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@a...>
> >
> > wrote:
> > > On Monday 03 October 2005 6:54 pm, wallyesterpaulrus wrote:
> > > > Hmm . . . I think I'm getting the picture. So if the MIDI file
> >
> > contains a
> >
> > > > I-vi-IV-ii-V-I progression, and you put it through this 22-
equal
> >
> > adaptive
> >
> > > > tuning, it will drift by 55 cents. At what point does
the "'past'
> >
> > array"
> >
> > > > come into play to prevent the drift, and how does it do so? Or
> >
> > perhaps it
> >
> > > > doesn't?
> > >
> > > Good point, to which I would say we can have several options
> >
> > available to the
> >
> > > users of the Python script:
> > >
> > > 1) drift mode, where chords with held common tones are
*allowed* to
> >
> > drift.
> >
> > > 2) fixed mode, where all chords are based on a predefined 12-
note
> >
> > fixed
> >
> > > baseline scale (ala vicentino)
> >
> > I don't see how that's ala vicentino, nor how this could work
here.
> > What did you have in mind?
>
> By analogy to Vicentino's algorithm, not literally... a fixed scale
(say, 12
> of 22). adaptive algorithm correcting vertical sonorities... not a
hard
> concept, really.

> How am I not being clear? Sometimes I think you are trying hard to
say you
> don't understand when you really do....

Sorry, Aaron, I think I understand what you're saying but it sounds a
lot like something else (for example Hermode or Justonic), not at all
like Vicentino. I like to make sure there's clarity both in
communication and on peripheral issues when posting on this list. I
understand that can be annoying sometimes, but I only have the
interest of mutual edification in mind.

Anyway, if we're going to start with a fixed 12 of 22 (not that we've
resolved all the issues that this would bring up), how about a choice
which contains a wealth of good harmonies already? In my paper on 22,
I mention a hexachordal dodecatonic scale, which happens to conform
to the geometry of the keyboard well. Allow E-F and B-C to be 1 step
of 22-equal, and all the other keyboard semitones to be 2 steps of 22-
equal. Now all the "ratios of 3" and "7:4" and "7:6" intervals will
appear on keys of the same color (white or black), while ratios of 5
will occur on pairs of keys of opposite color. This makes it easy to
see the consonant chords right on the keyboard. Of course, this
doesn't help you get past the fact that 22-equal is incompatible with
common-practice harmony/tonality, but perhaps this is a starting
point you can work from?