Yahoo Tuning Groups Ultimate Backup tuning Re: A Mode room on line

Paul H. Erlich wrote,

>Can I ask what the user will be able to do with the modes? How easy will it
>be to try out different chords?

It would be easy to design a file format, supposing one decided on that
model.

How about something like this:

List of chords format (*.lch)

/scale_key scale key
/scale_descr descr (optionally leave out this entry and next for n-tet)
/scale_def def
/modes mode list file
/mode
def ~descr
/chords
chord def ~descr
(multiple def for drop list of chords)

Then the java, and any visiting mode browsing program could be designed to
recognise the format.

It could display the list of chords in a drop list, with the descriptions.

One could also assign short cut keys to chords, e.g. Alt + 1 for first chord
in list, ... alt + 0 for tenth (+ continue through rows of p.c. keyboard
from then on),
or Alt + A, ..., Alt + Z, or whaterver seems convenient

One could also do things like
Alt + 74 to play 7th chord in list on degree 4 of the mode

I.e. while holding down Alt key, type 7, then 4, chord played on release of
Alt key.

Alt + 7-4 to play chord 7 on degree -4 (i.e. 4 degrees below first note of
mode).

Alternatively, if one wants to use Roman numerals:
Alt 7v (for Alt +74)
Alt 7iv (for Alt + 73), etc.

(or maybe Alt + 75 would be preferred for Alt + 74? Or both as options, and
user chooses method?)

Maybe some notation for inversions as well.

Alt + 74,1 to play chord 7 on degree 4, first inversion (i.e. transpose
first note of chord up an octave, or up by degree of last note of mode in
general case where scale repeats at some other interval than the octave).

Suggestion for chord def:
Steps notation
2 2 3 ~tonic position major chord in major scale.

Alternatively
0 2 4 7 ~tonic position major chord in major scale.
Could use
/steps
or
/degrees
to specify the notation used in rest of file, choose whichever of these
seems likely to be used most often as the default.

Use b for flat, # for sharp

0 2b 4b 5 7 ~diminished seventh in major scale

(for sharps and flats, seems perhaps /degrees would be a good default)

If one wants half sharps / half flats notation, add line
/half_acc
after the /chords line, then use, say,
| for half flat
= for half sharp

(Idea of choosing those chars is that they will be easy to type on the p.c.
keyboard).

Multiple sharps / flats as say 2bb, 2b|, 4##, 4#= etc.

To specify chord somewhere other than root position for drop list:

[4] 2 2 3~major chord on 4th degree of major scale (i.e. V), steps notation
or
4 6 8 11~major chord on 4th degree of major scale (i.e. V), degrees notation

Just an idea, but I imagine if one's finished the programming to play notes
of any mode in any scale, it will be pretty easy to add chords in like this.

See what the Java programmers have to say though,

Robert

🔗Paul H. Erlich <PERLICH@ACADIAN-ASSET.COM>

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

Paul,

Sorry, should have had a line describing the mode as well:

/scale_html _12t
/mode 2 2 1 2 2 2 1 ~ major scale
/modes_list common_12t_modes.lmd
/chords
/degrees
0 2 4 7 ~ major chord
0 2b 4b 5 7 ~ diminished seventh

One can leave out the scale def for et scale because prog can work out total
number of et tones by adding all the steps in the mode def. (Supposing it is
one that repeats at the octave, if not, would need to give proper def.)

The mode is defined in terms of steps in the scale. The chord is defined as
degrees in the mode.

The b just means go back one step in the scale. So 2b means second step in
mode, i.e. 4 in scale, which prog will work out from the /mode line, then go
back 1, to 3.

# means go forward one step in scale

If you have
/half_acc

then = means go forward one step in scale, # means go forward 2 steps,
means go back one (perhaps [ would be better than | as closer to = and
numbers on keyboard, and less likely to be confused with 1), and b means go
back 2 steps.

They don't have to really be ordinary flats and sharps, and one can use ##=
to go forward 5 steps, and so on.

So it is completely general to any mode in any scale, and scale and mode
with any numbers of notes. I don't know much about what chords are used in
which scales, so that's why I chose a familiar example to show the notation.

Of course one could use other notations, just suggesting a clear example to
get started. Prob. best to fix on one simple notation however - then one can
give a concise description of how it all works, which will be helpful for
anyone wanting to add capability to browse the modes html to their program.

I've had a number of other ideas about it - the scales could be implemented
as a list rather than a drop list, with the short cut char next to the entry
like this:
1 major scale
2 diminished seventh

so you can see what key to press to get the chord .

If there was a special chords popup window with the list, then when one is
using that window (caption highlighted), one could just use the char. on its
own without the Alt to play the chord. One would then only need the Alt
shortcut method to add extras to the chord like inversions and
transpositions.

I've replaced the /scale_key line by /scale_html as more aptly describing
it, as a key to the html. Also it could be the name for the html for the
start page for those scales: say _12t.html as the start page for 12 tone
scales.

Also, when transposing the chord up / down, there are 3 poss., to keep the
identical pattern of steps in the mode (so major chord becomes minor chord
in some positions), or keep the identical pattern of steps in the scale (so
in et, chord is identical), or to keep the identical pattern of intervals
between successive notes of chord (in non et scales). One could have short
cuts for all three, e.g. Alt + 7i3 = play chord 7 on mode degree 3 with
identical intervals and Alt + 7s3 to keep identical steps (or whatever short
cut keys one likes to use for these effects).

Another thing one could add is a /time line

...(as before)
/chords
/degrees
/time 1.5
0 2 4 7 ~ major chord
/time 0.4
0 2b 4b 5 7 ~ diminished seventh

= immediately after loading the file, play the major chord for 1.5 secnods,
then the diminished seventh for 0.4 seconds.

Could be useful if one wants to demonstrate some sequence of chords. Any
chords immediately prefixed with a /time entry are played immediately after
file is loaded, any others are simply added to drop list without being
played.

Could also define an order for the /time entries, in case one wants the drop
list to be ordered in some other way from the time order:
/time 0.4
/time_order 2
0 2 4 7 ~ major chord
/time 0.4
/time_order 1
0 2b 4b 5 7 ~ diminished seventh

= play diminished seventh first, then major chord.

I could set up FTS as an example browser easily by adding an extra window to
show the chords, and option to place it on top, keep the chords window quite
small, and hide the main FTS window.

Could just look something like this:
Scales
(drop list)
Modes
(drop list)
Chords
(scrollable list)
Tune button (to show the chords as they are played)
Configure button (for customisation, if anything like that is needed).

In FTS, tune button would bring up the FTS Tune... window to show the chords
as they are played - it's fairly basic, just dots on a couple of staves with
no treble or base clef signs (window title says whether it shows treble or
base, or both), but will give some idea.

It does have a nice feature of a nudge to pitch check box, which shows lines
of stave spaced exactly according to pitch, so with two line spacings, and
notes positioned on the stave accuratedly vertically according to pitch, e.g
a third of the way between one line and the next, or whatever is
appropriate.

Also another option to show horizontal lines for the intervals of the scale
(e.g. every other note, every third note, or whatever). (N.b. with this beta
some time, I'll add horizontal lines for the intervals of the mode as
another option).

Then could do some example html pages with chords etc., preferrably copy one
from the web by someone knowledgeable about chords than to make up my own.

However I'd like to hear what the Java programmers have in mind for the
project first, and we haven't had anything from them yet this week.

Hope preparations are going well for that :-)

Robert

🔗Bill Alves <ALVES@ORION.AC.HMC.EDU>

>Paul,
>
>Sorry, should have had a line describing the mode as well:
>
Perhaps I'm missing something, but modes (if we restrict that term merely
to the construct that can be represented as a scale) may not be definable
in terms of equal temperament. Furthermore, their tuning may be flexible,
and a limit to that flexibility is not at all an easy line to draw. Also, I
for one am not that interested in chordal constructs as a dimension of
modes, especially if that list of chords is a reflection of a certain
historical/cultural style.

Not that examples of a mode's use in a specific cultural context isn't
important. While many of the modes I'm interested may have scales that
correspond to some in other cultures, I would like to know defining factors
in a certain culture beyond the scale -- appropriate motives, use of
ornaments, and so on. I would also invite the authors of this mode room to
include information on extramusical associations found in those cultures,
as in the excellent _Raga Guide_ recently published by Nimbus. I also hope
this mode room will be a growing construct and will have a mechanism for
submissions.

I would also hope that playability of these modes, as with the instruments
in each drawer as originally suggested by Lou Harrison (whose idea this
room was back in the 1960s, by the way), is all in Java to enhance the
Esperanto-like cross-platform capabilities of this endeavor. I do not have
a windows box nor do I plan to get one. I had much more specific
suggestions, but I sent those to Lydia when this topic first came up last
year. Let me know if you need them again, Lydia.

Bill

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^ Bill Alves email: alves@hmc.edu ^
^ Harvey Mudd College URL: http://www2.hmc.edu/~alves/ ^
^ 301 E. Twelfth St. (909)607-4170 (office) ^
^ Claremont CA 91711 USA (909)607-7600 (fax) ^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

>Perhaps I'm missing something, but modes (if we restrict that term merely
>to the construct that can be represented as a scale) may not be definable
>in terms of equal temperament. Furthermore, their tuning may be flexible,

There's a /scale entry as well, which one can use to define the scale, but
it can be left out if scale is et.

I don't have any suggestion for flexible tuning, except perhaps to have
separate scale defs with the intervals tuned appropriately. If the pitch
depends on context, say, a particular interval from a previous note, perhaps
one could add method for transposing notes up / down by a particular
interval by pressing a key; one would have to see whether it could be
extended depending on the examples that it's needed for.

Programming would probably be easy if one has a clear description of what
needs to be done, but user interface and file format would prob. need a lot
of thought.

>Not that examples of a mode's use in a specific cultural context isn't
>important. While many of the modes I'm interested may have scales that
>correspond to some in other cultures, I would like to know defining factors
>in a certain culture beyond the scale -- appropriate motives, use of
>ornaments, and so on. I would also invite the authors of this mode room to
>include information on extramusical associations found in those cultures,
>as in the excellent _Raga Guide_ recently published by Nimbus. I also hope
>this mode room will be a growing construct and will have a mechanism for
>submissions.

In the look up table idea, the /scale_html entry is for this - browsing prog
can use the look up table to find the html by looking in it under the
scale_html key, then in that section, find the mode by the arrangement of
steps, then the table gives a bookmark for each mode, which takes one to the
html that describes it.

How the html is arranged is independent of the lookup table.

I offered to do some demo pages to show how the look up table and chords
browsing could work, however they weren't intended to be example of how the
html would be organised, or it's content, not at all, and I'm making no
suggestions at all about that. It's not my field.

I expect one would have a coordinator for each type of scale, or section of
the site, to whom one would submit additions, as that's how these things are
often done.

>I would also hope that playability of these modes, as with the instruments
>in each drawer as originally suggested by Lou Harrison (whose idea this
>room was back in the 1960s, by the way), is all in Java to enhance the
>Esperanto-like cross-platform capabilities of this endeavor. I do not have

I'm just making suggestions, and that prob makes sense.

My suggestion though was that the Java interface uses a method that can also
be used by other programs too to browse the site, so that if one is using a
scale and mode in some other program, one can jump immediately to the page
that describes it, and learn about it.

Would be cross platform in the same way that html is, and I could add
browsing capabilities to the FTS beta as an example for Windows 95/98, and
mode room browsing capabilities could be added to any program in any
platform.

If it was thought useful to use this approach, I could provide c-code for a
skeleton browser that does all the parsing of look up table and list of
chords / scales etc. Other programmers then wouldn't need to rewrite this
code, and as c is cross platform, would be useful for programmers in any
platform.

But forget about all this if it is not useful, just trying to be helpful.

Or if anything in it is useful, use that, and forget the rest.

Robert

🔗Simon Sum <cwingsum@ctimail3.com>

Hi everyone,
First of all, thank you very much for all the ideas, suggestions and
references on the list concerning our project. I had several exams
recently so I had to put it aside. Sorry about that.

We are still thinking about the design and operation. I agree that
the
file format is quite important, especially I have to include some
discussions, reference information etc. So I am still thinking how
should I put them - put into different files or can be in same file
with proper enclosing on all the content. Robert's idea of the file
types is quite useful to us and we'll take that into consideration.

Actually, I'm a bit curious about how the modes should be stored. Is
it more useful if the ratios are in cents? If then, is it good for
allowing users to enter cents only, or allow users to enter fraction?

In the mean time, we'll keep on discussing our project with Dr. Ayers
and welcome for any ideas.

For the discussion about cross-platform, I also like to hear more
about the details. But it is probably not the thing I concern most at
the moment.

Once again, thanks for the ideas suggested recently.

Simon Sum

*********************************************************
Name: Simon, Sum Chi Wing
(Computer Science, year 3)
Email: cs_scw@stu.ust.hk
Project
webpage: http://wwwfyp.cs.ust.hk:7065
(will be available soon)
*********************************************************