back to list

Adaptive puzzle tune

🔗Robert Walker <robertwalker@ntlworld.com>

9/2/2001 10:27:19 AM

Hi there,

I've just done the adaptive puzzle tune I sketched out some time back,
starting in C major, then moving to the black keys with an abrupt
ambiguous Ab / G#, with no preparation, then moving back to C
in such a way as to show that it was a G# (or perhaps, an Ab).
Actually the way it turned out, it's a G# both times, but two flavours of
G#, 25/16 and 405/128. Also has a brief visit to the Ab at
8/5 on the way back to C the second time.

There is no way an adaptive retuning program could tell which it was
until one gets to the resolution.

http://members.tripod.com/~robertinventor/tunes/tunes.htm

Idea was as an example of a tune where the real time
adaptive tuning program would have to look several
bars ahead to decide how to tune a note.

As it turned out, it has some melodic diesis shifts too at the end
(a la Margo Schulter / Vincentino),
which makes it something of an impossible to solve adaptive
puzzle at that point, at least for conventional twelve note
adaptive tuning.

Of course, this is just part of the puzzle. To make
a really puzzling tune for an adaptive tuning program,
one would need to go round it several times.

This isn't a comma pump proper, because it can be retuned
perfectly with no overall shifts of pitch, but if you
make the wrong decision for the unexpected note, then
it turns into a comma pump.

So the adaptive tunign challenge is to find the optimal
solution that has no overall shift of pitch (and no
fudging of the pitches), which a real-time adaptive
tuning program couldn't possibly do.

A leisure time one could do in principle, but might find it
a bit of a puzzle too. (Apart from the melodic
diesis shifts at the end, of course, which a twelve
tone adaptive tuning program would just have to tune out).

Mostly pure low number j.i. ratios, but a one or two more
complex intervals here and there.

It's also a try out of the new FTS root control windows.

Robert

🔗John A. deLaubenfels <jdl@adaptune.com>

9/3/2001 6:09:10 AM

Robert, I threw your adaptive puzzle piece at my program, which as you
know is able to look ahead in time, and as I expected it seems to handle
it pretty well (I used 5-limit "tuning file free", very rigid vertical
springs, normal horizontal and grounding springs, and no melody
springs).

[Robert (on web page, not tuning list):]
>I think it could puzzle a leisure time adaptive tuning program too
>actually, especially as it ends with some diesis shifts that are meant
>to be heard as such.

In that sense my program is "puzzled" and does not give the results
you're seeking. But we're talking about something that cannot in
principle be divined by _any_ program, without more than 12 pitch
classes input, right? OK, you say that in your post.

>It's also a try out of the new FTS root control windows.

Is this connected with the spec that Carl posted a week or so ago? I
read it, but can't make head or tails of it! Is the point to give a
player real-time control of which 12 pitch classes the 12 keys
represent?

JdL

🔗Robert Walker <robertwalker@ntlworld.com>

9/3/2001 7:31:09 AM

Hi John,

> Robert, I threw your adaptive puzzle piece at my program, which as you
> know is able to look ahead in time, and as I expected it seems to handle
> it pretty well (I used 5-limit "tuning file free", very rigid vertical
> springs, normal horizontal and grounding springs, and no melody
> springs).

Great! Can I hear the result?

> [Robert (on web page, not tuning list):]
> >I think it could puzzle a leisure time adaptive tuning program too
> >actually, especially as it ends with some diesis shifts that are meant
> >to be heard as such.

> In that sense my program is "puzzled" and does not give the results
> you're seeking. But we're talking about something that cannot in
> principle be divined by _any_ program, without more than 12 pitch
> classes input, right? OK, you say that in your post.

Yes. Ok, I'd better correct the web page and remove the things about
it puzzling a leisure time adaptive tuning program (apart from
the diesis shifts of course) - Done - as Q can it, then A
- yes.

> >It's also a try out of the new FTS root control windows.

> Is this connected with the spec that Carl posted a week or so ago? I
> read it, but can't make head or tails of it! Is the point to give a
> player real-time control of which 12 pitch classes the 12 keys
> represent?

Yes, that's right.

The note in the root control channel changes the root for the notes
in the playing channels. So for ex, if the root control channel
note is 5/4, then for the 12-tone j.i. scale cross set,

1/1 16/15 9/8 6/5 5/4 4/3 45/32 3/2 8/5 5/3 9/5 15/8 2/1
with C of keyboard playing 1/1

it gets transposed up by 5/4 to

5/4 4/3 45/32 3/2 25/16 5/3 225/128 15/8 2/1 25/12 9/4 75/32

with E of keyboard playing the 5/4,
so that starting from C the scale now is:

1/1 25/24 9/8 75/64 5/4 4/3 45/32 3/2 25/16 5/3 225/128 15/8 2/1

So now you can play a just diatonic E, and an E major chord with
5/4 25/16 15/8
instead of the
5/4 8/5 15/8 of the j.i. scale.

E minor is okay in both scales. But try a trickier one, say, D

then in the C root j.i., the D minor is 9/8 4/3 5/3
i.e. 1/1 32/27, 40/27, which is a real WOLF.

Touch the D root control and you can now play the pure
just D minor and D major in the scale:

81/80 135/132 9/8 6/5 81/64 27/20 45/32 3/2 405/256 27/16 9/5 15/8 81/40
e.g. D minor as
9/8 27/20 27/16

With FTS as set up at present, you can either assign an octave of
your keyboard to root control keys, or use a separate channel
for root control.

For the score I used a separate channel. Also if one has a second
manual, or organ type pedals, one can use those for root control
in the same way.

(I may later combine the two methods, so that
one can have one channel for all the root controls, or
factor selections, and the rest free for playing).

Though one can use the method to just remap twelve tone
note names to new pitches (in either octave or non octave
scale), one can also more generally use any mapping of the
128 midi notes to scale pitches.

One of the presets is the harmonic series tonality diamond
assigned to successive white keys of the keyboard.

One can also select a scale / mode into any of the midi
channels, which doesn't have to be the same scale as is
used for root control (allowing, e.g., tonality diamonds)
and in fact, one can select a different scale / mode
into each channel too if one wants.

So for example, this lets one use Margo Schulter's
mappings of two keyboards to play a scale, plus
a diesis shift of the scale, or more generally,
to play any scale of 24 or less notes in an octave.

(Now I _have_ to get my second keyboard to try this
out!)

One can also have, say, up to 15 scales, or modes of a
scale, and sweep through them while playing by assigning
a controller to change the "voice channel" while playing
- or can achieve same effect if one has an easy way
to quickly change midi in channels while playing.

There's also a cross free option that allows one
to continually change in a free fashion - e.g.
play a melody line, and when it hits on A,
touch the A root control and you get A root j.i.
starting from that very note, without any
diesis shifts.

Then when it reaches D, touch the D and you are
off into D major rooted j.i., again with no
diesis shift, but of course, one gets
diesis / comma drift instead.

This section is very new, has bugs for sure, and I
may not have explained it very well yet, but will be
working on it.

Robert

🔗John A. deLaubenfels <jdl@adaptune.com>

9/4/2001 9:43:22 AM

Robert, I uploaded the tuned version of your sequence yesterday, to the
JdL directory of the files area. Here are some observations about it.

A minor gripe: the first note-on is not till 4.8 seconds into the piece.
By that time, I'm scrambling to see if my speakers are off, etc. It
_is_ good to wait a fraction of a second for all the early control
messages to be digested, but anything over 1/2 second or so is
unnecessary (apologies if I'm being overly grumpy; I just stood in
two lines at two banks, trying to deposit a check made out to my wife
& me both; apparently it is nearly impossible. ;-> ).

Since the sequence stresses G#/Ab ambiguity, and since from your
description most of the time the note turns out to be G#, I expected
that scale degree (8 when numbered from C = 0) to be grounded on the
flat side. It ends up in my treatment being grounded at +2.6 cents
relative to 12-tET, a surprise. But, C itself is grounded at +4.4
cents, so G#/Ab _is_ flatter than that, which fits your description.

Here is a summary of the grounding I get:

Grounding: nSpring Strength Pain RMS deviation
---------- ------- -------- ---- -------------
0: 4.376 80 285.916 2421.475 4.116 cent
1: 1.986 23 163.306 981.194 3.467 cent
2: 3.552 38 192.768 399.147 2.035 cent
3: 1.785 35 141.051 3861.148 7.399 cent
4: -8.579 68 328.540 1115.803 2.606 cent
5: -6.294 2 6.461 13.062 2.011 cent
6: 6.107 19 130.758 2724.252 6.455 cent
7: 3.139 88 404.046 1634.105 2.844 cent
8: 2.554 17 159.020 1339.358 4.104 cent
9: -3.023 52 232.114 4047.753 5.906 cent
A: -12.074 9 73.466 88.648 1.553 cent
B: -1.262 16 74.544 2145.685 7.587 cent

The RMS deviation for each pitch class is an interesting quantity,
because it hints at which notes might best be split into separately
grounded enharmonics. Interestingly, D#/Eb shows much stronger desire
to split than G#/Ab; so does B/Cb (!). The most "happily grounded" note
is Bb (confusingly shown as "A" above, in base 12 notation).

Because the vertical springs are very stiff (256 times nominal), one
might expect zero deviation across them. But, the ambiguous chord
types (full diminished, augmented, chain-of-fifths) force some vertical
flexing to take place. I now have vertical spring deviations broken
down by intervals:

Vert range: nSpring Strength Pain RMS deviation
----------- ------- -------- ---- -------------
88.5-110.7 8 1129.807 39153.811 8.325 cent
183.4-202.9 42 12615.939 723836.933 10.712 cent
314.6-316.6 85 480848.305 90515.388 0.614 cent
385.3-387.3 55 276755.598 3507.898 0.159 cent
497.0-499.0 100 510698.736 51080.599 0.447 cent
550.0-650.0 1 503.784 147680.818 24.213 cent

Where any gaps represent a range of vertical intervals with no springs.
All the consonant intervals (6/5, 5/4, 4/3) have less than a cent RMS
deviation, which is quite good.

Thanks, Robert, for the description of your new FTS real-time feature.
Is it the case that it is real-time _only_? To put it another way, is
it possible to save a MIDI file with varying set-of-12 information?
As you might guess, I'm grasping for a way to make my tuning program
more clever about divining more than 12 pitch classes on input.

JdL

🔗Robert Walker <robertwalker@ntlworld.com>

9/5/2001 9:35:18 PM

Hi John,

> A minor gripe: the first note-on is not till 4.8 seconds into the piece.

Sorry about that. Retuned via FTS, and that is just the delay
between pressing the record button in FTS and the play button in NWC.
I've done it again using the option to start the recording at the
first note played (this was temporarily out of order because
of a bug needing to be fixed).

> Since the sequence stresses G#/Ab ambiguity, and since from your
> description most of the time the note turns out to be G#, I expected
> that scale degree (8 when numbered from C = 0) to be grounded on the
> flat side. It ends up in my treatment being grounded at +2.6 cents
> relative to 12-tET, a surprise. But, C itself is grounded at +4.4
> cents, so G#/Ab _is_ flatter than that, which fits your description.

Yes, that's a bit flat, but is it flat enough for the G#?

Actually the first G# is also shifted up by a diesis as it is
a 9/8 above a 5/4 above a 9/8 above the 1/1, which makes it
only a couple of cents below the 12-tet note.

Then there are two Abs in the c minor section, and a couple of normal
G#s.

So if averaging over the number of notes, I think it is indeed prob. close to what one would expect.

> Here is a summary of the grounding I get:

> Grounding: nSpring Strength Pain RMS deviation
> ---------- ------- -------- ---- -------------
> 0: 4.376 80 285.916 2421.475 4.116 cent
> 1: 1.986 23 163.306 981.194 3.467 cent C#
> 2: 3.552 38 192.768 399.147 2.035 cent
> 3: 1.785 35 141.051 3861.148 7.399 cent D#
> 4: -8.579 68 328.540 1115.803 2.606 cent
> 5: -6.294 2 6.461 13.062 2.011 cent
> 6: 6.107 19 130.758 2724.252 6.455 cent F#
> 7: 3.139 88 404.046 1634.105 2.844 cent
> 8: 2.554 17 159.020 1339.358 4.104 cent G#
> 9: -3.023 52 232.114 4047.753 5.906 cent
> A: -12.074 9 73.466 88.648 1.553 cent A#
> B: -1.262 16 74.544 2145.685 7.587 cent

(i've added the accidentals to help keep track)

> The RMS deviation for each pitch class is an interesting quantity,
> because it hints at which notes might best be split into separately
> grounded enharmonics. Interestingly, D#/Eb shows much stronger desire
> to split than G#/Ab; so does B/Cb (!). The most "happily grounded" note
> is Bb (confusingly shown as "A" above, in base 12 notation).

It's understandable that all the "black notes" show strong desire to
split, as the second tune is played entirely on the black notes
each time it enters (except the last time when it has an A natural),
and that's the section that is most varied in its position relative
to the 1/1.

As for the B / Cb, in the original it occurs twice as
1129.32 cents from 60
and four times as
1088.26 cents from 60

- a very wide split of getting on for a quarter tone.

In bar 9 it's 15/16 below the nearest C; while an example of
the other tuning is in bar 15 where it is 24/25 below C
(and occurs in octaves).

So these are the smallest, and the largest j.i. semitones,
at 70.6724 and 111.731 cents

In bar 15, the intervals are all rather complex, such as
12/25 ~25/8~ 3/2 ~4/3~ 2/1
- this is where the tune kind of falls apart in a muddle,
before coming together again (and rhythm and harmony both do
likewise).

This is the c minor-ish section, however the root at this point is
Ab in the root channel chord from the Ab transition.

I'd have got clearer harmonies here by changing the root to C.

I quite liked the complex chords at this point with the falling
apart rhythm at the same time.

However, tried C as the root for it, and lo and behold
they all turn into 16/15s:

15/32 ~4/1~ 15/8 ~4/3~ 5/2
15/32 ~4/1~ 15/8 ~16/15~ 2/1
15/32 ~8/3~ 5/4 ~8/5~ 2/1
15/32 ~16/5~ 3/2 ~4/3~ 2/1

(sounds much sweeter).

Also found anohter straying root in bar 24 - the whole of bar
23 could be rooted to c = 1/1.

Now the only remaining complex intervals are the 27/10s (sharp
fourths resulting from three ascending 3/2s followed by 4/5, e.g.
in sequence C G D A F)
at the end of bar 3, 5, 31 and 33. Rest is all pure j.i.

Ex., at end of bar 3:

5/12 ~27/10~ 9/8 ~4/3~ 3/2

I think I'll leave those as they are.

See the web page to hear the new version of it.

So, I think, maybe quite a challenge to get it pure to this extent.

Your tuning does sound sweet, but I think doesn't quite get to the
sweetness of the original in places (with that complex section
now retuned). (I may be prejudiced :-))

Actually, this sequence is far more complex than it needs to be
to make the puzzle work, as the idea was to make one that you
would need to look a long way ahead to solve. Might help to
see better what is going on in the program to do a
much shorter sequence, with just the basic chords (and leaving
out hte dieses of course). Could be nice to do that if you are interested.

> Because the vertical springs are very stiff (256 times nominal), one
> might expect zero deviation across them. But, the ambiguous chord
> types (full diminished, augmented, chain-of-fifths) force some vertical
> flexing to take place. I now have vertical spring deviations broken
> down by intervals:

> Vert range: nSpring Strength Pain RMS deviation
> ----------- ------- -------- ---- -------------
> 88.5-110.7 8 1129.807 39153.811 8.325 cent
> 183.4-202.9 42 12615.939 723836.933 10.712 cent
> 314.6-316.6 85 480848.305 90515.388 0.614 cent
> 385.3-387.3 55 276755.598 3507.898 0.159 cent
> 497.0-499.0 100 510698.736 51080.599 0.447 cent
> 550.0-650.0 1 503.784 147680.818 24.213 cent

> Where any gaps represent a range of vertical intervals with no springs.
> All the consonant intervals (6/5, 5/4, 4/3) have less than a cent RMS
> deviation, which is quite good.

Yes, that's pretty good.

However, in theory one should be able to get pretty close to 0.

N.B. I'm not sure if the puzzle has a unique solution, as it will
depend on which note one wants to keep steady from beginning to end
of the piece as measure of extent to which one has minimised the
drift.

I used C = 1/1. However, could be reasons for choosing
another note, then decisions could all be a bit changed.

> Thanks, Robert, for the description of your new FTS real-time feature.
> Is it the case that it is real-time _only_? To put it another way, is
> it possible to save a MIDI file with varying set-of-12 information?
> As you might guess, I'm grasping for a way to make my tuning program
> more clever about divining more than 12 pitch classes on input.

Yes, it is possible. In fact, I imagine composers using this system
will save the score, and can save it equally well as a .midi
file, which you could use for adaptive retuning.

Just need to have one channel for root control. For twelve tone system
one needs only 12 notes for root control, so you can have multiple
root controls in the same channel by assigning an octave to each.

Could use non melod. perc. channel for root control if the piece
doesn't use that channel.

(This is for ideas for your prog. I also plan to update FTS so
that one can put all the root controls in one channel, but haven't
done that yet, and at present it uses a separate channel for
each one when one has multiple root controls).

Robert

🔗John A. deLaubenfels <jdl@adaptune.com>

9/6/2001 11:19:18 AM

[I wrote:]
>>Since the sequence stresses G#/Ab ambiguity, and since from your
>>description most of the time the note turns out to be G#, I expected
>>that scale degree (8 when numbered from C = 0) to be grounded on the
>>flat side. It ends up in my treatment being grounded at +2.6 cents
>>relative to 12-tET, a surprise. But, C itself is grounded at +4.4
>>cents, so G#/Ab _is_ flatter than that, which fits your description.

[Robert:]
>Yes, that's a bit flat, but is it flat enough for the G#?

Seems to be. Everything's under pretty good control, according to the
numbers, and I can't detect a problem in the result with my moderately
sensitive ear.

[Robert:]
>Actually the first G# is also shifted up by a diesis as it is
>a 9/8 above a 5/4 above a 9/8 above the 1/1, which makes it
>only a couple of cents below the 12-tet note.

Kyool.

>Then there are two Abs in the c minor section, and a couple of normal
>G#s.

>So if averaging over the number of notes, I think it is indeed prob.
>close to what one would expect.

It seems to be.

[Robert:]
>Your tuning does sound sweet, but I think doesn't quite get to the
>sweetness of the original in places (with that complex section
>now retuned). (I may be prejudiced :-))

Hmmm. Certainly I do not capture the same walk along enharmonic notes
as you do, but vertically I think one would be hard pressed to hear a
difference.

[Robert:]
>Actually, this sequence is far more complex than it needs to be
>to make the puzzle work, as the idea was to make one that you
>would need to look a long way ahead to solve. Might help to
>see better what is going on in the program to do a
>much shorter sequence, with just the basic chords (and leaving
>out the dieses of course). Could be nice to do that if you are
>interested.

I am always up for challenges.

[JdL:]
>>Because the vertical springs are very stiff (256 times nominal), one
>>might expect zero deviation across them. But, the ambiguous chord
>>types (full diminished, augmented, chain-of-fifths) force some vertical
>>flexing to take place. I now have vertical spring deviations broken
>>down by intervals:

>>Vert range: nSpring Strength Pain RMS deviation
>>----------- ------- -------- ---- -------------
>> 88.5-110.7 8 1129.807 39153.811 8.325 cent
>>183.4-202.9 42 12615.939 723836.933 10.712 cent
>>314.6-316.6 85 480848.305 90515.388 0.614 cent
>>385.3-387.3 55 276755.598 3507.898 0.159 cent
>>497.0-499.0 100 510698.736 51080.599 0.447 cent
>>550.0-650.0 1 503.784 147680.818 24.213 cent

>>Where any gaps represent a range of vertical intervals with no springs.
>>All the consonant intervals (6/5, 5/4, 4/3) have less than a cent RMS
>>deviation, which is quite good.

[Robert:]
>Yes, that's pretty good.

>However, in theory one should be able to get pretty close to 0.

No. Just an occasional chord with non-self-consistent vertical springs
does a lot of "damage" to the RMS numbers, not to mention causing huge
vertical pain to be calculated when vertical springs are stiff. I can
run your piece with vertical springs at 2^16 of nominal, but I don't
think there'd be much vertical improvement. I don't currently have, but
could add, detection and reporting of places where an "impossible"
mixture of notes takes place; it is quite common in practice.

[JdL:]
>>Thanks, Robert, for the description of your new FTS real-time feature.
>>Is it the case that it is real-time _only_? To put it another way, is
>>it possible to save a MIDI file with varying set-of-12 information?
>>As you might guess, I'm grasping for a way to make my tuning program
>>more clever about divining more than 12 pitch classes on input.

[Robert:]
>Yes, it is possible. In fact, I imagine composers using this system
>will save the score, and can save it equally well as a .midi
>file, which you could use for adaptive retuning.

>Just need to have one channel for root control. For twelve tone system
>one needs only 12 notes for root control, so you can have multiple
>root controls in the same channel by assigning an octave to each.

Kyool! I went back and reread your previous reply and realized you had
stated that before as well. This system makes a lot of sense,
especially for sequences with just one or two voices. Can FTS output
a "mix-down" MIDI file suitable for any GM module?

>Could use non melod. perc. channel for root control if the piece
>doesn't use that channel.

Right! That dang channel, in the middle of the GM list; it'd be nice
to have an actual use for it. Every now and then I tune a sequence that
actually uses internal 9 for percussion, so that option also has to be
available.

Tell you what else I'd like to have: a continuous controller pedal
attached to absolute tuning. This would allow shifting from one
preset tuning to another while also taking control of drift very
explicitly. The usual spring-loaded hand-operated pitch wheel is
useless in this regard.

>(This is for ideas for your prog. I also plan to update FTS so
>that one can put all the root controls in one channel, but haven't
>done that yet, and at present it uses a separate channel for
>each one when one has multiple root controls).

I just went back and did your sequence with pitch class splitting, and
got the following grounding:

Grounding: nSpring Strength Pain RMS deviation
---------- ------- -------- ---- -------------
Cb 15.182 3 30.804 0.858 0.236 cent
Gb 20.124 11 85.842 159.284 1.926 cent
Db 0.788 23 163.306 202.585 1.575 cent
Ab 3.986 17 159.020 797.049 3.166 cent
Eb 7.283 35 141.051 1272.327 4.247 cent
Bb -13.902 9 73.466 135.107 1.918 cent
F -5.975 2 6.461 25.239 2.795 cent
C 3.605 80 285.916 1692.605 3.441 cent
G 1.964 88 404.046 1173.022 2.410 cent
D 2.106 38 192.768 205.097 1.459 cent
A -3.974 52 232.114 4416.190 6.169 cent
E -9.498 68 328.540 2293.941 3.737 cent
B -10.338 13 43.740 82.491 1.942 cent
F# -4.897 8 44.916 835.754 6.100 cent

As before, Ab/G# is _not_ split. Now its grounding is higher than C!
Not sure why. That's a very unusual set of grounding numbers,
reflecting the particular character of the piece (and the limitations of
my program).

It suddenly occurs to me that, when I'm taking in a sequence that is
already tuned, I could have my program differentiate pitch classes
right from those tuning numbers! I already have an option to take in
pitch bends as gliss (adding them to the tuning I calculate), so this
would be just one other way to deal with them. I'm not sure what I'd
do if a pitch class has a whole _bunch_ of input tunings, though...
Heck, I _could_ just base grounding spring targets upon the values
input for each note, suppressing any adjustment of grounding targets
within the relaxation process. That way, I could adaptively tune pieces
prepared from other n-tET's very simply. Can't believe I've never
thought of this before...

JdL

🔗Herman Miller <hmiller@IO.COM>

9/6/2001 5:53:40 PM

On Thu, 06 Sep 2001 12:19:18 -0600, "John A. deLaubenfels"
<jdl@adaptune.com> wrote:

>It suddenly occurs to me that, when I'm taking in a sequence that is
>already tuned, I could have my program differentiate pitch classes
>right from those tuning numbers! I already have an option to take in
>pitch bends as gliss (adding them to the tuning I calculate), so this
>would be just one other way to deal with them. I'm not sure what I'd
>do if a pitch class has a whole _bunch_ of input tunings, though...
>Heck, I _could_ just base grounding spring targets upon the values
>input for each note, suppressing any adjustment of grounding targets
>within the relaxation process. That way, I could adaptively tune pieces
>prepared from other n-tET's very simply. Can't believe I've never
>thought of this before...

Cool! Does it have to be a single timbre, or can it sort out multiple
timbres? I'd like to see what it does to my 26-TET etude (which is all
piano)

http://www.io.com/~hmiller/midi/26tet.mid

and I think "This Way to the Egress" (14-TET) is all one timbre

http://www.io.com/~hmiller/midi/egress.mid

(it'd be interesting to see if it can make heads or tails of 14-TET
harmony!)

--
see my music page ---> ---<http://www.io.com/~hmiller/music/index.html>--
hmiller (Herman Miller) "If all Printers were determin'd not to print any
@io.com email password: thing till they were sure it would offend no body,
\ "Subject: teamouse" / there would be very little printed." -Ben Franklin

🔗Robert Walker <robertwalker@ntlworld.com>

9/6/2001 7:10:33 PM

Hi John,

> Hmmm. Certainly I do not capture the same walk along enharmonic notes
> as you do, but vertically I think one would be hard pressed to hear a
> difference.

[Robert:]
> >Actually, this sequence is far more complex than it needs to be
> >to make the puzzle work, as the idea was to make one that you
> >would need to look a long way ahead to solve. Might help to
> >see better what is going on in the program to do a
> >much shorter sequence, with just the basic chords (and leaving
> >out the dieses of course). Could be nice to do that if you are
> >interested.

> I am always up for challenges.

Okay, I'll try a shorter piece with much fewer notes, but same
basic idea (more or less).

> No. Just an occasional chord with non-self-consistent vertical springs
> does a lot of "damage" to the RMS numbers, not to mention causing huge
> vertical pain to be calculated when vertical springs are stiff. I can
> run your piece with vertical springs at 2^16 of nominal, but I don't
> think there'd be much vertical improvement. I don't currently have, but
> could add, detection and reporting of places where an "impossible"
> mixture of notes takes place; it is quite common in practice.

Okay, I understand that.

I've added an option to the automatic logging of the intervals
to show all the intervals, rather than just consecutive ones,
and it shows things such as, two 6/5s stacked on top of each other
(up to octave equivalence anyway) to make a 36/25, or the 27/20s
(9/8 + 6/5 or 10/9 + 4/3). Those are the most frequent.

Also 6/5 + 5/4 + 9/8 giving 27/16, 45/32.

Perhaps it's a little tricky somtimes comparing two tunings to see which is
best, as one can listen to particularly nice intervals in one tuning, and
then look out for the same ones in another, and doing that is likely to favour
whichever is the one that one listens to first.

> Kyool! I went back and reread your previous reply and realized you had
> stated that before as well. This system makes a lot of sense,
> especially for sequences with just one or two voices. Can FTS output
> a "mix-down" MIDI file suitable for any GM module?

You'll have the original midi with the root control channel prob. best
saved from the sequnecer / score editor.

Then FTS can record all the notes played as they are played, as
I did for the example.

What is needed for a "mix-down" MIDI file?

> Right! That dang channel, in the middle of the GM list; it'd be nice
> to have an actual use for it. Every now and then I tune a sequence that
> actually uses internal 9 for percussion, so that option also has to be
> available.

Same here. Yes, such an awkward position; I wonder why they didn't
make it the last one in the list.

> Tell you what else I'd like to have: a continuous controller pedal
> attached to absolute tuning. This would allow shifting from one
> preset tuning to another while also taking control of drift very
> explicitly. The usual spring-loaded hand-operated pitch wheel is
> useless in this regard.

I wonder if that is related to the next section I'm planning,
which is to add option to morph from one scale to another,
idea of Graham's - at present it does it for mean-tone,
by varying the comma, but one could morph from any scale
to any other with same number of notes, by linear interpolation
of the note values.

Or, use the controller to morph between a succession of
several scales all with the same number of notes.

However, I have a feeling you have something else in mind.

Yes, the spring loaded pitch wheel assumes you are always
going to want to return to the original note pitch, and isn't
much use when one wants to move everything up a little, or
down a little.

In FTS as it is now, since the scales and modes are selected
into the "voice channel", one can sweep between them by varying
the midi in channel, and I added option to use a continuous controller to
same effect.

However, could also be nice to change the scale in all the playing channels
simultaneously in the same kind of a way. That would probably be
done using the next section, when I program it.

I also thought about using a controller to change the root control.

That could be possible perhaps if one had a display in FTS showing
which note it was set to, so that you can see it change as you
change the controller. With multiple controllers / factor selection,
then one could assigne a controller to each root control,
as alternative to assigning a midi in channel to each one, and so
leave all the midi in channels free.

I think, the controller would be expected to have the same effect
whichever midi in channel it was received on, as it affects all
the scales being played.

(I'd have to think a bit more about how to do this exactly).

> I just went back and did your sequence with pitch class splitting, and
> got the following grounding:

> Grounding: nSpring Strength Pain RMS deviation
> ---------- ------- -------- ---- -------------
> Cb 15.182 3 30.804 0.858 0.236 cent
> Gb 20.124 11 85.842 159.284 1.926 cent
> Db 0.788 23 163.306 202.585 1.575 cent
> Ab 3.986 17 159.020 797.049 3.166 cent
> Eb 7.283 35 141.051 1272.327 4.247 cent
> Bb -13.902 9 73.466 135.107 1.918 cent
> F -5.975 2 6.461 25.239 2.795 cent
> C 3.605 80 285.916 1692.605 3.441 cent
> G 1.964 88 404.046 1173.022 2.410 cent
> D 2.106 38 192.768 205.097 1.459 cent
> A -3.974 52 232.114 4416.190 6.169 cent
> E -9.498 68 328.540 2293.941 3.737 cent
> B -10.338 13 43.740 82.491 1.942 cent
> F# -4.897 8 44.916 835.754 6.100 cent

> As before, Ab/G# is _not_ split. Now its grounding is higher than C!
> Not sure why. That's a very unusual set of grounding numbers,
> reflecting the particular character of the piece (and the limitations of
> my program).

Yes, funny that the B Cb splits, and the F# Gb, and the Ab G# doesn't.

Maybe we'll get an idea of why with a shorter sequence with less going
on.

> It suddenly occurs to me that, when I'm taking in a sequence that is
> already tuned, I could have my program differentiate pitch classes
> right from those tuning numbers! I already have an option to take in
> pitch bends as gliss (adding them to the tuning I calculate), so this
> would be just one other way to deal with them. I'm not sure what I'd
> do if a pitch class has a whole _bunch_ of input tunings, though...
> Heck, I _could_ just base grounding spring targets upon the values
> input for each note, suppressing any adjustment of grounding targets
> within the relaxation process. That way, I could adaptively tune pieces
> prepared from other n-tET's very simply. Can't believe I've never
> thought of this before...

That's a nice idiea. So composer could for example write a piece in, say, 7-tet,
and you can adaptively tune it to make the 3/2s more mellow (and
perhaps target 11/9s too?) if desired. Do I understand this
right?

Robert

🔗John A. deLaubenfels <jdl@adaptune.com>

9/7/2001 11:37:00 AM

[I wrote:]
>>It suddenly occurs to me that, when I'm taking in a sequence that is
>>already tuned, I could have my program differentiate pitch classes
>>right from those tuning numbers! I already have an option to take in
>>pitch bends as gliss (adding them to the tuning I calculate), so this
>>would be just one other way to deal with them. I'm not sure what I'd
>>do if a pitch class has a whole _bunch_ of input tunings, though...
>>Heck, I _could_ just base grounding spring targets upon the values
>>input for each note, suppressing any adjustment of grounding targets
>>within the relaxation process. That way, I could adaptively tune
>>pieces prepared from other n-tET's very simply. Can't believe I've
>>never thought of this before...

[Herman Miller wrote:]
>Cool! Does it have to be a single timbre, or can it sort out multiple
>timbres? I'd like to see what it does to my 26-TET etude (which is all
>piano)

It can be more than one timbre to the same extent that I've supported
since around the turn of the year, i.e., as long as there are enough
channels for dynamic channel reassignment.

>http://www.io.com/~hmiller/midi/26tet.mid

>and I think "This Way to the Egress" (14-TET) is all one timbre

>http://www.io.com/~hmiller/midi/egress.mid

>(it'd be interesting to see if it can make heads or tails of 14-TET
>harmony!)

Cool! Thanks for the refs. I don't have this coded yet, but as soon as
I do, I'll throw your pieces at it. Another bit of information is
needed, however: given a certain input interval, what does the program
use as the _target_ interval? In the case of 14-tET, for example, it
is clear that 8 steps should target 3:2, but what number of steps, if
any, should target 5:4, or 6:5? What targets should be formed from
other increments of 14-tET? Ideally, this should go into a "tuning"
file, to allow for experimentation without recompilation.

JdL

🔗John A. deLaubenfels <jdl@adaptune.com>

9/7/2001 11:37:42 AM

[Robert wrote:]
>>>Actually, this sequence is far more complex than it needs to be
>>>to make the puzzle work, as the idea was to make one that you
>>>would need to look a long way ahead to solve. Might help to
>>>see better what is going on in the program to do a
>>>much shorter sequence, with just the basic chords (and leaving
>>>out the dieses of course). Could be nice to do that if you are
>>>interested.

[I wrote:]
>>I am always up for challenges.

[Robert:]
>Okay, I'll try a shorter piece with much fewer notes, but same
>basic idea (more or less).

Kyool!

[JdL:]
>>No. Just an occasional chord with non-self-consistent vertical
>>springs does a lot of "damage" to the RMS numbers, not to mention
>>causing huge vertical pain to be calculated when vertical springs are
>>stiff. I can run your piece with vertical springs at 2^16 of nominal,
>>but I don't think there'd be much vertical improvement. I don't
>>currently have, but could add, detection and reporting of places where
>>an "impossible" mixture of notes takes place; it is quite common in
>>practice.

[Robert:]
>Okay, I understand that.

It's actually worse because I'm using the equal3 tuning file, which I
prepared at your suggestion, in which tritones conflict with a stack of
minor thirds, and even major seconds add stress against a fourth minus
a minor third. So all the vertical deviation and pain numbers are
inflated. Taking Paul E's suggestion, tritones and seconds get zero
vertical strength, which improves the calculated vertical pain
considerably (without _necessarily_ improving the resultant tuning).

>Perhaps it's a little tricky sometimes comparing two tunings to see
>which is best, as one can listen to particularly nice intervals in one
>tuning, and then look out for the same ones in another, and doing that
>is likely to favour whichever is the one that one listens to first.

I know what you're saying; my ear is frustratingly inconsistent in its
reaction to a given tuning. Sometimes I hear horrible shifts in
sounding notes, other times not; ditto with deviations from ideal
vertical intervals.

[JdL:]
>>Kyool! I went back and reread your previous reply and realized you
>>had stated that before as well. This system makes a lot of sense,
>>especially for sequences with just one or two voices. Can FTS output
>>a "mix-down" MIDI file suitable for any GM module?

[Robert:]
>You'll have the original midi with the root control channel prob. best
>saved from the sequencer / score editor.

>Then FTS can record all the notes played as they are played, as
>I did for the example.

>What is needed for a "mix-down" MIDI file?

I think it's what you mean by what FTS records: the control channel is
eliminated from the file, but its effects are included. Thus, any GM
module can play the fully sequence without understanding the control
messages.

>>Right! That dang channel, in the middle of the GM list; it'd be nice
>>to have an actual use for it. Every now and then I tune a sequence
>>that actually uses internal 9 for percussion, so that option also has
>>to be available.

[Robert:]
>Same here. Yes, such an awkward position; I wonder why they didn't
>make it the last one in the list.

It's something historical, kind of like the Intel chip and so many
other messes created from backward compatibility conflicting with
consistent architecture. I wish they had simply reserved one of the
128 programs for the "drum kit voice"; after all, program change on
the MIDI percussion channel is meaningless as things stand, a real waste
of flexible space. But, I already have the ugly code to work around
the problem. And we're stuck with it till further notice.

[JdL:]
>>Tell you what else I'd like to have: a continuous controller pedal
>>attached to absolute tuning. This would allow shifting from one
>>preset tuning to another while also taking control of drift very
>>explicitly. The usual spring-loaded hand-operated pitch wheel is
>>useless in this regard.

[Robert:]
>I wonder if that is related to the next section I'm planning,
>which is to add option to morph from one scale to another,
>idea of Graham's - at present it does it for mean-tone,
>by varying the comma, but one could morph from any scale
>to any other with same number of notes, by linear interpolation
>of the note values.

>Or, use the controller to morph between a succession of
>several scales all with the same number of notes.

>However, I have a feeling you have something else in mind.

What I have in mind is to use a continuous foot controller exactly as
the pitch wheel is now used: to add (or subtract) cents of offset to
every pitch class of whatever tuning is chosen by the other means. I
visualize my left foot on organ pitch pedals, one or two octaves worth,
and my right foot on the continuous controller.

[JdL:]
>>It suddenly occurs to me that, when I'm taking in a sequence that is
>>already tuned, I could have my program differentiate pitch classes
>>right from those tuning numbers! I already have an option to take in
>>pitch bends as gliss (adding them to the tuning I calculate), so this
>>would be just one other way to deal with them. I'm not sure what I'd
>>do if a pitch class has a whole _bunch_ of input tunings, though...
>>Heck, I _could_ just base grounding spring targets upon the values
>>input for each note, suppressing any adjustment of grounding targets
>>within the relaxation process. That way, I could adaptively tune
>>pieces prepared from other n-tET's very simply. Can't believe I've
>>never thought of this before...

[Robert:]
>That's a nice idea. So composer could for example write a piece in,
>say, 7-tet, and you can adaptively tune it to make the 3/2s more mellow
>(and perhaps target 11/9s too?) if desired. Do I understand this right?

Yes.

JdL

🔗Herman Miller <hmiller@IO.COM>

9/9/2001 4:54:38 PM

On Fri, 07 Sep 2001 12:37:00 -0600, "John A. deLaubenfels"
<jdl@adaptune.com> wrote:

>Cool! Thanks for the refs. I don't have this coded yet, but as soon as
>I do, I'll throw your pieces at it. Another bit of information is
>needed, however: given a certain input interval, what does the program
>use as the _target_ interval? In the case of 14-tET, for example, it
>is clear that 8 steps should target 3:2, but what number of steps, if
>any, should target 5:4, or 6:5? What targets should be formed from
>other increments of 14-tET? Ideally, this should go into a "tuning"
>file, to allow for experimentation without recompilation.

You could start with just the closest 12-TET interval as a first guess.

I think 14-TET has more of a 7-limit flavor, so you could try 7/6 at 3
steps and 9/7 at 5 steps. Also note that 3 steps divides the perfect fourth
into two equal parts, which may be used melodically as equal divisions. 4
steps could be any flavor of neutral third, 11/9 if you're going for an
11-limit tuning. The "tritone" (umm, semioctave?) at 7 steps is ambiguous
just like in 12-TET. I don't think it matters much exactly which just
intervals are targeted for the seconds and sevenths, but 1 step of 14-TET
is very close to 21/20, and 2 steps could be either 10/9 or 11/10.

26-TET has a nearly perfect 7/4 at 21 steps and a good 11/8 at 12 steps.
The diatonic semitone is very wide (3 steps), so I use a 2-step "semitone"
in the piece; the whole tone is 4 steps, so the diatonic scale is 0, 4, 8,
11, 15, 19, 23, 26.

--
see my music page ---> ---<http://www.io.com/~hmiller/music/index.html>--
hmiller (Herman Miller) "If all Printers were determin'd not to print any
@io.com email password: thing till they were sure it would offend no body,
\ "Subject: teamouse" / there would be very little printed." -Ben Franklin