[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Diatonic notation system

From: Hans Aberg
Subject: Re: Diatonic notation system
Date: Mon, 8 Dec 2008 11:04:11 +0100

On 8 Dec 2008, at 04:53, Graham Breed wrote:

Now, that leads to the model I indicated if one uses an abstract perfect
fifth, as the m and m can extracted from it by iteration and octave

Right.  But the actual fifth has to be specified so you need an init
file to do that.  The exact meaning of the alterations also have to be
specified in an init file.  So there has to be a different init file
for each Sagittal context if you want any reasonable MIDI output.

So it might be better to write an intermediate sound file with the diatonic structure. Then it can be used to return the output without having to recompile the typeset output.

Here I am not sure if the idea is to indicate specific pitch alterations. The problem with that is the same as with fixing a tuning system: it may differ with musical interpretational context, even if one agrees on that
there should be alteration.

They can be as fixed as the composer chooses.  But you can't expect a
computer to understand that interpretational context.  Specifying
fixed alterations is enough.

So then using neutral seconds seems right.

For what?

The question is the composer chooses pitches, or abstract intervals as in Arab and Persian music. The latter is more powerful, because intervals can be adjusted with the tuning.

There is also a paper
 Tuning, Tonality, and Twenty-Two-Tone Temperament
 Paul Erlich
which constructs generalized 10-tone diatonic scales in E22.

He then does not seem to realize that standard Western music notation will
work, if one only alters the number of notes per octave.

He does so!  There are examples on the last page.

I think he introduces special accidental symbols, which are unnecessary.

This is rather special, but the model I gave will work with that, too.

I am looking at other cases like this.  There's a list to discuss
microtonal tools, which started out very optimistically.  What you're
talking about are, indeed, "diatonic notations":

This might be the same idea: to get the Western music notation working in this generalization, one needs really only abstract m and M, and an octave plus names A B C D E F G ... for specific combinations of them. To get the G- C- or F- clef working in this generality, those note names needs to be defined.

Also, I made keyboard map, which I have used in Scala playing in mainly E31 for the last couple of months:
   A#  B#  Cx  Dx  Ex
  A   B   C#  D#  E#  Fx  Gx  Ax  Bx
    Bb  C   D   E   F#  G#  A#  B#
      Cb  Db  Eb  F   G   A   B   C'# D'#
        Dbb Ebb Fb  Gb  Ab  Bb  C'  D'  E'
It will them work in any such generalized diatonic system.

If you play standard music, you will find that the melodic development takes place by moving between the diagonals /, where a change on such a diagonal represents a scale alterations.

In the p m + q M model, the number p + q is the scale degree. Altering with accidentals does not change this scale degree. A similar thing happens in Persian music, when adding the neutral second: the intermediate pitch ends up on the / diagonal.

The diagram above makes it is easy to compute transpositions, as they are merely translations.

I think they can be made to work in Lilypond.  The problems are:

- You have to override the standard octave numbers

I suspect one has to scrap the current model, but if the change can be made, it might be simpler. Only the core developers could know that.

But I think the simplest would be to use pairs (p, q) internally, and compute octaves at need from that.

- You need a different init file for MIDI and printing

If one can write an intermediate diatonic file, as I described above, then that could be used for creating MIDI-files at your favorite tuning.

Then in the init file used for typesetting, the composer may have the option to choose pitches or abstract intervals. But even if the composer chooses pitches in a specific tuning, it may be best to let the intermediate file still write it diatonically, if possible, so that retuning is possible.

I think that's about as much as we can expect given how obscure they
are.  Here's the shortlist of notation types we're trying to support:

MicroABC can do some of them.  I think Lilypond should be able to do
most of them with a bit of work.

Thank you, it is a nice list, but unfortunately, most of the links lead to a porn site :-).

Several of the those systems are designed for a specific tuning, and the problem with that is that is not how musical interpretation takes place.

This is something that has been criticized in the Turkish musical notation systems. There are some papers: Ozan Yarman, "A Comparative Evaluation of Pitch Notations in Turkish Makam Music"
  Nail YavuzogĖ†lu, "Equal Temperament in Turkish Music"
(If you can't find them, I can send them to you.)

The first paper (I think) says that the E53 Arel-Ezgi-Uzdilek (AEU) notation system was created by taking the 13th century Saffiaddin Ormavi's work, with some errors. One such is setting the sharps # to the wrong value, as shown here:

In any diatonic tuning, sharps and flats alter by the same amount M - m. In E53, M = 9, m = 4, so these accidentals should alter with 5 commas, not 4, as in the link above.

I think that the Turks want to change that, but it is difficult, because one has to go back to the original model, and make a new translation. It is not possible to do that from the current AEU notated music.

So that illustrates the problem of having notation tied to a specific tuning.

A thing that cannot be handled in a transposable way by the Western notation with strict pitch interpretation is strict Just intonation, as it uses two M's of different sizes. this can be illustrated in E72 (or E53) where (in C major), the E should be lowered one tonestep). One then gets an diatonic intermediate pitch.

But when playing this, I think two M's of different sizes in succession sounds weird. So it does not bother me, too much. :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]