Scale formats, monzos and mus

The Scala scale format interprets a float as cents and an integer or
ratio as frequency ratios. Two other formats which I would be
inclinded to use if they were available would be monzos and mus. If
Manuel added it, this would mean |2> would be 4, |-1 1> would be 3/2,
and |-1 -1 0 1> would be 7/6, for example. For integer amounts of mu,
we might put the integers in parenthesis, so that (196608) would be
2, (115008) would be 3/2, and so forth.

on 1/7/04 1:24 AM, Gene Ward Smith <gwsmith@svpal.org> wrote:

> The Scala scale format interprets a float as cents and an integer or
> ratio as frequency ratios. Two other formats which I would be
> inclinded to use if they were available would be monzos and mus. If
> Manuel added it, this would mean |2> would be 4, |-1 1> would be 3/2,
> and |-1 -1 0 1> would be 7/6, for example. For integer amounts of mu,
> we might put the integers in parenthesis, so that (196608) would be
> 2, (115008) would be 3/2, and so forth.

Personally I'd rather see the unit "mu" appear after the number, so as not
to use up parens yet, in case another useful unit comes along, and also to
maximize the human-readable aspect.

-Kurt

--- In tuning@yahoogroups.com, Kurt Bigler <kkb@b...> wrote:
> on 1/7/04 1:24 AM, Gene Ward Smith <gwsmith@s...> wrote:

For integer amounts of mu,
> > we might put the integers in parenthesis, so that (196608) would
be
> > 2, (115008) would be 3/2, and so forth.
>
> Personally I'd rather see the unit "mu" appear after the number, so
as not
> to use up parens yet, in case another useful unit comes along, and
also to
> maximize the human-readable aspect.

It occured to me after I posted this that this would be better, for
another reason--not to confuse this with what Scala does with seq
files.

196608mu is a 2
115008mu is a 3/2
320mu is a 32805/32768

etc. Excellent for presenting scales.

hi Gene and everyone else,

--- In tuning@yahoogroups.com, "Gene Ward Smith" <gwsmith@s...> wrote:

> The Scala scale format interprets a float as cents and
> an integer or ratio as frequency ratios. Two other formats
> which I would be inclinded to use if they were available
> would be monzos and mus. If Manuel added it, this would
> mean |2> would be 4, |-1 1> would be 3/2, and |-1 -1 0 1>
> would be 7/6, for example. For integer amounts of mu,
> we might put the integers in parenthesis, so that (196608)
> would be 2, (115008) would be 3/2, and so forth.

are we all in agreement now that a monzo should be
expressed as |a b ...> with the "pipe" symbol on the
left and the "greater-than" on the right?

what about the idea of using commas after certain exponents?
wasn't the idea to group them as follows? :

2 3, 5 7 11, 13 17 19, 23 29 31, etc.

-monz

--- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> hi Gene and everyone else,

> are we all in agreement now that a monzo should be
> expressed as |a b ...> with the "pipe" symbol on the
> left and the "greater-than" on the right?

It's the notation I prefer; it goes with corresponding notation for
vals. It's the Dirac bra-ket notation applied to music.

> what about the idea of using commas after certain exponents?
> wasn't the idea to group them as follows? :
>
> 2 3, 5 7 11, 13 17 19, 23 29 31, etc.

If someone wants to stick them in, I suppose they can, but why make
this extra complexity a standard? I don't much like it myself.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <gwsmith@s...> wrote:
> --- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> > hi Gene and everyone else,
>
> > are we all in agreement now that a monzo should be
> > expressed as |a b ...> with the "pipe" symbol on the
> > left and the "greater-than" on the right?
>
> It's the notation I prefer; it goes with corresponding notation for
> vals. It's the Dirac bra-ket notation applied to music.
>
> > what about the idea of using commas after certain exponents?
> > wasn't the idea to group them as follows? :
> >
> > 2 3, 5 7 11, 13 17 19, 23 29 31, etc.
>
> If someone wants to stick them in, I suppose they can, but why make
> this extra complexity a standard? I don't much like it myself.

This was originally my suggestion:

/tuning-math/message/7436

This isn't extra *complexity* if it *simplifies* the task of making
the notation more human-readable. Just as it isn't absolutely
necessary to insert commas every third place from the decimal point
for large numbers, it does make them much easier to read.

But I suggest making this a *convention* rather than a *standard*,
since it would be completely optional.

--George

Gene wrote:
> If Manuel added it, this would
> mean |2> would be 4, |-1 1> would be 3/2, and |-1 -1 0 1>
> would be 7/6, for example.

Yes, that would be a useful addition. Not to the scale
format however, but as a method to enter a ratio.

>196608mu is a 2
>115008mu is a 3/2

With the "calc" and ":=" commands, they can be entered as
$m^196608
$m^115008
So that's very close.

Manuel

--- In tuning@yahoogroups.com, "Manuel Op de Coul"
<manuel.op.de.coul@e...> wrote:
>
> Gene wrote:
> > If Manuel added it, this would
> > mean |2> would be 4, |-1 1> would be 3/2, and |-1 -1 0 1>
> > would be 7/6, for example.
>
> Yes, that would be a useful addition. Not to the scale
> format however, but as a method to enter a ratio.

Why not to the scale format? It would get by the current restriction
caused by big integers, and would be very useful in connection with
temperaments in which those big integers occur. The same comment
applies to seq files.

> >196608mu is a 2
> >115008mu is a 3/2
>
> With the "calc" and ":=" commands, they can be entered as
> $m^196608
> $m^115008

That's of no use for the purpose I had in mind, however.

Gene wrote:
>Why not to the scale format?

It would break other applications. The format has become something
of a standard, and has been changed never.

>That's of no use for the purpose I had in mind, however.

You can also use Scala command files do specify scales.

Manuel

>Gene wrote:
>>Why not to the scale format?
>
>It would break other applications. The format has become something
>of a standard, and has been changed never.

You could do it behind a !. If the scale degree is followed
by a ! on the same line, and then by the chars <mu>, say...

Or you could create a new format based on xml, so that those
who want these features can have them, and if it becomes the
new standard it can be extended without breaking itself.

>>That's of no use for the purpose I had in mind, however.
>
>You can also use Scala command files do specify scales.

Probably Gene's thinking of generating .scl files directly from
maple automation, or something.

-Carl

--- In tuning@yahoogroups.com, "Manuel Op de Coul"
<manuel.op.de.coul@e...> wrote:
>
> Gene wrote:
> >Why not to the scale format?
>
> It would break other applications. The format has become something
> of a standard, and has been changed never.
>
> >That's of no use for the purpose I had in mind, however.
>
> You can also use Scala command files do specify scales.

Scala won't specify scales well enough to suit me, which is what I'm
trying to correct, by adding something which gets around the
uncertainly of floating point numbers and the limitations of its
handling of rational numbers. The idea is that I want to be able to
classify and compare scales and know I'm doing it right.

--- In tuning@yahoogroups.com, Carl Lumma <ekin@l...> wrote:

> Probably Gene's thinking of generating .scl files directly from
> maple automation, or something.

Correct. More importantly, Gene is thinking he wants to know if two
scales are equal, or inversely equal, and not have to guess if Scala
is going to give the correct answer, and he wants to be able to sort
and compare scales in Maple, doing the above himself, in a format
Scala can handle. It also makes sense to me that Scala would be able
to deal with JI without the limitations it now has.

> Probably Gene's thinking of generating .scl files directly from
> maple automation, or something.

Gene could also write .cmd files instead. Something like
this:

! example.cmd
! Scale definition with expressions
set description
This is just an example
clear
%n+1 := 2^-1+3^3+13^-1
%n+1 := 2^-2+3^0+5^1
! etc.
%n+1 := 2^1

It not exactly the | > notation yet but the exponents can have
any size. Of course the result will be in cents if an integer
becomes too large.

>It also makes sense to me that Scala would be able
>to deal with JI without the limitations it now has.

Well it was designed for musicians rather than mathematicians.
Otherwise it would be quite different.
Adding unbounded integers would be a very big job to retrofit in,
and there's not so much "market" for it that I'm aware of.

Manuel