Re: factor remapping

Hi Gene,

> The *rotations* of the octahedron are also abstractly S4, and permute
> the six vertices of the octahedron by one of the permutation
> representations of S4 on six elements.

That makes sense.

I can see a geometrical connection.

You can get octahedron by joining mid points of edges of a tetrahedron
(then continuing process with octahedron -> cube -> cubocatahedron)

(or equivalently, get large tetrahedron by adding smaller tetrahedra to alternate
faces of the octahedron).

So one can see from that that every permutation of the vertices of
the tetrahedron is an isometry of the octahedron. However, leaves out
the quarter turns of the octahedron, as they are not isometries of the tetrahedron.
Nor are the central inversions.

So looks as though the group of transformations by remapping the hexany
factors is another subgroup isomorphic to S4.

> That's how you would make the group go from 24 to 48 elements, the
> full group of isometries of an octahedron.

Okay, and I realised that the map from 2 3 5 7 to 1/2 1/3 1/5 1/7
is the central inversion rather than reflection in equatorial square.

Also did some figuring and found the other octahedron symmetries.

2 3 5 7 -> 3 2 5 7 = reflection in midpoint of edge, already have.

2 3 5 7 -> 3 2 7 5 = half turn about vertex

2 3 5 7 -> 3 5 2 7 = third turn about centre of face

2 3 5 7 -> 3 7 2 5 = quarter turn rotary reflection in equatorial square

2 3 5 7 -> 1/2 1/3 1/5 1/7 = central inversion.

Reflection in equatorial square = half turn + central inversion.

Quarter turn = quarter turn rotary reflection + central inversion

3 7 2 5 -> 2 3 5 7 -> 1/2 1/3 1/5 1/7

I.e. 3 -> 1/3, 7 -> 1/3 2 -> 1/5 5 -> 1/7

then one's got the octahedral group from the reflection in midpoint
of edge, third turn, and quarter turn. Add the central inversion
to get the complete orthogonal group.

(N.B. I use 2 instead of 1 here because it means program can find
the factors for remapping by factorisation, which doesn't work if
one of them is 1)

> > Do you have any suggestions for a suitable ascii format?

> I would suggest a note number, followed by a value in cents, in front
> of the rest of the score. If a program which converts an ascii score
> file to midi knows to always output note x as y cents from the
> reference frequency, you can remap the notes to other notes.

Okay, that's possible. Presumably it would be nice to show cents or ratios as appropriate
for each note? - that is easy to do in FTS as it is all programmed in.

Could also give the midi note number for the 1/1, and its freq in
herz, in a text event.

> > I can add a record to text as a third option (at present has
> > record to WAVE, and to MIDI). Could be a useful thing to have.

> I would say definitely yes.

Okay.

I wonder what ascii format to base it around?

abc is limiting for multiple parts, and rather complex to program
if converting to it from a midi file, and the midi2txt format is
easier to do, but then one can get to it anyway using the free
utility to convert a midi file to text.

I could just have option to add a text event to the midi file listing all the midi notes
from 0 to 127, and cents values or ratios from the 1/1 for each. Then user can use
mf2t to convert the midi file to ascii. Or could do the midi file save to text
in mf2t format - from the mf2t readme, it seems pretty straightforward to do that.

A remapping program can then process the ascii file, but only change the
note numbers and pitch bend data.

Except, come to think of it, it would also need to remap the channels too.
Two notes will be in same channel if they have the same pitch bend, and after
remap, especially if it changes octave relationships, it may no longer be
possible to place the same notes in the same channels.

When changing channels for pitch bends, the remapping program would also need
to keep track of which patches are in use for the notes before the
map and apply them if necessary in the new channel, and possibly
track midi controllers as well (not needed for the hexany trio).

This can sometimes get a little involved.

I wonder if there can be some way to avoid need to get into all that
for the examples you want to make?

One idea is to specify the remapping one wants in a file with same
file name as the .mid file, but with extension .midi_remap (or something).

Could look like this:

hexany_trio.midi_remap,
-----------------
reduce_octave 2/1

a = 2 3 5 7 > 3 2 5 7
b = 2 3 5 7 > 5 2 3 7
c = 2 3 5 7 > 1/5 1/2 1/7 1/3
d = 2 3 5 7 > 1/2 1/3 1/5 1/7
a b ab b2 ab2
c ac bc abc b2c ab2c
c2 ac2 bc2 abc2 b2c2 ab2c2
c3 ac3 bc3 abc3 b2c3 ab2c3

d ad bd abd b2d ab2d
cd acd bcd abcd b2cd ab2cd
c2d ac2d bc2d abc2d b2c2d ab2c2d
c3d ac3d bc3d abc3d b2c3d ab2c3d
------------------

With that saved in same folder as hexany_trio.mid
then when you open hexany_trio.mid for playing in FTS,
it would play all 48 variations.

here for ex ab2c2d = apply a then b twice, then c twice, then d
to the original scale before playing the tune.

That would be pretty easy to program.

Idea is, before playing each variation, it remaps the
scale. Keeps the order of the notes in the
scale the same each time (so transformed scale is not nec. an
ascending one).

It would be easy to do because all the programming would
be in one place, just have a little program that reads the
remap file, transforms the scale as instructed, and then
calls other routines already programmed to play the
midi clip with the transformed scale, and save it.

If recording to midi at the time, it would modify the
file name for each one and save them as:

hexany_trio_a.mid, hexany_trio_b.mid, hexany_trio ab.mid
hexany_trio_b2.mid,...

One would use hexany scale in the non octave reduced form, with
2s instead of 1s (as octave reduction 2s will confuse the remap)

For the symbols to define at head of the file, one could
use any ascii symbols except the numerals 0 to 9,
which should be plenty for most situations.

I wonder how all this fits in with what you said
about keeping octaves invariant and making sure the melody doesn't
vary wildly in your reply to Paul.

(didn't follow the matrix maths, as I don't know the context,
such as what 4-et means or the reason for using left and right
eigenvectors, or why those particular powers of 2 3 5 7) )

...............................................

I also have idea of the log to include time information
and maybe also patches, and note volumes.

The thing that would make this approach particularly
suitable is that one could also add option to read
a log in that format, and play it in FTS.

So then, you wouldn't need to get into all the
channel remapping and patch tracking for channels,
but just leave it to FTS to do it.

Not meant to be as flexible as the full midi format,
just a nice easy way of making midi clips in microtonal
scales.

This last idea might take a little bit more programming
than the other two.

.............................................

Anywya, those are the three main possiblities I can think of
at present.

> I would say whatever you do, it should allow you to at least take the
> set of all notes which appear in a given piece, and remap them to
> other notes; it doesn't seem to me what you are talking about below
> does that. There are other kinds of remappings which this won't
> support but I think getting at least that far would be grand.

As for the factor remapping channel, that would also work
for all the notes in a uniform way - possibly I didn't
explain it that well. If you play the 3 <-> 5 key on the
midi keyboard then it transforms all the scales used in
all the playing channels, by swapping 3s for 5s in them.

Details were to do with how to specify that a particular
midi note is to have that effect, and were just first
thoughts about how one might do it.

Robert

--- In tuning@y..., "Robert Walker" <robertwalker@n...> wrote:

> You can get octahedron by joining mid points of edges of a
tetrahedron
> (then continuing process with octahedron -> cube -> cubocatahedron)

Then rotations of the octahedron can convert a major (utonal)
tetahedron to a minor one, and vice-versa.

> (N.B. I use 2 instead of 1 here because it means program can find
> the factors for remapping by factorization, which doesn't work if
> one of them is 1)

Actually, I wouldn't want the program to do this in this way. The
procedure I had in mind is this:

We take 3,5,7,15,21,35 and divide by 7, getting 3/7,5/7,1,15/7,3,5;
the reason for this is that while we can transform in a way which
keeps vertices, edges, faces or cells invariant, we want to start by
keeping a vertex 1/1 fixed, since this is easier mathematically.

Fixing 1 and rotating the lattice around the 7/5-1-10/7 axis, turns
our reference octahedron upside-down and moves it down. It gives us
the mapping 1->3/3, 3->3/1, 5->3/5, 7->3/7, which we can also write
in matrix form as

[1 0 0]
m = [1 -1 0]
[1 0 -1],

where we multiply row vectors by m to map them: for instance [0 1 0]
representing the 5 class is mapped to [1 -1 0], representing 3/5.
Since the determinant of the above matrix is 1, it is a rotation and
not a reflection. It represents a genuine rotation of an octahedron
since we can specify a corresponding quadratic form (distance
measure) on 7-limit classes by finding the distance of 3^a 5^b 7^c
from 1 by taking the square root of a^2+b^2+c^2+ab+ac+bc.

We now want to lift m from a transformation on octave equivalence
classes to notes in the 7-limit. If we set

[1 0 0 0]
[a 1 0 0]
M = [b 1 -1 0]
[c 1 0 -1]

then [1 0 0 0]M = [1 0 0 0]. This means that octaves are left fixed
by M, and [1 0 0 0] is an eigenvector for the value 1 for M. There
must be another eigenvector for 1 which is a column vector v such
that Mv = v. If v is the column vector

[ln(2)]
[ln(3)]
[ln(5)]
[ln(7)]

then Mv = v would mean all 7-limit notes would be left fixed. If v is
approximately such a column vector, then 7-limit notes will be
approximately fixed. In particular, let us take a column vector
derived from the division of the octave into four parts, which gives
us

[ 4]
[ 6]
[ 9]
[11].

If this is left fixed by M, 7-limit notes will not wander too wildly.
They will in fact transform so that 8/7, 7/6, 6/5 and 5/4 stay in a
class of one-step intervals; 4/3, 7/5, 10/7 and 3/2 in a class of two-
step intervals, and 8/5,5/3,12/7 and 7/4 in a class with three steps,
so that 1, 3, 5 and 7 go to distinct classes. If now we solve for a,
b, and c we find we get integer values and so we can do this lifting,
obtaining

[1 0 0 0]
[0 1 0 0]
M = [3 1 -1 0]
[4 1 0 -1].

If we write this multiplicatively, we get 2->2, 3->3, 5->24/5, and
7->48/7; this is in fact the major-minor, minor-major transformation
in the 7-limit.

Let us now look at a rotation by a quarter turn. If we rotate counter-
clockwise around the axis passing through 1 and perpendicular to the
square with corners 1, 3, 7/5 and (opposite 1) 15/7, we get a map r
which sends 1->7/7, 3->7/5, 5->7/1, 7->7/3. If we write this in
matrix form, we get

[ 0 -1 -1]
r = [ 0 0 1]
[-1 0 -1],

which again has determinant 1 and is a rotational isometry. If we try
to lift this as before, we find we can't--we are "obstructed" as a
mathematician might say. However, we can lift it if we do so
inversely, by sending 2->1/2, and making the 4-division column vector
an eigenvector for the eigenvalue -1. When we do that, we get

[-1 0 0 0]
[-2 0 -1 1]
R = [-5 0 0 1]
[ 4 1 0 -1],

which is of order 4 and which approximately inverts. While r had a
determinant of 1, det(R) = -1, but it does correspond to a rotation
of the hexany even so.

Finally, we want an element of order 3. Rotating in the plane of a
triangular lattice lying in the 5-limit, we send 1->5/5, 3->1/5 and
5->3/5; we then extend this to the 7-limit by 7->7/5. However, we now
run into trouble. This transformation works very well in the 5-limit
when we make it preserve the 3-et instead of the 4-et, but in the 7-
limit we find we cannot lift it and preserve the 4-et either directly
or inversely. We can do the best we can in the situation by making
the lifting a matrix of order three which preserves the column vector
of logarithms as closely as we can contrive. When we do this, we lift

[0 -1 0]
g = [1 -1 0]
[0 -1 1]

to

[1 0 0 0]
[3 0 -1 0]
G = [3 1 -1 0]
[2 0 -1 1],

which written multiplicatively is the map 2->2, 3->8/5, 5->24/5, and
7->28/5.

If we apply these mappings, the hexany will be transposed to another.
However, we can shift it back. If we take the vectors representing
the vertices of the hexany and average them, we find its center, so
all we need do is move the center of the transformed hexany back to
the original. For instance, our starting hexany written in vector
form is [0 0 0], [1 0 0], [0 1 0], [0 1 -1], [1 1 -1] and [1 0 -1];
adding these up gives us [3 3 -3] and so the center is
[1/2 1/2 -1/2]. Transforming this by r gives us [0 0 0], [0 -1 1],
[0 0 1], [1 0 0], [1 -1 1] and [1 -1 0]. Adding these gives us
[3 -3 3] with center [1/2 -1/2 1/2]. Then [3 3 -3] - [3 -3 3] =
[0 6 -6], so dividing by six we find we can shift it back by adding
[0 1 -1]; note that this way of doing things means we can use integer
arithmetic.

By successively applying these transformations it is easy to get all
24 rotations of the octahedron; the full isometry group is obtained
by simply adding the negatives of the rotation matrices; in other
words, multiplying them by

[-1 0 0 0]
[ 0 -1 0 0]
[ 0 0 -1 0]
[ 0 0 0 -1],

which multiplicatively is simply the inversion map x--1/x.

I hope all that was clear!

> Okay, that's possible. Presumably it would be nice to show cents or
ratios as appropriate
> for each note? - that is easy to do in FTS as it is all programmed
in.

Sounds good; I take it you have a continued fraction routine in FTS?

> I wonder if there can be some way to avoid need to get into all that
> for the examples you want to make?

Probably, but the other way sounds like a wonderful addition to FTS.

--- In tuning@y..., genewardsmith@j... wrote:

> [1 0 0 0]
> [3 0 -1 0]
> G = [3 1 -1 0]
> [2 0 -1 1],
> > which written multiplicatively is the map 2->2, 3->8/5, 5->24/5,
and > 7->28/5.

I became so wrapped up in group theory I forgot to mention an
important point, which is that from a practical, musical perspective
we don't want to use G, we want to use

[1 0 0 0]
[4 0 -1 0]
S = [3 1 -1 0]
[2 0 -1 1],

and instead of using S^2 we take instead

[1 0 0 0]
[1 -1 1 0]
S^(-1) = [4 -1 0 0]
[2 -1 0 1].

This is no longer of finite order, which doesn't much matter though
it does mean intervals are no longer locked into the classes I
mentioned. However, these are the transformations which sound right,
and it *does* now generate a group (to which we can add major/minor
and inversion) on 5-limit harmonies. Multiplicitively, we can write
these as S: 2->2, 3->16/5, 5->24/5, 7->28/5; and
S^(-1): 2->2, 3->10/3, 5->16/3, and 7->28/3.

In practice I would suggest running through powers of R, M and taking
+-1, giving a group of order 16. When that has run its course, apply
S and get 16 further variations, and when that finishes, apply S^(-1)
for the last 16 variations. You could wrap the whole thing up by
playing the starting piece again. When I did this on a hexany, the
effect of something constantly changing and yet staying the same was
hypnotic.

If I can...

You dont make any music!
You only discuss ....
It is sad...

--- Robert Walker <robertwalker@ntlworld.com> a
�crit�: > Hi Gene,
>
> > The *rotations* of the octahedron are also
> abstractly S4, and permute
> > the six vertices of the octahedron by one of the
> permutation
> > representations of S4 on six elements.
>
> That makes sense.
>
> I can see a geometrical connection.
>
> You can get octahedron by joining mid points of
> edges of a tetrahedron
> (then continuing process with octahedron -> cube ->
> cubocatahedron)
>
> (or equivalently, get large tetrahedron by adding
> smaller tetrahedra to alternate
> faces of the octahedron).
>
> So one can see from that that every permutation of
> the vertices of
> the tetrahedron is an isometry of the octahedron.
> However, leaves out
> the quarter turns of the octahedron, as they are not
> isometries of the tetrahedron.
> Nor are the central inversions.
>
> So looks as though the group of transformations by
> remapping the hexany
> factors is another subgroup isomorphic to S4.
>
> > That's how you would make the group go from 24 to
> 48 elements, the
> > full group of isometries of an octahedron.
>
> Okay, and I realised that the map from 2 3 5 7 to
> 1/2 1/3 1/5 1/7
> is the central inversion rather than reflection in
> equatorial square.
>
> Also did some figuring and found the other
> octahedron symmetries.
>
> 2 3 5 7 -> 3 2 5 7 = reflection in midpoint of edge,
> already have.
>
> 2 3 5 7 -> 3 2 7 5 = half turn about vertex
>
> 2 3 5 7 -> 3 5 2 7 = third turn about centre of face
>
> 2 3 5 7 -> 3 7 2 5 = quarter turn rotary reflection
> in equatorial square
>
> 2 3 5 7 -> 1/2 1/3 1/5 1/7 = central inversion.
>
> Reflection in equatorial square = half turn +
> central inversion.
>
> Quarter turn = quarter turn rotary reflection +
> central inversion
>
> 3 7 2 5 -> 2 3 5 7 -> 1/2 1/3 1/5 1/7
>
> I.e. 3 -> 1/3, 7 -> 1/3 2 -> 1/5 5 -> 1/7
>
> then one's got the octahedral group from the
> reflection in midpoint
> of edge, third turn, and quarter turn. Add the
> central inversion
> to get the complete orthogonal group.
>
> (N.B. I use 2 instead of 1 here because it means
> program can find
> the factors for remapping by factorisation, which
> doesn't work if
> one of them is 1)
>
> > > Do you have any suggestions for a suitable ascii
> format?
>
> > I would suggest a note number, followed by a value
> in cents, in front
> > of the rest of the score. If a program which
> converts an ascii score
> > file to midi knows to always output note x as y
> cents from the
> > reference frequency, you can remap the notes to
> other notes.
>
> Okay, that's possible. Presumably it would be nice
> to show cents or ratios as appropriate
> for each note? - that is easy to do in FTS as it is
> all programmed in.
>
> Could also give the midi note number for the 1/1,
> and its freq in
> herz, in a text event.
>
> > > I can add a record to text as a third option (at
> present has
> > > record to WAVE, and to MIDI). Could be a useful
> thing to have.
>
> > I would say definitely yes.
>
> Okay.
>
> I wonder what ascii format to base it around?
>
> abc is limiting for multiple parts, and rather
> complex to program
> if converting to it from a midi file, and the
> midi2txt format is
> easier to do, but then one can get to it anyway
> using the free
> utility to convert a midi file to text.
>
> I could just have option to add a text event to the
> midi file listing all the midi notes
> from 0 to 127, and cents values or ratios from the
> 1/1 for each. Then user can use
> mf2t to convert the midi file to ascii. Or could do
> the midi file save to text
> in mf2t format - from the mf2t readme, it seems
> pretty straightforward to do that.
>
> A remapping program can then process the ascii file,
> but only change the
> note numbers and pitch bend data.
>
> Except, come to think of it, it would also need to
> remap the channels too.
> Two notes will be in same channel if they have the
> same pitch bend, and after
> remap, especially if it changes octave
> relationships, it may no longer be
> possible to place the same notes in the same
> channels.
>
> When changing channels for pitch bends, the
> remapping program would also need
> to keep track of which patches are in use for the
> notes before the
> map and apply them if necessary in the new channel,
> and possibly
> track midi controllers as well (not needed for the
> hexany trio).
>
> This can sometimes get a little involved.
>
> I wonder if there can be some way to avoid need to
> get into all that
> for the examples you want to make?
>
> One idea is to specify the remapping one wants in a
> file with same
> file name as the .mid file, but with extension
> .midi_remap (or something).
>
> Could look like this:
>
> hexany_trio.midi_remap,
> -----------------
> reduce_octave 2/1
>
> a = 2 3 5 7 > 3 2 5 7
> b = 2 3 5 7 > 5 2 3 7
> c = 2 3 5 7 > 1/5 1/2 1/7 1/3
> d = 2 3 5 7 > 1/2 1/3 1/5 1/7
> a b ab b2 ab2
> c ac bc abc b2c ab2c
> c2 ac2 bc2 abc2 b2c2 ab2c2
> c3 ac3 bc3 abc3 b2c3 ab2c3
>
> d ad bd abd b2d ab2d
> cd acd bcd abcd b2cd ab2cd
> c2d ac2d bc2d abc2d b2c2d ab2c2d
> c3d ac3d bc3d abc3d b2c3d ab2c3d
> ------------------
>
> With that saved in same folder as hexany_trio.mid
> then when you open hexany_trio.mid for playing in
> FTS,
> it would play all 48 variations.
>
> here for ex ab2c2d = apply a then b twice, then c
> twice, then d
> to the original scale before playing the tune.
>
> That would be pretty easy to program.
>
> Idea is, before playing each variation, it remaps
> the
> scale. Keeps the order of the notes in the
> scale the same each time (so transformed scale is
> not nec. an
> ascending one).
>
> It would be easy to do because all the programming
> would
> be in one place, just have a little program that
> reads the
> remap file, transforms the scale as instructed, and
> then
> calls other routines already programmed to play the
> midi clip with the transformed scale, and save it.
>
> If recording to midi at the time, it would modify
> the
> file name for each one and save them as:
>
> hexany_trio_a.mid, hexany_trio_b.mid, hexany_trio
> ab.mid
> hexany_trio_b2.mid,...
>
> One would use hexany scale in the non octave reduced
> form, with
> 2s instead of 1s (as octave reduction 2s will
> confuse the remap)
>
> For the symbols to define at head of the file, one
> could
> use any ascii symbols except the numerals 0 to 9,
> which should be plenty for most situations.
>
> I wonder how all this fits in with what you said
> about keeping octaves invariant and making sure the
> melody doesn't
> vary wildly in your reply to Paul.
>
> (didn't follow the matrix maths, as I don't know the
> context,
> such as what 4-et means or the reason for using left
> and right
> eigenvectors, or why those particular powers of 2 3
> 5 7) )
>
> ...............................................
>
> I also have idea of the log to include time
> information
> and maybe also patches, and note volumes.
>
> The thing that would make this approach particularly
> suitable is that one could also add option to read
> a log in that format, and play it in FTS.
>
> So then, you wouldn't need to get into all the
> channel remapping and patch tracking for channels,
> but just leave it to FTS to do it.
>
> Not meant to be as flexible as the full midi format,
> just a nice easy way of making midi clips in
> microtonal
> scales.
>
> This last idea might take a little bit more
> programming
> than the other two.
>
> .............................................
>
>
> Anywya, those are the three main possiblities I can
> think of
> at present.
>
> > I would say whatever you do, it should allow you
> to at least take the
> > set of all notes which appear in a given piece,
> and remap them to
> > other notes; it doesn't seem to me what you are
> talking about below
> > does that. There are other kinds of remappings
> which this won't
> > support but I think getting at least that far
> would be grand.
>
> As for the factor remapping channel, that would also
> work
> for all the notes in a uniform way - possibly I
> didn't
> explain it that well. If you play the 3 <-> 5 key on
> the
> midi keyboard then it transforms all the scales used
> in
> all the playing channels, by swapping 3s for 5s in
> them.
>
> Details were to do with how to specify that a
> particular
> midi note is to have that effect, and were just
> first
> thoughts about how one might do it.
>
> Robert
>
>
>
>
>
>
>

___________________________________________________________
Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr !
Yahoo! Courrier : http://fr.mail.yahoo.com

Hi Gene,

I hope all that was clear!

Basic idea of the approach is, yes. Some of the details require results
that I'm hazy about.

There's one point that I would particularly like to understand, as it is central to
your idea:

> then [1 0 0 0]M = [1 0 0 0]. This means that octaves are left fixed
> by M, and [1 0 0 0] is an eigenvector for the value 1 for M. There
> must be another eigenvector for 1 which is a column vector v such
> that Mv = v. If v is the column vector

> [ln(2)]
> [ln(3)]
> [ln(5)]
> [ln(7)]

> then Mv = v would mean all 7-limit notes would be left fixed. If v is
> approximately such a column vector, then 7-limit notes will be
> approximately fixed. In particular, let us take a column vector

Here the idea is that you've got some representation of a number
as
2^x*3^y*5^z*7^w

and you want to transform it to
2^x'*3^y'*5^z'*7^w'
in a way that preserves all notes which have y=z=w=0 (octaves)

and that keeps other notes as close as possible to their
original size.

That [1 0 0 0] is a left eigenvector shows that one preserves the
octaves.

Why though, does having

> [ln(2)]
> [ln(3)]
> [ln(5)]
> [ln(7)]

as a right eigenvector
mean that one preserves all the 7 limit notes?

I've done a bit of puzzling out but can't quite see it yet...

Anyway, it's very nice, and I could program FTS to read a matrix
and use it to transform 7 limit notes.

One doesn't know till one gets down to it, but I think it would be pretty easy.

Here is my idea for the file format:

Reserve I for identity matrix, then:

hexany_trio.midi_remap,
-----------------
factors_to_remap 2 3 5 7
preserve cofg_of_scale
M =
1 0 0 0
0 1 0 0
3 1 -1 0
4 1 0 -1
!reflection order 2

R =
-1 0 0 0
-2 0 -1 1
-5 0 0 1
4 1 0 -1
!rotation order 4

S =
1 0 0 0
4 0 -1 0
3 1 -1 0
2 0 -1 1
!rotation order 3

T =
1 0 0 0
1 -1 1 0
4 -1 0 0
2 -1 0 1
!T is S^-1

U =
-1 0 0 0
0 -1 0 0
0 0 -1 0
0 0 0 -1
!inversion

I R R2 R3 M MR MR2 MR3
U RU R2U R3U MU MRU MR2U MR3U
S RS R2S R3S MS MRS MR2S MR3S
SU RSU R2SU R3SU MSU MRSU MR2SU MR3SU
T RT R2T R3T MT MRT MR2T MR3T
TU RTU R2TU R3TU MTU MRTU MR2TU MR3TU
I
------------------

The ! lines are comments.

The line
preserve cofg_of_scale

means that one is to find the product of all the ntoes of the scale, and take nth root
where n is number of notes.

Then do same for the remapped scale.

Then divide all the notes in the remapped scale by the ratio of these
two values.

This will have same effect as adding your [0 1 -1] etc., but be
easier to program.

As before, MR3TU means apply M then R three times, then T, then U.

Robert

--- In tuning@y..., "Robert Walker" <robertwalker@n...> wrote:

> Why though, does having
>
> > [ln(2)]
> > [ln(3)]
> > [ln(5)]
> > [ln(7)]
>
> as a right eigenvector
> mean that one preserves all the 7 limit notes?

If you have a note [a b c d], then playing the note can be accomplised
by computing exp(a ln(2) + b ln(3) + c ln(5) + d ln(7)). This we may
regard as multiplying the row vector u = [a b c d] by the column
vector of v logs, and applying exp; it is exp(u*v) where the "*" is
matrix multiplication. When we transform by a matrix M, we get instead
exp(u*M*v). We can think of this in two ways: either as u*M
transforming the notes u, which are then played as usual using the
tuning defined by v (note remapping), or as M transforming the tuning
u to M*u, which then plays the note v in a different way (generator
remapping.) From the point of note remapping, if u*M = u then the
note defined by u (eg the octave) is left fixed by M. From the point
of view of generator remapping, if M*v = v then the tuning defined by
v is left fixed by M. If the 4-et tuning is left fixed by M, then any
transformations by M will sound the same if played in the 4-et, which
limits how much they can vary.

> -----------------
> factors_to_remap 2 3 5 7
> preserve cofg_of_scale
> M =
> 1 0 0 0
> 0 1 0 0
> 3 1 -1 0
> 4 1 0 -1
> !reflection order 2

Actually, M is a rotation of order 2.
> I R R2 R3 M MR MR2 MR3
> U RU R2U R3U MU MRU MR2U MR3U
> S RS R2S R3S MS MRS MR2S MR3S
> SU RSU R2SU R3SU MSU MRSU MR2SU MR3SU
> T RT R2T R3T MT MRT MR2T MR3T
> TU RTU R2TU R3TU MTU MRTU MR2TU MR3TU
> I

You somtimes have M on one side of R, and sometimes on the other.
It's safer to put them always in a consistent order, for instance

I R R2 R3 M MR MR2 MR3
U UR UR2 UR3 UM UMR UMR2 UMR3
S SR SR2 SR3 SM SMR SMR2 SMR3
SU SUR SUR2 SUR3 SUM SUMR SUMR2 SUMR3
T TR TR2 TR3 TM TMR TMR2 TMR3
TU TUR TUR2 TUR3 TUM TUMR TUMR2 TUMR3
I

Correction:

So exp(u'*v) ~= exp(u*v), so u and u' are similar in size as ratios.
(v instead of w in last line)

Robert

--- In tuning@y..., "Robert Walker" <robertwalker@n...> wrote:
> Correction:

This looks as if it might be a correction to a file which has not yet
arrived, but I've waited and so such file has appeared. Can you
clarify?

Hi Gene,

> If you have a note [a b c d], then playing the note can be accomplised
> by computing exp(a ln(2) + b ln(3) + c ln(5) + d ln(7)). This we may
> regard as multiplying the row vector u = [a b c d] by the column
> vector of v logs, and applying exp; it is exp(u*v) where the "*" is
> matrix multiplication. When we transform by a matrix M, we get instead
> exp(u*M*v). We can think of this in two ways: either as u*M
> transforming the notes u, which are then played as usual using the
> tuning defined by v (note remapping), or as M transforming the tuning
> u to M*u, which then plays the note v in a different way (generator
> remapping.) From the point of note remapping, if u*M = u then the
> note defined by u (eg the octave) is left fixed by M. From the point
> of view of generator remapping, if M*v = v then the tuning defined by
> v is left fixed by M. If the 4-et tuning is left fixed by M, then any
> transformations by M will sound the same if played in the 4-et, which
> limits how much they can vary.

Okay fine, that all makes sense.

Of course, all the numbers are just the powers of the factors, so one needs a
way to map these to the actual ratios to play. Until then
all one has is a four dimensional integer lattice.

then if v =

[ln(2)]
[ln(3)]
[ln(5)]
[ln(7)]

u -> exp(u*v) then gives the map from the integer lattice to the actual
ratios used.

If we can find an M with M*v = v, then (u*M)*v = u*(M*v)
(by associativity of matrix multiplication)
= u*v

Then if u'= u*M, we have u'*v = u*v, so u and u' are the same note,

Since we want everything integer, we can't expect an M with an exact
solution to M*v = v

However, we can find approximate solutions of the form w ~= k.v
(constant multiplier k and vector s with integer coefficients)
with M*w ~= w, and then we'll have u'*w = u*w, so (dividing by k)
u'*v ~= u*v.

So exp(u'*w) ~= exp(u*w), so u and u' are similar in size.

Great.

One other thing, what does et stand for in 4-et?

With any luck, we'll have some music to show for it soon
:-)

Robert

Hi Gene,

> This looks as if it might be a correction to a file which has not yet
> arrived, but I've waited and so such file has appeared. Can you
> clarify?

Sorry about that.

My posts to TL are getting out of sequence and delayed by
hours at present, for some reason (I posted it last night).

I see it has arrived now.

Robert

--- In tuning@y..., "Robert Walker" <robertwalker@n...> wrote:

> One other thing, what does et stand for in 4-et?

It seems everyone else calls it the 4-tet; I used to call it the
4-division or 4-system and changed over but left out the t. I suppose
I'd better quit doing that. :)

> With any luck, we'll have some music to show for it soon
> :-)

Sounds good. There are related ideas I once used in my own version of
a music-generating program, by the way. If you feel like working on
FTS they might come in handy.

--- In tuning@y..., genewardsmith@j... wrote:
> --- In tuning@y..., "Robert Walker" <robertwalker@n...> wrote:
>
> > You can get octahedron by joining mid points of edges of a
> tetrahedron
> > (then continuing process with octahedron -> cube ->
cubocatahedron)
>
> Then rotations of the octahedron can convert a major (utonal)
> tetahedron to a minor one, and vice-versa.

Major = otonal, minor = utonal.

--- In tuning@y..., Latchezar Dimitrov <latchezar_d@y...> wrote:
> If I can...
>
> You dont make any music!
> You only discuss ....
> It is sad...

Do you realize that the point of this is to be able to make a piece
of music with 48 variations? I'm sure we'll be hearing these pieces
soon. Patience! Besides, this is a _discussion_ group . . . do you
have a problem with that?

Hi Gene,

> It seems everyone else calls it the 4-tet; I used to call it the
> 4-division or 4-system and changed over but left out the t. I suppose
> I'd better quit doing that. :)

I wonder, or maybe we should all start calling it 4-et??... The first t
is pretty redundant really. 4 tone equal temperament -> 4 equal temperament.

Some of us call it 4-edo, meaning 4 equal divisions of the octave; doesn't
seem to be as much used as 4-et.

> > With any luck, we'll have some music to show for it soon
> > :-)

> Sounds good. There are related ideas I once used in my own version of
> a music-generating program, by the way. If you feel like working on
> FTS they might come in handy.

Thanks, I'll be interested to hear about them :-)

I've been thinking it might be nice to transform scales while playing
the fractal tunes in FTS.

I wonder also about transforming tunes in general. Normally they aren't going
to work harmonically in 12-tone j.i. I suppose, e.g. if they have D minor
triads, dep. on how they are meant to be heard. So presumably first you
need to find suitable j.i. ratios for a tune before you can start
transforming the harmonies?

Anyway, back to your idea:

I've got it working for the M, S, T and U arrays.

Here is a sequence for my hexany phrase using just
the M, S and T arrays, on violin:

/tuning/files/Robert%20Walker/hp_I_M_S_MS_T_MT_I.mid

The U and R arrays both invert the ratios. This sends the violin very low
(with 1/1 = middle C)

Here, using the idea that if the cofg of the remapped scale is less than
1, transpose it up by, say, 2 octaves (number of octaves for transposition
specified in the remap file.

Here it is on violin with the U:
/tuning/files/Robert%20Walker/hp_I_U_M_UM_S_US_MS_UMS_T_UT_MT_UMT_I.mid

The R array also inverts the ratios.

However, it doesn't seem to work quite yet.
Gives a very broken melody.

Here is what happens with it:

===============================

ratio 6/5 = 1.2

1 1 -1 0
*R
-1 0 0 0
-2 0 -1 1
-5 0 0 1
4 1 0 -1

=
2 0 -1 0

mapped to 0.8

Cofg shift: 0.8*12.218 = 9.77443

===============================

ratio 6/7 = 0.857143

1 1 0 -1
*R
-1 0 0 0
-2 0 -1 1
-5 0 0 1
4 1 0 -1

=
-7 -1 -1 2

mapped to 0.0255208

Cofg shift: 0.0255208*12.218 = 0.311815

===============================

Can you see what's happening from this?

I'm enjoying your idea! I say on the tunes page,
it could be seed for a larger piece later. Maybe this is it :-)

Have you thought of rotating in the 1 3 5 7 11 lattice
- and so moving the hexany to the 1 3 5 11 hexany etc?
- if your technique works for 5 factors.

I've done the programming so that a factor doesn't have to be prime,
so one can experiment with the 1 3 5 9 hexany etc,
if you can figure out good matrices for it.

Robert

32 OR 64? WHY 48 ? :))

--- Paul Erlich <paul@stretch-music.com> a �crit�: >
--- In tuning@y..., Latchezar Dimitrov
> <latchezar_d@y...> wrote:
> > If I can...
> >
> > You dont make any music!
> > You only discuss ....
> > It is sad...
>
> Do you realize that the point of this is to be able
> to make a piece
> of music with 48 variations? I'm sure we'll be
> hearing these pieces
> soon. Patience! Besides, this is a _discussion_
> group . . . do you
> have a problem with that?
>
>

___________________________________________________________
Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr !
Yahoo! Courrier : http://fr.mail.yahoo.com