reasons for TuningXML

[Aaron Andrew Hunt]

The idea of TuningXML is at least twofold:

(1) to have a more flexible way to share any kind of tuning data, in an up-to-date universal syntax
(2) to have all the things that go along with using a standard language to construct the files:
- translatability
- extensibility
- database compatibility
- etc.

I'd like to rewrite the specification with those aims in mind.

Does anyone have a reaction to the original spec? I laugh at it now but I would keep most of those database tags and the basic idea for developing the real spec would still be the same:

<http://www.h-pi.com/wordpress/?p=24>

Thanks for your time!

Aaron

[Ozan Yarman]

I think the word "TuningXML" is a tad long despite the clarity of meaning it conveys.

I suggest "TuneXML" instead. It's more catchy.

And what better platform to set a tuning programming standard than here? :)

Oz.

✩ ✩ ✩
www.ozanyarman.com

> --
> MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com
> To unsubscribe from this group, send email to mtonalist+...@googlegroups.com
>
> GOOGLE TRANSLATE IT: http://translate.google.com.tr

[Anthony Prechtl]

One thing I would like to see in a standard format is the ability to
specify notes that are close in pitch and aren't really meant to be
played consecutively. In a sense, there must be some functional
correlation between them (e.g., you'd use note X in this situation,
and note Y in that situation). This is something I noticed when you
(Aaron) played some of the Scala files at MELM. When previewing the
scales, ScalaVista would simply go up and down the scale, playing
every note along the way. The problem is that some of those notes were
very near in pitch--a sharpened or flattened version of the previous
note. Playing them consecutively didn't really give a good example of
the scale, because they probably weren't supposed to be that way.

Of course, that's not ScalaVista's fault. I'm just saying that if a
new format is being built, it might be nice to specify that, for
example, tone 7 at 100 cents and tone 8 at 120 cents are variations of
each other, rather than completely separate notes.

Anthony

[Aaron Andrew Hunt]

Great point. This is exactly what XML can do for us. To express what you've just described in XML:

<parent>
<child/>
<child/>
</parent>

Two children (tones) have the same parent (scale step).

I bet maqam theorists want to say something about this too? It seems a pertinent issue.

[Ozan Yarman]

Indeed. This "commatic/kleismatic/schismatic" note alteration gestalt in the context of "similar pitch/interval class" is a VITAL feature of Maqam music. In the recorded history of Maqam music theory, basic melody building blocks correspond to 3 famous interval classes:

1. Bakiyye = Limma (B), which can be understood to occupy a pitch space roughly between 70-120 cents.

2. Mujannab = Apotome/Neutral Second (C or J); which is understood to roughly span the 120-180 cents corridor (aptly christened the "Mujannab Zone": continuum of the anterior finger position on the neck of the ud).

3. Tanini = Whole tone (T); obviously the 9/8 interval at 204 cents, lest it is used in place of the Augmented Second (all the way up to 267 cents) in such instances as demanding the presence of two mujannabs of unspecified size in a tetrachord (such as C T C = 120+260+120 or 125+200+175, etc...).

Although this outlook has been somewhat revised and the values above thinly pinned down in 20th Century theoretical models, the established norm is to incorporate bakiyye/mujannab/tanini variants one way or another - especially when attempting to describe how they are to be performed.

The intonation issue of these three basic interval classes is entangled in the mysterious realm of "seyir" or melodic progression that defines how a particular "perde" (tone) in the sphere of a particular makam is to be inflexed. As expected, tradition immediately kicks in, requiring minute observations on how masters choose to execute the tones of a particular makam/destgah/mugam/rag...

Meanwhile, we can manually define how - among the 79 tones of my qanun for example - a subset of a master tuning containing such "commatic/kleismatic/schismatic" inflexions of any pitch/interval class can be defined in such a way as to faciliate the correct sequential playback of pitches seperated by smallish steps in any scale, while forbidding unwanted concomitant sounding of such commas/kleismas/schismas...

Cordially,
Dr. Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ozan Yarman]

Also, I think I remember the Notist program by Uğur Keçecioğlu has made possible a limited application of the "commatic pitch inflexion" feature.

-----

Uğur ağabey, senin Notist'te perdelerin makamsal icrada nasıl kaydırılacağının belirlenmesi mümkündü, değil mi? Bak top döndü dolaştı bizim önümüze geldi! :)

Oz.

✩ ✩ ✩
www.ozanyarman.com

On Jan 16, 2012, at 7:46 PM, Aaron Andrew Hunt wrote:

[Aaron Andrew Hunt]

Yes, if ScalaVista had a more informative file to read - TuningXML instead of Scala - then it could play back the scales as indicated by the file. Likewise it could do a whole lot more to categorize and make searching useful if the files contained more information than do Scala files.

Database related elements were what first gave me the idea for TuningXML. The Scala archive has way too much repetition in it, scales with no explanation, etc. All problems that should be addressed with a better format.

Now Anthony, you are pointing to more practical musical issues. This is good; this is what we need.

On Jan 16, 2012, at 12:40 PM, Anthony Prechtl wrote:

[Aaron Andrew Hunt]

Also, I know Omer Tulgan is concerned with this very issue in Nota; that is, a change in tuning that only occurs *at the end* of a melody. XML can handle this kind of thing in a logical way.

Does Notist use XML?

[Aaron Andrew Hunt]

TuneXML sounds too much like an XML for *melodies* (tunes) to me. TuningXML is more specific.

[Ozan Yarman]

ToneXML then.

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Aaron Andrew Hunt]

Excellent, Oz. This is also a main concern for H-Syetm theory and Xentone software, etc.

Let me open a new subject heading for this - tuning zones. The concept is very important and needs to be structured in the new format.

First stab at something like this.

<zone>
<names>
<name> Limma </name>
<name> Bakiyye </name>
</names>
<tones>
<format>cents</format>
<tone>80</tone>
<tone>96</tone>
<tone>110<tone>
</tones>
<zone>

With the multiple names, this is for example to show it is useful, but there can simply be a standard tag or header stating which dictionary to use, then XSL translates for various theories and languages, obviating the need for multiple names.

[Aaron Andrew Hunt]

Well, whatever, the name doesn't really matter right now and we shouldn't waste time on it ; )

Second stab at the zone:

<zone>
<name> Bakiyye </name>
<bounds>
<format> cents </format>
<bound> 70 </bound>
<bound> 120 </bound>
</bounds>
</zone>

A zone has a name, a lower and an upper bound. Anything else needed?

Yes, how it's used. But these are context specific, so I leave it to maqam theorists to suggest tags and structure for that.

On Jan 16, 2012, at 1:44 PM, Aaron Andrew Hunt wrote:

[Ozan Yarman]

I already like where this is heading. :) What sayest the others?

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ozan Yarman]

Since a considerable body of tunings are actually supersets (i.e. 53-tET for Turkish Makam Music) that do not by themselves mean much without the subset scale information, I would suggest an XML format that takes into mind tuning resolution for specific purposes.

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Robert Walker]

Hi everyone,

I woke up with a whole lot of ideas relevant to tonexml and the recent dscussion, which I'd like to share.

Hope this helps.

SCALA MODES

In Scala and Tune Smithy, this is handled using the Scala modes and Tune Smithy arpeggios. I don't know of any other program that uses the idea, so it's not widespread, but it has many advantages, you might like to think about whether something related should be used. It also has its problems too, which you are likely to encounter in some form whatever approach you use.

So - it is a reasonably well developed already existing system, so worth paying some attention to I think.

It's a way of dealing with a scale with many more notes than you actually use in a composition or section of a composition, and with notes that can be tuned in different ways depending on the section of the piece.

Manuel has actually taken a start towards a comprehensive list of modes. You can see it here:

http://www.huygens-fokker.org/docs/modename.html

As Manuel says, "The numbers represent the number of scale degrees between consecutive tones of the mode, starting from the tonic."

ADVANTAGES OF MODES

The advantage is that you can use the same mode for many slightly different tunings. E.g. the twelve tone modes can be used with any of the temperings of the twelve tone system (pythagorean, mean-tone, and all the well temperings etc). You don't need to list all the possible tunings of e.g. the major second in all possible well temperings, which would be impossible to do comprehensively (since a new well tempering can be invented at any moment) and impractical. Just give the twelve tone mode and you are done.

If you look down the list you will find a list of maqams under the 24 tone section...

3 3 4 4 2 4 4	Maqam 'Ushshaq Turki, Urfa, Isfahan, Dastgah-e Shur
3 3 4 4 2 1 3 4	Maqam Bayati
3 3 4 4 4 2 4	Maqam Nahfat
3 3 2 6 2 4 4	Maqam Saba
3 3 2 6 2 4 2 2	Maqam Saba
3 3 2 6 2 6 2	Maqam Sabr Jadid

These presumably should be tuned using one of the possible 24 tone systems of maqams, such as 53-et, or Ozan's 24 tone system, or (theoretically) a selection of 24 out of the 53 tone pythagorean MOS

LIMITATION OF THE MODE FORMAT IN ITS CURRENT FORM - THE SCALE DOESN'T HAVE TO BE SPECIFIED

When preparing for the MELM I thought I'd use one of those modes for a fractal example, but that then brings up one of the two main limitations of the modes format. That's that it doesn't specify the scale for each mode - and the other way around if you have some arbitrary 24 tone scale, you can't easily find out whether any of the 24 tone modes apply to it, and which ones to use with it. For some of the modes Manuel gives an example of a suitable scale, but in others he doesn't. In the 24 tone case then many f those modes clearly by the name, are intended for maqam tunings, but many are be intended for 24 equal tunings of Western music for instance.

So anyway, Ozan naturally had a lot on, and the maqam theorists seem to work mainly with accidentals rather than modes, and I wasn't confident with just a little time that I'd translate between the two systems correctly myself which is why I went for Margo Schulter's example instead. 

You could deal with this perhaps by following Manuel's example, and take it further, separate out all the modes into lists appropriate for different types of scale. Some of the modes may be appropriate for several different types of scale, no problem list them twice.

ARPEGGIOS - STEPS CAN BE NEGATIVE, ALSO YOU CAN ASCEND AND DESCEND BY DIFFERENT MODES

The fractal tunes use arpeggios, my generalisation of Manuel's modes. They introduce two innovations which I needed for the fractal tunes, first that the steps can be negative (as in the patterns of notes musicians use for practising arpeggios) as well as positive, and secondly, that the modes can ascend one way and descend another way as in the melodic minor of Western music - I have an option to provide a second mode to be used only for descending passages of notes in the fractal tunes.

ANOTHER LIMITATION OF THE MODE FORMAT, MODES THAT ASCEND AND DESCEND IN DIFFERENT WAYS

That then leads to another limitation of the format. It can't handle the likes of the melodic minor where a different selection of notes from the scale is used for ascending and for descending.

HOW YOU COULD DEAL WITH THIS LIMITATION - MULTIPLE MODES

You can do music where a different mode is used for different sections of the piece just by having a list of the modes to use for each section. But you can't do music where you change from one mode to another just depending on the context of the note to be played as in the melodic minor in Western music.

Just adding a second descending mode to the format as I do in FTS isn't enough though as I understand the rules can be more complex than just whether it is in an ascending or descending passage. 

But you could have an option to add a list of several different modes all to be used in the same passage of music, i.e. generalise the idea from two to many modes. Then either you have rules about how they are used, and specify those two, or just need to say it is up to the performer, or composer, informed by tradition to choose which to use for each passage of the music (maybe even several modes simultaneously in different instruments or parts in the same passage?).

THE INFORMATION I'D LOOK FOR IN A TONEXML FILE IS THE SCALE, MODE, AND KEYBOARD MAP

So also if I want to read a tonexml file into FTS for use with the fractal tunes in their current form, the main information I'll look for in it is the scale, and the mode, to be extracted somehow. Also the keyboard map for a performer who wants to play along with a fractal tune from a midi keyboard (or use the midi relaying facilities of FTS)..

LISTS OF CHORDS AND CHORD PROGRESSIONS

Also there's another thing you are going to encounter eventually, depending on how versatile you make the format. 

That's for music that uses chords, a list of chords suitable for those modes or scales

Again Manual has made a start on a comprehensive list, see  Scala | View | List of Chords or look at the chordnam.par file in the SCALA directory after install.

Here is Manuel's post about it to the tuning list:

http://launch.groups.yahoo.com/group/tuning/message/24377

The way he does it as you see is that the chord has to be defined as a particular list of pitches. You leave it to the composer or performer to find approximations to those pitches for their tuning system, and to decide whether it is appropriate to use a particular approximation to those pitches in a tempering or scale.

Another way to do it is to go to another layer of subsets, chords as subsets of the mode which is a subset of a scale, where you reduce the huge range of possible chords to the ones you decide to accept for a particular scale and mode in the context of a particular composition or style of music etc. E.g. (using Western  music examples again because it's what I know most about) you would use different chords for Pythagorean tunings of Early music where the major third is treated as a dissonance. 

Then on top of that you have of course chord progressions as well.

LOOKING TOWARDS THE FUTURE

Clearly if you have a tonexml format, and it ever gets developed and used widely, you will encounter all this and much more eventually and expect to end up with something much more complicated than e.g. musicxml.

So anyway it makes sense to start with a format suitable for maqam music since that's where it is going to be used originally.

But - with my programs before I program something major (rather than a minor easy to program feature) I often spend a long time looking ahead, may think for months about the possible ways it might need to be developed later on, as that helps you to get started with a good format right away early on.

So that's my reason for suggesting you think about these things, not that they need to be put into the format right away, but that it might help to inform how the format develops.

META INFORMATION, AN ADVANTAGE OF XML

On other things in Tonexml, it's particularly useful to be able to add information about the author, and context, for the scale - how it is used, what music culture it is for, links to web pages or papers you can read to find out more about it, and the like. I see the possibility of including that meta information as one of the big advantages of xml over other formats.

COMMENTS ABOUT INTERVALS

I can't think of any situation where I'd want to add a comment to a single note in a scale, and wonder if perhaps like the chords list, that might be best done as a separate thing where you add the comment to an interval instead. 

Certainly in Aaron's example, then all those comments would be more appropriately attached to intervals, which occur between pairs of notes in the tuning.

E.g. you could add a comment to a 5/4, and the 5/4 then may occur in several different locations in a particular tuning (e.g. 8 locations in mean-tone, and 4 approximate locations in pythagorean) (see http://www.hpschd.nu/index.html?nav/nav-4.html&t/welcome.html&http://www.hpschd.nu/tech/tmp/pythagorean.html)

There as for chords again, then that suggests the idea of categorising the intervals by the exact pitch, and leave it to software to search and locate those intervals within the tuning - though you could also have a section of the tonexml file that optionally lists the most important intervals and the chords of interest in the tuning.

IDEA OF A COMMAND LINE TOOL AND LIBRARY - FOR CONVERTING TONEXML TO SCL, TUN AND KBM FORMATS AND BACK AGAIN

Also another thought, if there is an extensive database of tonexml files developed, then you need a simple way to extract a scale, and keyboard mapping and the original .tun format file from it for use with programs that understand those formats and don't yet read tonexml, maybe some tool can be developed for doing that.

If you make that a command line tool and write it in a platform independent way so it can be used in any OS, then that might deal with the problem of authors of different software all needing to write their own importer to interface with the tonexml file. 

The thing is, to read it then at the minimum you need some kind of xml parser - I had a look to see what is available and did find a free source C++ xml parser - but is it a good one, or is it buggy? Or is there some routine in the Windows API to load and parse xml files? As I've never had to do much extensive work with them before, I don't know the answer. A few hours of searching might well turn up the answer for C++ but what about other languages?

Especially if you work at a low level, but also if inexperienced hobbyist programmer, you might not know how to read a xml file, or the best ways to do it. 

But if you have a command line tool you can just spawn it and run it invisibly, and so extract a .scl, .kbm and .tun file.

I suggest that the command line tool defaults to extracting them as files with the same name as the original, same location, and differing just in the file extension (with option to override those if user wants to extract to a different location).

The other way around also you could provide a command line tool to take a .scl, a .kbm and a .tun file (or optionally any one or two of those) plus any other relevant files, and convert them into a tonexml file.

It could be provided as a library too (dll in Windows) to call to do the same thing.

Someone could also do the same with a gui, just add a user interface to the command line tool, and that would provide a way for a non programmer to easily extract e.g. .tun files from the tonexml files in order to use them with VSTi that only understand the .tun file format.

That would make it much easier for me to adopt the format in Tune Smithy. so by extension, I imagine there might well be other programmers who would feel the same way, and it might help with early adoption of the format more widely.

It's better than providing code to link to to read the xml directly into your program, since most microtonal programmers will already have code to read some of those file formats, while code you link to to read the data requires you to interface it more directly to internal data - you also worry about the possibility that the code might be buggy and have bugs that would crash your program (never a problem with command line tools) or that the interface might be deprecated so you have to re-write your code to call a new version of the code.

You can address all those concerns, and code to link to the program is obviously useful for users who want to write programs that are more intimately connected to the xml - if you have a whole lot of programmers all using the xml format then there is a lot to be said for an open source or free source code base for reading the xml as well. Possibly same code could be used for writing the command line tool and for parsing the xml - just link the code for reading the xml to a small main program that uses it to extract the necessary information and writes out a .scl, .kbm and .tun file.

Anyway those are the main thoughts I had.

Robert

[Ozan Yarman]

In response to Robert (accepting "ToneXML" from now):

Yes, Manuel's SCALA Modes library is a gem that has been available for years. But here too is a  glaring problem: The same scale can correspond to several maqams without even the mention of intonational inflexions. 3 3 4 4 2 4 4 steps (ordinarily in 24-tET no doubt) can correspond to Ushshaq, Isfahan, Huseyni, Beyati, Tahir, etc...

There is good sense to handle the diversities under "maqam families". There have been attempts before to categorize them under such denomination as "Huseyni-Ushshaq family", "Hijaz family", etc...

But another problem emerges exemplified in the case of the 24-tone Pythagorean scale adapted by Arel-Ezgi-Uzdilek using data from an earlier proponent of the same tuning, Rauf Yekta. While the two approaches contain different ratios, this is only because Yekta begins the tuning on perde YEGAH, whereas Arel's team begin the tuning on perde KABA CHARGAH. The two perdes are seperated by 8/9. The correct mapping, as shown in my doctoral dissertation (p. 37), proves that the two tunings are in effect one and the same - with the sole difference boiling down to the notation.

Similar caution would be needed again when taking into consideration AHENKS (diapasons) referenced by Ney sizes such as Mansur, Bolahenk, Supurde, etc... Akin to "key transposing instruments", with these AHENKS we see that the perde names RAST, DUGAH, SEGAH, etc.. map altogether to a particular key level (either of C, D, E, etc... for instance). So, in Mansur Ahenk, RAST is always mapped to G while DUGAH to A. In Bolahenk the mapping is RAST to D, DUGAH to E. Maqams which have their tonics defined by these perde names require their scales to conform to the change of Ahenks. Simply defining Ushshaq as 3 3 4 4 2 4 4 is deceptive when mentioning Rast using similar step numbers 4 3 3 4 4 2 1 3 without due reference to a tone of origin.

Surely the same is true for Greek, Byzantine and Romanesque modes involving Hypo modes or octave species; to say nothing of rags/dastgahs, etc...

Furthermore, there is always the danger that step numbers will work in some tunings but not in others designed for the purpose at hand. I suspect there will be serious discrepancies when trying to adapt the step numbers from 24-tET to Yarman-24 - since the two tunings operate rather differently despite the common goal.

I remember back some years ago fondly inputting step numbers into FTS to achieve exactly what Robert has described below in his message. In SCALA, however, I had no way but to merge all possible alterations of a perde in a maqam scale into the same mode data:

!

! 79 tone equal mode:

6 7 7 6 7 6 7 6 7 7 6 7 Meantone Chromatic (3/20-comma)

13 11 1 1 7 13 12 1 7 4 1 1 7  Ozan Yarman's RAST with tonic at 0th step (perde rast)

6 1 5 1 7 1 4 2 4 2 6 1 5 1 6 1 5 1 7 1 4 2 4 2  Arel-Ezgi-Uzdilek approximation

!

! 80 tone MOS from 159-TET for Maqamat:

6 2 4 2 6 1 4 2 6 1 5 2 4 2 6 2 4 2 6 1 4 2 4 2  Arel-Ezgi-Uzdilek approximation

14 12 7 13 1 14 5 7 7 Ozan Yarman's RAST with tonic at 0th step (perde rast)

13 1 12 1 1 5 13 1 13 1 12 1 1 5                 Ozan Yarman's MAHUR with tonic at 0th step (perde rast)

13 1 7 12 1 12 1 6 1 12 1 1 5 7                  Ozan Yarman's NIHAVEND with tonic at 0th step (perde rast)

6 7 1 13 6 13 1 13 1 5 1 1 12                    Ozan Yarman's BUSELIK with tonic at 2nd step (perde dugah)

13 1 5 1 13 1 12 1 6 7 1 5 1 13                  Ozan Yarman's KÜRDI with tonic at 1st step (perde dugah)

13 1 10 1 8 13 1 13 1 10 1 8                     Ozan Yarman's HÜSEYNI with tonic at 1st step (perde dugah)

13 1 9 1 9 13 1 13 1 5 14                        Ozan Yarman's USHSHAQ with tonic at 1st step (perde dugah)

13 1 5 4 1 9 13 1 5 8 1 5 7 7                    Ozan Yarman's BAYATI with tonic at 1st step (perde dugah)

13 1 6 1 1 11 6 7 1 13 1 5 1 1 1 2 1 8           Ozan Yarman's HIJAZ with tonic at 1st step (perde dugah)

6 7 1 6 1 1 17 7 1 13 1 6 1 1 11                 Ozan Yarman's ZIRGULELI HIJAZ with tonic at 2nd step (perde dugah)

7 1 1 4 1 10 1 1 1 6 7 1 1 1 1 1 14 1 1 5 1 13   Ozan Yarman's SABA with tonic at 4th step (perde dugah)

13 1 5 7 7 13 1 12 1 6 7 7                       Ozan Yarman's SEGAH with tonic at 4th step (perde segah)

13 1 4 1 1 4 1 8 13 1 9 1 1 2 1 4 1 1 4 1 8      Ozan Yarman's HÜZZAM with tonic at 5th step (perde segah)

7 6 1 5 2 6 1 5 6 7 1 13 1 5 13 1                Ozan Yarman's NISHABUR with tonic at 7th step (perde nishabur)

6 7 1 12 1 5 1 6 1 6 1 13 13 7                   Ozan Yarman's FERAHNAK with tonic at -5th step (perde arak)

!

Notice the confluence of "1s", expecially in Maqam Saba!

Halil Ibrahim Kirazlı, founder of the now-defunct googlegroup "MusikiXLM", who had been working on the still unfinished? Suzidil Makam Score Editor (and whom we should also invite to this group) engaged members of MELM in discussions also on "MakamXML". The Turkish exchanges are too tedious to repeat here; let it be said simply that I am pleased by Robert's suggestion regarding a preliminary approach to the usage of XML as a universal tuning container initially focusing on Maqam Music.

As someone with an affinity to software interfaces, I would very much like to see an editor that does the job demanded of such a command-line tool for .SCL .TUN .KBD conversion operations. In fact, I had had suggested some years ago that the Turkish score editor programmers join hands to develop a converter between their proprietary notation formats. If ToneXML actually becomes a standard also for notation, then the file formats could all merge, resulting in a considerable score collection with the potential to increase much faster than would the file formats alone by themselves.

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Robert Walker]

Thanks, Ozan, yes, though of course without all the details you give informed by your knowledge of maqams, those are exactly the sorts of issues that I came across with the modes lists.

ONE DETAIL

There is one thing I don't understand in your reply: "The same scale can correspond to several maqams without even the mention of intonational inflexions. 3 3 4 4 2 4 4 steps (ordinarily in 24-tET no doubt) can correspond to Ushshaq, Isfahan, Huseyni, Beyati, Tahir, etc..."

Remember I have no understanding of maqams at all. I tried to read up about it but the amount of detail made it too overwhelming, and it is anyway clearly a matter that needs many years of study to understand at all adequately.

Leaving aside the matter of intonational inflexions and different tunings of the same note depending on context, how can the various maqams for  3 3 4 4 2 4 4 steps differ in tuning? Or do you mean that they differ in some other way, so that the maqam families comprise different maqams that all use the same pitches (essentially apart from inflexions) in differing ways?

MANUELS LISTS OF MODES

BTW, Manuel always titles the list of modes for equal divisions of the octave by e.g. "53 tone equal modes". When he leaves out the word "equal", then the tuning is undefined. You just don't know the tuning, because his format in its current form leaves it optional whether you specify a tuning or not. I think it is reasonable to assume that his maqam modes are intended for some kind of an unequal division of the octave into 24 steps.

STEP NUMBER AMBIGUITY

"Furthermore, there is always the danger that step numbers will work in some tunings but not in others designed for the purpose at hand."

Yes, the modes list needs to be supplied with a suitable scale described sufficiently accurately so the user can avoid these sorts of issues when generating new tunings for the modes.

For the chain of fifths type tunings such as 24 out of 53 then there is only one parameter lacking to make the modes list unambiguous, which is which scale degree the chain of fifths starts on (or ends on). That was the main information I was lacking to put the modes lists into FTS as e.g. modes for 24 out of 53-et or 24 out of 53 Pythagorean. 

Does this answer the issue? 

A MORE COMPLETE MODES LIST FORMAT

This sort of issue can be solved by making it a requirement to add an example scale for every list of modes, in e.g. the SCALA scale type format (or whatever is suitable), together with a description of what sort of tuning the modes list is intended for so the user can generate their own suitable tunings.

So, for a more complete version of the modes list, the basic elements are

* an example tuning

* a list of modes for that tuning with description of each mode

* a description of the tuning sufficiently exact for the user to create or find suitable tunings for the modes list.

The FTS list of modes file format works this way - though it is intended only for exchange of modes lists between instances of Tune Smithy so has other stuff specific to Tune Smithy which you wouldn't include in a general file format:

http://robertinventor.com/software/tunesmithy/help/mode_list_format.htm#List_of_Modes_format_(*.LMD)

IN ONE WAY OR ANOTHER THE TONEXML HAS TO SEPARATE THE TUNING FROM THE MAQAM OR MODE

The  main reason I brought this up is that it gives you a way to separate the tuning from the mode. So for instance you don't need to give separate Scala scale files for all possible tunings of one of the modes. Instead you have one modes list, and then can provide many different tunings for that modes list.

One way or another a format suitable for maqams will need to separate the maqam from the tuning, some way to specify the details of the pitches required for the maqam independent of the actual choice of pitches.

Otherwise you will have lots of files saved using different tunings, just depending on the preference of the user, and there will be no easy way to e.g. read a file saved in 53-et and play it in e.g. Ozan's 24 or 79 tone tunings, or vice versa.

MAQAMS AND ACCIDENTALS

Probably programs that use tonexml will mainly use accidentals for maqam tunings.

However, accidentals can be hard to program for programmers not intimately involved in the tradition, and can get very complex if you extend them to a wide variety of systems as we see with the various Sagital notations, and the wide range of notations in SCALA. Only a few programs will ever incorporate all of those, either specialist ones for particular traditions, or ones that are the result of specialist dedicated programmers such as SCALA.

Possibly rather than require that every file has all those details saved in it you could instead provide a tool to add the missing sections to the file if required.

E.g. you can have a tool to convert a maqam key signature to a mode. The mode would be suitable for any 24 out of 53 type tuning with the chain of fifths starting on a specified particular scale degree.

This idea of tools to convert the files e.g. to scl + kbm + .tun is the main idea that I woke up with yesterday and thought would simplify things enormously. The idea of automatically adding missing sections to the format is a new idea today which would also help.

If you are going to the trouble to make the file format clear and unambiguous, then writing such tools should be easy to do, and also, will be an excellent way to help show up any remaining ambiguities in the format.

ANOTHER POINT IN YOUR POST I DIDN'T QUITE FOLLOW

"Notice the confluence of "1s", expecially in Maqam Saba!"

What is the significance? Sorry I didn't quite follow that bit. Are those 1s possible alternate tunings of a note?

I'm sure there are many other details I don't quite follow but I think hopefully I got the general gist enough for this post to be useful.

Thanks,

Robert

[Aaron Andrew Hunt]

OK, if you'll humor me, I am in fact the author of this thing, which was called TuningXML, now it's being called ToneXML, so let me say something about this suggested change in the name.

I like this suggestion, and here's why:

These 3 words are often used interchangeably in musical discussion:

Note, Tone, Pitch

I have long held that they can and should not be thrown around willy-nilly, but should instead be used for specific meanings:

Note: a marking, a symbolic representation of a Tone
Tone: a mathematical representation of a measurement, quantified in numbers, universally invariant
Pitch: a perceptual experience in a listener, not universally the same and quantifiable only by research query (JND)

By the same token when discussing intervals, these terms can be used for clarity when needed:

Note Interval: as written in a notation
Tone Interval: as expressed with numbers
Pitch Interval: as heard by a listener

You see the usefulness.

These are numbers we are putting in these files.

So, gentlemen, TuningXML is now officially ToneXML.

Thank you.
AAH

[Aaron Andrew Hunt]

Thanks to Robert, and here is a suggested structure based on his message.

<mode>
<name> Maqam Bayati </name>
<ascending> 3, 3, 4, 4, 2, 1, 3, 4 </ascending>
</mode>

Although this practice of requiring comma delimited data is bad form for XML. It should really be like this:

<mode>
<name> Maqam Bayati </name>
<ascending>
<step> 3 </step>
<step> 3 </step>
<step> 4 </step>
<step> 4 </step>
<step> 2 </step>
<step> 1 </step>
<step> 3 </step>
<step> 4 </step>
</ascending>
</mode>

A 12ET Example, using bad form for brevity:

<mode>
<name> Melodic Minor </name>
<ascending> 2, 1, 2, 2, 2, 2, 1 </ascending>
<descending> 2, 1, 2, 2, 1, 2, 2 </descending>
</mode>

You see that descending steps are written in ascending order, and when descending is the same as ascending, there the <descending> tag is simply omitted and the parser makes it equal to ascending.

The problem of linking the mode with the scale is removed when the scale and its modes are in the same file.

True Western modes and others of the world do indeed require steps *below* a tonic to show correct structures, so negative steps should be allowed certainly, but not officially for the sake of arpeggios, which are a different structure and if you want to include them they need their own elements.

Going beyond scales and modes to arpeggios and chords etc. is going beyond tuning into the realm of composition and that doesn't belong in a tuning file format IMHO.

The command line tool is a beautiful idea of course, which can and should be done.

Thanks!
AAH

[Aaron Andrew Hunt]

Actually, the verbose form should probably be:

<modes>

<mode>
<name> Maqam Bayati </name>
<ascending>

<steps>

<step> 3 </step>
<step> 3 </step>
<step> 4 </step>
<step> 4 </step>
<step> 2 </step>
<step> 1 </step>
<step> 3 </step>
<step> 4 </step>

</steps>
</ascending>
</mode>
</modes>

The convention being whenever there will be a list of some element, that list is contained in a plural tag of that element.

Hence, a list of mode elements are in a modes element, and a list of step elements are in a steps element.

[Ozan Yarman]

Dear Aaron, yes, you are the author of TuningXML. You've obviously given a lot of consideration into it. Yet, if an XML standard will arise for the adoption of microtonalist entrepreneurs, then the authorship shall be collaborative in the end, I think.

Glad you like the suggestion "ToneXML" as a shorter name. I too quite agree with the need to concretize concepts of note, tone, and pitch. At first glance, I'm tempted to agree with your definitions, though room for improvement/modification is reserved for the future.

If there are no objections, I shall extend invitations straightforwardly to:

Manuel op de Coul - Author of SCALA
Victor Cerullo - Author of Vogue line of synths and others
Halil İbrahim Kirazlı - conceptualizer of MakamXML
Mark Henning - conceptualizer of AnaMark TUNing format (by suggestion of Robert, e-mail address is required)

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ozan Yarman]

I have also found this related to the topic at hand:

http://msdn.microsoft.com/en-us/library/ms180825.aspx

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Robert Walker]

Hi everyone, here are the high res versions of the photos I've uploaded so far to facebook as public downloadable zips, if anyone wants them. I'll leave them up for at least another week.

http://dl.dropbox.com/u/54333215/Istanbul-and-Ankara.zip

31 MB

(gallery here http://www.dropbox.com/gallery/54333215/1/Istanbul%20and%20Ankara?h=ae196f)

http://dl.dropbox.com/u/54333215/Istanbul-and-Ankara-2.zip

131 MB

(gallery here: http://www.dropbox.com/gallery/54333215/1/Istanbul%20and%20Ankara%202?h=d9caa8 )

Robert

[Ömer Tulgan]

dear aaron,
sorry, uptill now i had not the opprtunity to study the messages in melm.
(i say "study", because with my small english, to read a message is really a "study" of the text!)
i find your idea of tunexml great. but i need a little more time, tio understand everything!

about my makamxml, i have had difficulties to formulate a multy-ligual xsl file, as you know.
but now, i thing i have found a way,
so i hope that i shall be able to send the result soon.

greetings to all,
tulgan


Aaron Andrew Hunt schrieb:

[Robert Walker]

Ozan, that's about tuning databases to improve server load, not tuning musical notes. It's for the dta tuning advisor utility, explained here:

http://msdn.microsoft.com/en-us/library/ms162812.aspx

Robert

[Ozan Yarman]

My point exactly. Tuning could be confused with something else when coupled with the notion of XML, since it is reserved for some other field of programming. So I think we all converged on a more proper term to choose "ToneXML". :)

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Robert Walker]

Aaron, yes that is something my program can deal with easily - if the maqams can be translated into this form at some point. 

I expect that some things in the xml file will only be understood by a dedicated maqam program. Some details of the tuning will surely be lost sometimes when you do the translation.

TWO OCTAVE MODES

Note, a mode like this can also span two or more octaves. That could be useful for maqams with different tunings depending on the octave. There is no need to do anything special to achieve that. If all the steps add up to two octaves in the underlying scale then that makes it a two octave mode.

MORE CATEGORIES NOT JUST ASCENDING AND DESCENDING

With maqams where things are much more complex, I expect you will need many different modes for a single maqam, and not just ascending and descending. 

If there are notes in a maqam with many different possible tunings, depending on context and performer's interpretation, it might be impractical to translate all those possibilities into a list of modes. 

If so could just have one or a few modes in this format. Then add a brief description or just a warning, or other xml element to the mode for the other options.

Robert

[Robert Walker]

Okay I understand now, thanks.

Robert

[Ozan Yarman]

Robert,

When I talk of the same scale steps corresponding to a number of distinct makams, let it be said at this point that - aside from diverse subtleties - the factors for differentiation in between any of them could be the following:

1. The step numbers can only bluntly describe the intonation. Certain of the tones/perdes of, say, Huseyni differ from those of Ushshaq (perde segah/2nd degree is distinctly lower towards the finalis in the latter). Taking 24-tET (or some other 24-tone tuning) as basis will only work as a rough draft, or grid, if you will.

2. The tonic/finalis of one makam could be at a different degree compared to another, though both imperatively use the tones towards the lower end of the scale (compare Chargah with Saba).

3. While the tonic/finalis is the same for both, including the very similitude of intonation, the seyir (melodic procedure) of one makam might differ from the other - in the example of Ushshaq/Bayati.

Indeed, understanding these subtleties requires years of getting into the particulars of what constitutes a makam.

I don't know if your incorporation of the missing degree wherewith the fifth cycle starts answers the issue at hand. I suspect this is not by itself sufficient to codify makams digitally.

If we focus on the first case above, the tuning of a particular step series will definitely require minute changes along the melodic line, no matter what the makam in question may be. Sometimes, the alterations will be just a few cents, sometimes entire quarter-tones, more often than not whole halftone or greater steps - yielding alterated scales altogether. I wholly agree that the tuning information should be seperate from makam step sequence categories, yet, think some loose connection must nevertheless exist in between. The example tuning could be a guide of sorts to this end perhaps.

As for the confluence of steps of 1 in the makam Saba scale I produced from my personal Scala mode file:

7 1 1 4 1 10 1 1 1 6 7 1 1 1 1 1 14 1 1 5 1 13   Ozan Yarman's SABA with tonic at 4th step (perde dugah)

They do indeed signify "commatic" alterations required of the melodic procedure of the Saba makam. But they are not to be executed in succession. This step number sequence does not contain the information necessary to describe the possible melodic avenues of Saba. We need to define acceptable subsets out of it. If this can be automated, all the better.

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Aaron Andrew Hunt]

On Jan 22, 2012, at 6:10 PM, Ozan Yarman wrote:
> As for the confluence of steps of 1 in the makam Saba scale I produced from my personal Scala mode file:
>
> 7 1 1 4 1 10 1 1 1 6 7 1 1 1 1 1 14 1 1 5 1 13 Ozan Yarman's SABA with tonic at 4th step (perde dugah)
>
> They do indeed signify "commatic" alterations required of the melodic procedure of the Saba makam. But they are not to be executed in succession.

This suggests that a different form is needed, where you first specify zones, and allow for zone specification in terms of steps, and then instead of specifying a mode using numbers of steps, you specify it using zone names. You want to show a scale using steps with multiple possible tones used for that step, so define the step with the multiple tones, then define the mode as a series of those zones. Here is what I mean.

<zones>
<units> 53 </units> // this states 53 equal is used as the unit for all zones, whatever you want can be used here
<zone>
<name> Mode Step Name 1 </name>
<bounds>
<bound> 7 </bound> // 8th step of 53edo
<bound> 9 </bound>
</bounds>
</zone>
<zone>
<name> Mode Step Name 2 </name>
<bounds>
<bound> 13 </bound>
<bound> 14 </bound>
</bounds>
</zone>
// ... etc. for all mode step names
</zones>

<modes>
<mode>
<name> Maqam Name </name>
<format> zones </format>
<ascending>
<steps>
<step> Mode Step Name 1 </step>
<step> Mode Step Name 2 </step>
<step> Mode Step Name 3 </step>
<step> Mode Step Name 4 </step>
<step> Mode Step Name 5 </step>
<step> Mode Step Name 6 </step>
<step> Mode Step Name 7 </step>
</steps>
</ascending>
</mode>
</modes>

Make sense?

[Robert Walker]

Ozan,

Great, that answers all my questions, with a clear exposition, I understand much better now.

I came up with an idea for a way to extend the sagittal approach so it specifies where the fifth cycle starts in a 24 out of 53 type tuning so will post that separately. Perhaps that may help clarify whether that type of approach is sufficient or more is needed for maqam tunings.

Thanks,

Robert

[Aaron Andrew Hunt]

Thanks, and it's great to hear from you Omer; looking forward to more. Sorry I can't speak / type in Turkish. Google translate hopefully can help. <http://translate.google.com/>
Cheers,
Aaron

[Robert Walker]

Omer, I wonder, might it help to auto translate into German instead of Turkish?

Just an idea. Maybe that's what you do already.

I find German auto translated into English easier to read than Turkish auto translated.

Also hope you don't feel you have to read all my long posts.

I normally break up my longer posts using headers in capitals. They may help you see which sections you can safely skip or just skim over.

Thanks,

Robert

[Ozan Yarman]

I strongly urge the usage of Google Translate to convert our dialogue to the language of your choice given that Turkish or English is difficult to follow by everyone. Also, perhaps Robert or Aaron or someone else can suggest a simple HTML or XML code to attach each message so that Google Servers can duplicate a translated portion of the message at the button of each mail or in a web browser upon clicking a link. I also think one can make it mandatory for the MELM Googlegroup to include the code along with the message that accompanies our messages.

--------

İngilizce yazışmaları tam takip edemeyenlerimiz lütfen http://translate.google.com.tr

adresinden istifade etmekten çekinmesinler. Google bu işlerde oldukça ilerledi.

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Ozan Yarman]

Can you explain to me in a little more detail how the zones work Aaron Andrew?

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Robert Walker]

Hi Ozan,

Seems, the simplest way is to go to the google translate page and enter the url of the MELM group into the text to translate field.

This should show all the messages auto translated to turkish:

http://translate.google.com/translate?sl=en&tl=tr&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fgroups.google.com%2Fgroup%2Fmtonalist&act=url

And this should show them in german:

http://translate.google.com/translate?sl=en&tl=de&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fgroups.google.com%2Fgroup%2Fmtonalist&act=url

To do that I just went to http://translate.google.com/

and in the left hand box where it says to enter the text or a website address, entered the group address:

http://groups.google.com/group/mtonalist

Then you select the languages and use the link in the right hand box.

OTHER OPTIONS (NOT SO GOOD)

If you visit the group in the browser

http://groups.google.com/group/mtonalist

you might see a link above the message to translate it into another language

It doesn't always work though. There are no MELM messages in Turkish for me to try it on, so tried other groups.

Sometimes I get "translate to English" when it is already in English and sometimes I get no link at all when it is in another language.

This is the google help post about it:

http://support.google.com/groups/bin/answer.py?hl=en&answer=144332

Another thing you can do is to get the Google translate tool bar here:

http://www.google.com/toolbar/ff/index.html

but it doesn't support the latest browsers, I just tried it in IE, Firefox and chrome, and it wouldn't install in any of them.

You can add the code to your own website easily - but that won't work with a plain text message.

http://translate.google.com/translate_tools

That just leaves visiting the google translate site and enter the url of the MELM group, which works fine.

Robert

[Ömer Tulgan]

thanks!
Omer

Robert Walker schrieb:

[Ömer Tulgan]

now a first approximation of Makam.xml can be downloaded from
http://www.tulgan.com/MakamXml/MakamXml.rar

to read it in english, copy all 6 files into the same directory
and just double-click Makam.xml.

to read it in turkish, the lines about contacting dtd-files must be changed:
-open Makam.xml with the editor
- change the lines 3-4 from
    <!--DOCTYPE makam SYSTEM "Turkce.dtd"-->
    <!DOCTYPE makam SYSTEM "English.dtd">
into:
    <!DOCTYPE makam SYSTEM "Turkce.dtd">
    <!--DOCTYPE makam SYSTEM "English.dtd"-->
- double-click then Makam.xml.
greetings,
omer

[Aaron Andrew Hunt]

On Jan 24, 2012, at 4:45 PM, Ozan Yarman wrote:
> Can you explain to me in a little more detail how the zones work Aaron Andrew?
>
> Oz.

Well, I'm just trying to translate what you're talking about, so actually it's up to you how such zones would work.

I have my own system of interval zones which can be applied to any music, as outlined in my theory and implemented in all my software:
<http://www.h-pi.com/theory/huntsystem4.html>

[Aaron Andrew Hunt]

Omer!
I see you have been very busy, and figured out how to use DTD and XSL. It will take me some time to study this, so I can't reply with anything substantial now besides the observation that the information in your XML can be made use of through XSL for any purpose. Thank you very much for sharing the work here!
Cheers,
Aaron
=====

[Robert Walker]

Just to say I can read it fine using XML notepad (XSL output tab shows it in English).

What is a diapason in this context (anyone)? 

When it comes to techy details about maqams in xml, I don't expect to be able to contribute anything, just read what everyone else says. 

I look forward to seeing how it develops.

Thanks,

Robert

[Ömer Tulgan]

I used it translating the word "Ahenk". ( I am not sure, if it is correct :) ...)
Ahenk means, that in maqam music you can perform the same note in several tone-levels.
so the tone "Rast" sounds in Bolaheng-Ahenk (nearly) like piano's D,
in Davud-Ahenk like E, in Shah-Ahenk like F,  a.s.o.
(and all the other tones are defined relative to Rast)

To have a small example, please download and open
http://www.tulgtan.com/MakamXml/Diapason.rar
There you find in Hicaz.pdf the notes of a small melody
and in the mid-files the soud of the prformence in diffrent ahenks.

greetings!
omer

Robert Walker schrieb:

[Ozan Yarman]

http://www.tulgan.com/MakamXml/Diapason.rar

is the correct address.

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ömer Tulgan]

thanks

Ozan Yarman schrieb:

[Robert Walker]

Omer, thanks for the examples and explanation and that's clear now. 

When you say all the other tones are defined relative to Rast, that sounds like it's the "tonic"

http://en.wikipedia.org/wiki/Tonic_(music)

Not just a concept of diatonic music as that article might suggest. It's used e.g. to describe Indian music and in microtonal music when you need to talk about this kind of a thing.

If you replace "Diapasons" by "Tonics" in the xml file, it reads okay to me. Does everyone else agree?

------------------------------------------------------------------------------

Diapasons is a rare word, I had to look it up, and I think most musicians won't know what it means.

In the xenharmonic wiki and in wikipedia, it is shown as the interval of an octave:

http://xenharmonic.wikispaces.com/Gallery+of+Just+Intervals

http://en.wikipedia.org/wiki/Diapason_(interval)

However it's also listed as a name for the default sound of an organ - the "principal stop" - when it doesn't imitate any other instrument.

http://en.wikipedia.org/wiki/Organ_stop#Classifications_of_stops

greetings! good to hear from you.

Robert

thanks

Ozan Yarman schrieb:

To unsubscribe from this group, send email to mtonalist+unsubscribe@googlegroups.com

GOOGLE TRANSLATE IT: http://translate.google.com.tr

--
MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com

To unsubscribe from this group, send email to mtonalist+unsubscribe@googlegroups.com

GOOGLE TRANSLATE IT: http://translate.google.com.tr

--
MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com

To unsubscribe from this group, send email to mtonalist+unsubscribe@googlegroups.com

GOOGLE TRANSLATE IT: http://translate.google.com.tr

--
MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com

To unsubscribe from this group, send email to mtonalist+unsubscribe@googlegroups.com

[Aaron Andrew Hunt]

Hi Robert. I understand your confusion, but the thing that's changing isn't the tonic, but rather the "register". Omer's use of "diapason" is perfectly fine for that, although register might be less academic sounding. He's using the term "diapason" technically the same way it is used in music theory, and also in organ building. Changing it to "tonic" would not be correct.

Cheers,
Aaron
=====

> To unsubscribe from this group, send email to mtonalist+...@googlegroups.com

>
> GOOGLE TRANSLATE IT: http://translate.google.com.tr
>
> --
> MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com

> To unsubscribe from this group, send email to mtonalist+...@googlegroups.com

>
> GOOGLE TRANSLATE IT: http://translate.google.com.tr
>
> --
> MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com

> To unsubscribe from this group, send email to mtonalist+...@googlegroups.com

>
> GOOGLE TRANSLATE IT: http://translate.google.com.tr
>
> --
> MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com

> To unsubscribe from this group, send email to mtonalist+...@googlegroups.com

>
> GOOGLE TRANSLATE IT: http://translate.google.com.tr
>
>
> --
> MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com

> To unsubscribe from this group, send email to mtonalist+...@googlegroups.com

[Robert Walker]

Hi Aaron, thanks for the correction. Can you explain a bit more? The word "diapason" is new to me and can't find a good online definition of it.

How does all this relate to principal organ stops and the interval of an octave, or is that another use of the word diapason?

Register doesn't sound right to me as it suggests different octaves of the same instrument, for wind instruments anyway:

http://en.wikipedia.org/wiki/Register_(music)

though again may be just another meaning of the word.

Also not sure what is wrong with the word "tonic". Is it because it suggests a system with changes of tonic?

That's how it seems to be used in Western music, but in Indian music, it's used pretty much in the way Omer uses it (I think) - with no context of changes of tonic during a piece, it is just the note that relates to the drone:

http://chandrakantha.com/articles/indian_music/drone.html

So if you can use it like that for Indian music I'd have thought you could use it for the principal tone of a maqam in Turkish music. What do you think, can you elaborate a bit more.

Thanks,

Robert

[Aaron Andrew Hunt]

My answer was based on conversations I had with Omer about this. As I understood it, "ahenk" means "level". The word "diapason" is used to mean "octave", and it can mean "in this octave" which is the same as "register". Everybody knows what "tonic" means; I'm not contesting that. But I don't think it's what Omer intends here. I may have misunderstood Omer. How about let's just let Omer answer the question.

[Robert Walker]

Aaron, oh right, if you look at his example xml file

Diapasons :

Bolahenk :

Rast = D4 - 0.083 HK

Davud :

Rast = E4 + 0.083 HK

Şah :

Rast = F4 - 0.333 HK

Mansur :

Rast = G4 - 0.167 HK

Kız :

Rast = A4 + 0.000 HK (= 440 Hz)

Müstear :

Rast = B4 + 0.167 HK

Sipürde :

Rast = C5 - 0.250 HK 

where Rast is the name of one of the notes in the maqam I believe, in this context,

then I think it's pretty clear he is using it in the same way as our "tonic".

Omer, what do you think?

Thanks for the explanation of Diapason, makes sense.

Thanks,

Robert

[Aaron Andrew Hunt]

Sorry, I hadn't looked at those latest xml files yet; have been very busy. Anyway, as I said, diapason is used to mean "octave" but I should clarify that it really means "through all the tones in this 1:2 span", the same as "diatonic" means literally, but you can see how that translates into "register". From Euclid forward the word "diapason" had the implication 1:2 and you can see that this meaning is not really the same as the notion of "tonic". When the scale is changing with different registers (as modes can, and as I think I understood from Omer the maqam is doing?) the word tonic isn't really the best one, and diapason could be the better word. So it's my understanding that Omer chose diapason for good reason, but let's please just let him answer ; )

[Ozan Yarman]

"Ahenk" has a distinctive meaning in Turkish Maqam music. It signifies exactly the task accomplished by "Key Transposing" in Western music.

The term comes from different sizes of Ney. Each Ney Ahenk (harmony, intoning), though may be different in dimensions, possesses the same key hole proportions as all others, which corresponds to an intelligible array of perdes (tones) for all, characteristically named as rast, zengule, dugah, kurdi, segah, etc...

So, you can map the perde series above (take whichever of them as your tone of origin) to any note, any frequency.

Thusly, perde rast corresponds to the Western G in Mansur Ahenk (Mansur Ney);
rast also corresponds to the Western F is Shah Ahenk (Shah Ney);

and so forth.

the mapping of rast to a particular Western note immediately maps the rest to their respective places in the pitch continuum (with much room for inflexion, of course).

Please refer to page 97, and pages 176-186 in my Doctorate Dissertation at:

http://www.ozanyarman.com/files/doctorate_thesis.pdf

for a Synopsis of this phenomenon.

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ozan Yarman]

Aaron Andrew,

In Turkish, diapason has become synonymous with "international standart pitch" or "concert pitch", which was also referred to as "diapason normal". I specifically use the term "standard diapason" in my writings to denote "concert pitch".

It is accepted almost across all music institutions in Turkey to say La (A) = 440 Hz, the diapason of...

Please refer to my previous message on this correlation of diapason with Ney Ahenks.

Cordially,
Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ömer Tulgan]

Reading your messages now it seems to me,
the word "diapason" is not the best solution.
what about just "level" or "tone level"?

omer

Robert Walker schrieb:

[Robert Walker]

Okay well if I understand it rightly I'd still call it tonic - I'd call Rast the tonic and the pitch you give is the pitch of the tonic.

Tonic and not tone because tone just means any musical note.

Also can call it the ";pitch of the 1/1" if you use the idea of the tuning based on 1/1 with all other tunings measured relative to the 1/1. 

From Ozan's emails then it seems the word diapason has taken a meaning similar to tonic in Turkish musicological circles. 

But perhaps this use of the word hasn't spread much outside Turkey, or at least is still rare elsewhere. Would e.g. typical members of the tuning list understand it in this way? I did a search of the xenharmonic wiki and didn't find it used in this way, and only a couple of mentions.

So perhaps it partly depends if it is to be read by Turkish or Western musicians.

I speak as a mathematician who never formally trained in music theory and just picked it up, can just present how I see things, look forward to hear what others think.

Thanks,

Robert

[Aaron Andrew Hunt]

Hi Robert.

Well, it's not register as I was saying -- I had it wrong based on a misunderstanding of what Omer was explaining to me in our conversations. But, I think it's not really tonic either.

Ozan has said it is something like the concept of the "reference tone" as in A 400 Hz. I think if it were just tonic, Ozan would have said that already.

it seems closer to what we call the "tuning pitch" or "reference tone" or "fundamental tone".

I suppose "tonic" would work, but it doesn't seem quite right.

Thoughts, Ozan?

Aaron
=====

[Robert Walker]

Hi Aaron,

Okay, reference tone works for me. Depending what Ozan says of course.

I wonder if it is to do with whether the music modulates. If the tonic changes in the course of the piece of music and you want to talk about that it's confusing to also use the word tonic for reference tone.

So an interesting question is, is the word "tonic" used with maqams with some other meaning, do you use it to talk about modulation for instance? 

With Indian music there's no modulation, just the steady drone throughout, so identifying the tonic with the reference tone makes sense.

With Western music you have only the one reference tone A = 440 Hz and it's not attached to a piece of music. All the music is played using the same pitch reference. 

Only need to mention it for early music which is generally pitched flatter than concert pitch.

Also if you talk about the upward creep of concert pitch so that now A = 442 Hz and A = 443 Hz is used by many orchestras

http://en.wikipedia.org/wiki/Concert_pitch#19th_and_20th_century_standards

So you have the distinction of tonic and reference tone but rarely need to talk about the reference tone and it's not associated with an particular piece of music.

Robert

[Ozan Yarman]

"Key Transposing degree" or "Pitch level" could perhaps suit the purposes better?

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Ozan Yarman]

Yes, "tuning pitch", "reference tone/perde" come very close to explaining the phenomenon. But it's not just a single pitch but all the series of perdes and their myriad intonational inflexions that are actually affected by a change of Ahenk. So it's more precise to say that "key transposing level" has shifted.

It could be viable to just say: "Ney Ahenk" or something akin to "Ney in C". Please refer to pages 176-186 in my Doctorate Dissertation at:

http://www.ozanyarman.com/files/doctorate_thesis.pdf

A change of Ahenk is synonymous with Key Transposing.

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ozan Yarman]

Robert, in between the lines:

✩ ✩ ✩

www.ozanyarman.com

On Feb 2, 2012, at 2:26 PM, Robert Walker wrote:

Hi Aaron,

Okay, reference tone works for me. Depending what Ozan says of course.

I had suggested that any of the following is good for the purpose:

"Key Transposing degree" (e.g. -9 steps of 53-EDO from C to c at concert pitch)

"Pitch level" (e.g. perde rast = 260 Hz yields Supurde)

"Tuning pitch" (e.g. ditto or perde neva = 440 Hz yields Bolahenk.)

"reference tone/perde" (any of the above)

I wonder if it is to do with whether the music modulates.

Modulation is a seperate phenomenon. Ahenk is the direct transpostion of the playing pitch level.

If the tonic changes in the course of the piece of music and you want to talk about that it's confusing to also use the word tonic for reference tone.

I agree. Tonic has a distinct translation as "Karar Perdesi" or "Durak" in Turkish. This is a step number independent of tuning. E.g. one can have perde rast as the tonic of maqam Rast, and this perde rast can correspond to any frequency despite remaining as the reference pitch 1/1.

So an interesting question is, is the word "tonic" used with maqams with some other meaning, do you use it to talk about modulation for instance? 

Explained above. Tonic is in the domain of modulation while reference tone is in the domain of direct transposition (mapping of notes to their respective niches at any level in the frequency continuum).

With Indian music there's no modulation, just the steady drone throughout, so identifying the tonic with the reference tone makes sense.

Exactly.

With Western music you have only the one reference tone A = 440 Hz and it's not attached to a piece of music. All the music is played using the same pitch reference. 

Only need to mention it for early music which is generally pitched flatter than concert pitch.

Also if you talk about the upward creep of concert pitch so that now A = 442 Hz and A = 443 Hz is used by many orchestras

http://en.wikipedia.org/wiki/Concert_pitch#19th_and_20th_century_standards

For all intents and purposes, yes; as you say furthermore, historical performences veered to the adoption of A=415 Hz for Baroque music and such. But this is a side issue. Modern execution of Western music generally follows the same or similar pitch for A everywhere. In Maqam music, there are quite a number of diapasons that players can choose from to suit their needs.

So you have the distinction of tonic and reference tone but rarely need to talk about the reference tone and it's not associated with an particular piece of music.

For Western music, apparently so.

Robert

Oz.

[Robert Walker]

Ozan, okay most of those work for me and not sure which is the best. When making up a new phrase or word for something I think it pays to take time and do it carefully and ask around for suggestions.

"reference tone" sounded good to me when Aaron suggested it. I thought of it as a tone you use as the reference when you pitch all the other notes in the maqam. But doesn't work so well if you think of it as the reference tone for pitching just one of the notes.

Yes I wonder if we have the concept at all in Western music. Of course, do have the idea of a home key e.g. a  movement in C major or whatever. But that's not really quite the same because you can handle it easily with the twelve keys and just choose which key you use as your home key.

Different sizes of instrument just handled by specifying the instrument in the score e.g. descant, treble etc. for recorder.

If you start with the western 12 note system and try to generate to more  notes per octave a natural idea is to just have more keys so e.g. 17 key system or 19 key system etc. But to do it the same way in a 53 tone system would get very complex with most of the keys never used and they all have to be named, though your  idea of using degrees of a 53 tone system  might help by using numbers instead of names.

In my programs I call a similar concept the "pitch of the 1/1", it's the nearest I can think but not quite the same perhaps.

Anyway those are just a few thoughts. I understand the issue anyway I think. But don't know what's the best answer.

Thanks,

Robert

[Ozan Yarman]

Robert,

Well, "reference tone" can work as I said.

Whereas, to elaborate further, if you say perde rast is 262 Hz, this is obviously middle C in pianos; but you can definitely notate it as G on the staff - according to Turkish custom - and treat it as key transposing. So, the habit is to read rast at G using a G clef all the time, while moving its frequency liberally as the occasion demands.

(Helpful to distinguish "tone" from "note" here, as Aaron would concur no doubt.)

Exactly what key transposing instruments accomplish. These instruments read the same notation, but transpose the entire music by a designated interval (e.g. all Bb Clarinets sound Bb when reading C).

Yet in fact, a second hidden transposition takes place in Turkish Maqam music, which is IMO a horrible deterrant to practicality: People read and recite rast as G using a G Clef, calibrate the standard pitch as 293.333333333333333 Hz sounding D at Bolahenk (in reference to perde neva at 440 Hz A), and moreover transpose the whole thing yet another perfect fourth down to A (Kiz Neyi Ahengi). That's a whole minor seventh down.

So, Ahenk is key transposing effect alright, but also, the ability change of concert pitch in addition to that.

Still bit complicated though, yes? :)

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Ozan Yarman]

Sorry to reply late to this one. I still have to experience the code in the form of some interface or tool in order to say for sure if the design promises to work for me. I'm just glad to help along you folk get your mind occupied with the implementation of ToneXML. :)

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Robert Walker]

Oz,

Thanks that explains something that was a bit of a puzzle. Before the MELM trip I tried to play the scores for some of the turkish videos on recorder - approximating the notes as best I could. (you can play microtonal pitches well on a recorder if you work on it, using alternate fingerings etc but this was just an experiment).

Anyway for some of them I could play the score on my voice flute (recorder in D) using the fingering for a descant (in C) to get it at the right pitch for the music. 

So that's transposing down a minor seventh as you say, the C on the score (as we would normally read it) was played as a D.

Robert

[Ömer Tulgan]

To see the relation between the term "reference tone" (or "level") and the term "tonic" as used in maqam music,
maybe it will be helpfull to have some examples:
(Here are ignored small differences between pitch vords of maqam perdes and western (12 equal tempered) tones)


Robert Walker schrieb:

[Ozan Yarman]

Buselik in Shah could be better expressed with Bb instead of A# and Eb instead of D#.

Ditto for Nihavend in Mansur.

Nihavend in Bolahenk better notated using Bb instead of A#.

Nihavend in Shah must altogether be corrected to:

F, G, Ab, Bb, C, Db, Eb, F.

Also, instead of 1 tone and 0.5 tone, the proper English naming conventions are rather "W", "S" - signifying wholetone and semitone respectively. This works better with perde rast designated as the 0th step (which is not an interval).

Notice, that it was possible I who first suggested the distinction of perde names from maqam names by writing the former without a capital initial.

Also, I suggest "reference tone" be skipped a row down to rast=D, rast=E, etc... The proper translation of the concept for "Ahenks" should be "Key Transposition".

Oz.

✩ ✩ ✩

www.ozanyarman.com

On Feb 4, 2012, at 3:40 AM, Ömer Tulgan wrote:

To see the relation between the term "reference tone" (or "level") and the term "tonic" as used in maqam music,
maybe it will be helpfull to have some examples:
(Here are ignored small differences between pitch vords of maqam perdes and western (12 equal tempered) tones)

<igjjaadg.png>

[Ömer Tulgan]

these are all true...
i wanted to use as less symbols as possibble,
to concentrate the attention to the relation of ahenk and tonic
(without making mstakes of course). therefore only using # and no b.

"key transposition" seems to me being a good translation:
knowing now, what is ment by "ahenk":
do you also agree???
omer

Ozan Yarman schrieb:

[Ömer Tulgan]

<Notice, that it was possible I who first suggested the distinction of
perde names from maqam names by writing the former without a capital
initial.>

in the maqam music tradition "perdes" are not only some lelative
positions of frequences, but each of them has its own character and
somehowe a "personality".
therefore they should also have (personal) "names", beginning with
capital letters!
considering the unequal distances and therefore more complex
relationships between them, resulting into diferent psychical efects, i
agree with this position...
omer

Ozan Yarman schrieb:

> Buselik in Shah could be better expressed with Bb instead of A# and Eb
> instead of D#.
>
> Ditto for Nihavend in Mansur.
>
> Nihavend in Bolahenk better notated using Bb instead of A#.
>
> Nihavend in Shah must altogether be corrected to:
>
> F, G, Ab, Bb, C, Db, Eb, F.
>
> Also, instead of 1 tone and 0.5 tone, the proper English naming
> conventions are rather "W", "S" - signifying wholetone and semitone
> respectively. This works better with perde rast designated as the 0th
> step (which is not an interval).
>
> Notice, that it was possible I who first suggested the distinction of
> perde names from maqam names by writing the former without a capital
> initial.
>
> Also, I suggest "reference tone" be skipped a row down to rast=D,
> rast=E, etc... The proper translation of the concept for "Ahenks"
> should be "Key Transposition".
>
> Oz.
>
>
> ✩ ✩ ✩

> www.ozanyarman.com <http://www.ozanyarman.com>

>>> www.ozanyarman.com <http://www.ozanyarman.com/>

>>>> <ozany...@ozanyarman.com <mailto:ozany...@ozanyarman.com>>

>>>> wrote:
>>>>
>>>> Robert, in between the lines:
>>>>
>>>> ✩ ✩ ✩

>>>> www.ozanyarman.com <http://www.ozanyarman.com/>

>>>>> <http://en.wikipedia.org/wiki/Register_%28music%29>

>>>>> >> though again may be just another meaning of the word.
>>>>> >>
>>>>> >> Also not sure what is wrong with the word "tonic".
>>>>> Is it because it suggests a system with changes of tonic?
>>>>> >>
>>>>> >> That's how it seems to be used in Western music,
>>>>> but in Indian music, it's used pretty much in the way
>>>>> Omer uses it (I think) - with no context of changes of
>>>>> tonic during a piece, it is just the note that relates
>>>>> to the drone:
>>>>> >>
>>>>> http://chandrakantha.com/articles/indian_music/drone.html
>>>>> >> So if you can use it like that for Indian music I'd
>>>>> have thought you could use it for the principal tone
>>>>> of a maqam in Turkish music. What do you think, can
>>>>> you elaborate a bit more.
>>>>> >>
>>>>> >> Thanks,
>>>>> >>
>>>>> >> Robert
>>>>> >>
>>>>> >> On Tue, Jan 31, 2012 at 3:12 PM, Aaron Andrew Hunt
>>>>> <aaronan...@gmail.com

>>>>> <mailto:aaronan...@gmail.com>> wrote:
>>>>> >> Hi Robert. I understand your confusion, but the
>>>>> thing that's changing isn't the tonic, but rather the
>>>>> "register". Omer's use of "diapason" is perfectly fine
>>>>> for that, although register might be less academic
>>>>> sounding. He's using the term "diapason" technically
>>>>> the same way it is used in music theory, and also in
>>>>> organ building. Changing it to "tonic" would not be
>>>>> correct.
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Aaron
>>>>> >> =====
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Jan 31, 2012, at 6:16 AM, Robert Walker wrote:
>>>>> >> > Omer, thanks for the examples and explanation and
>>>>> that's clear now.
>>>>> >> >
>>>>> >> > When you say all the other tones are defined
>>>>> relative to Rast, that sounds like it's the "tonic"
>>>>> >> > http://en.wikipedia.org/wiki/Tonic_(music)

>>>>> <http://en.wikipedia.org/wiki/Tonic_%28music%29>

>>>>> >> >
>>>>> >> > Not just a concept of diatonic music as that
>>>>> article might suggest. It's used e.g. to describe
>>>>> Indian music and in microtonal music when you need to
>>>>> talk about this kind of a thing.
>>>>> >> >
>>>>> >> > If you replace "Diapasons" by "Tonics" in the xml
>>>>> file, it reads okay to me. Does everyone else agree?
>>>>> >> >
>>>>> >> >
>>>>> ------------------------------------------------------------------------------
>>>>> >> >
>>>>> >> > Diapasons is a rare word, I had to look it up,
>>>>> and I think most musicians won't know what it means.
>>>>> >> >
>>>>> >> > In the xenharmonic wiki and in wikipedia, it is
>>>>> shown as the interval of an octave:
>>>>> >> >
>>>>> http://xenharmonic.wikispaces.com/Gallery+of+Just+Intervals
>>>>> >> > http://en.wikipedia.org/wiki/Diapason_(interval)

>>>>> <http://en.wikipedia.org/wiki/Diapason_%28interval%29>

>>>>> >> >
>>>>> >> > However it's also listed as a name for the
>>>>> default sound of an organ - the "principal stop" -
>>>>> when it doesn't imitate any other instrument.
>>>>> >> >
>>>>> http://en.wikipedia.org/wiki/Organ_stop#Classifications_of_stops
>>>>> >> >
>>>>> >> > greetings! good to hear from you.
>>>>> >> >
>>>>> >> > Robert
>>>>> >> >
>>>>> >> > On Mon, Jan 30, 2012 at 9:11 PM, Ömer Tulgan
>>>>> <oe...@tulgan.com <mailto:oe...@tulgan.com>> wrote:
>>>>> >> > thanks
>>>>> >> >
>>>>> >> > Ozan Yarman schrieb:
>>>>> >> > http://www.tulgan.com/MakamXml/Diapason.rar
>>>>> >> >
>>>>> >> > is the correct address.
>>>>> >> >
>>>>> >> > Oz.
>>>>> >> >
>>>>> >> > ✩ ✩ ✩

>>>>> >> > www.ozanyarman.com <http://www.ozanyarman.com/>

>>>>> <mailto:mton...@googlegroups.com>

>>>>> >> > To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >> >
>>>>> >> > GOOGLE TRANSLATE IT:
>>>>> http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >> >
>>>>> >> > --
>>>>> >> > MANAGERS ONLY: To post to MELM" group, send email
>>>>> to mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> >> > To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >> >
>>>>> >> > GOOGLE TRANSLATE IT:
>>>>> http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >> >
>>>>> >> > --
>>>>> >> > MANAGERS ONLY: To post to MELM" group, send email
>>>>> to mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> >> > To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >> >
>>>>> >> > GOOGLE TRANSLATE IT:
>>>>> http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >> >
>>>>> >> > --
>>>>> >> > MANAGERS ONLY: To post to MELM" group, send email
>>>>> to mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> >> > To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >> >
>>>>> >> > GOOGLE TRANSLATE IT:
>>>>> http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > MANAGERS ONLY: To post to MELM" group, send email
>>>>> to mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> >> > To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >> >
>>>>> >> > GOOGLE TRANSLATE IT:
>>>>> http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >>
>>>>> >> --
>>>>> >> MANAGERS ONLY: To post to MELM" group, send email
>>>>> to mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> >> To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >>
>>>>> >> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >>
>>>>> >> --
>>>>> >> MANAGERS ONLY: To post to MELM" group, send email
>>>>> to mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> >> To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >>
>>>>> >> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >
>>>>> >
>>>>> > --
>>>>> > MANAGERS ONLY: To post to MELM" group, send email to
>>>>> mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> > To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >
>>>>> > GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>> >
>>>>> >
>>>>> > --
>>>>> > MANAGERS ONLY: To post to MELM" group, send email to
>>>>> mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> > To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>> >
>>>>> > GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>>
>>>>> --
>>>>> MANAGERS ONLY: To post to MELM" group, send email to
>>>>> mton...@googlegroups.com

>>>>> <mailto:mton...@googlegroups.com>

>>>>> To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>>
>>>>> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> MANAGERS ONLY: To post to MELM" group, send email to

>>>>> mton...@googlegroups.com <mailto:mton...@googlegroups.com>

>>>>> To unsubscribe from this group, send email to
>>>>> mtonalist+...@googlegroups.com

>>>>> <mailto:mtonalist+...@googlegroups.com>

>>>>>
>>>>> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>>> <http://translate.google.com.tr/>

>>>>
>>>>
>>>> --
>>>> MANAGERS ONLY: To post to MELM" group, send email to

>>>> mton...@googlegroups.com <mailto:mton...@googlegroups.com>

>>>> To unsubscribe from this group, send email to
>>>> mtonalist+...@googlegroups.com

>>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>>
>>>> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>> <http://translate.google.com.tr/>

>>>>
>>>>
>>>>
>>>> --
>>>> MANAGERS ONLY: To post to MELM" group, send email to

>>>> mton...@googlegroups.com <mailto:mton...@googlegroups.com>

>>>> To unsubscribe from this group, send email to
>>>> mtonalist+...@googlegroups.com

>>>> <mailto:mtonalist+...@googlegroups.com>

>>>>
>>>> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>>> <http://translate.google.com.tr/>

>>>
>>> --
>>> MANAGERS ONLY: To post to MELM" group, send email to

>>> mton...@googlegroups.com <mailto:mton...@googlegroups.com>

>>> To unsubscribe from this group, send email to
>>> mtonalist+...@googlegroups.com

>>> <mailto:mtonalist%2Bunsu...@googlegroups.com>

>>>
>>> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>> <http://translate.google.com.tr/>

>>>
>>>
>>> --
>>> MANAGERS ONLY: To post to MELM" group, send email to
>>> mton...@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> mtonalist+...@googlegroups.com
>>>
>>> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>>> <http://translate.google.com.tr/>

>>
>>
>> --
>> MANAGERS ONLY: To post to MELM" group, send email to

>> mton...@googlegroups.com <mailto:mton...@googlegroups.com>

>> To unsubscribe from this group, send email to
>> mtonalist+...@googlegroups.com

>> <mailto:mtonalist+...@googlegroups.com>

>>
>> GOOGLE TRANSLATE IT: http://translate.google.com.tr

>> <http://translate.google.com.tr/>

[Ozan Yarman]

Omer, you are missing the point. It is necessary to distinguish the perde names from the same maqam names to clear confusion when new people are introduced with the maqam terminology. What better way than to decapitalize the first letter of perde names? This does in no respect diminish their "personality". On the contrary, it reinforces just that.

And besides, there was no way to write capital letters in Arabic, Persian, Ottoman alphabets, derivative of Arabic in the first place back in the centuries perde names had "their personality".

Oz.

✩ ✩ ✩
www.ozanyarman.com

[Ozan Yarman]

If only using # signs, the Rast in Shah requires as D#, not E.

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Robert Walker]

Okay, if I look in an xml editor I see it like this:

<ahenkler>

<ahenk>

<ismi>Bolahenk</ismi>

<rast_referansı>

<ton>D4</ton>

<fark> - 0.083 </fark>

</rast_referansı>

</ahenk>

...

<ahenkler>

and if I look at the formatted output, in XML notepad it shows it like this.

Diapasons :

Bolahenk :

Rast = D4 - 0.083 HK

So - I think probably it ignores the tags that don't have translations in the dtd yet.

Old version of Internet Explorer here shows it similarly, more recent version shows it garbled, and chrome shows it blank. Perhaps just because not all the tags are translated ??

So anyway, - assume your suggestion is:

<ahenkler>

<key_transposition>

<ismi>Bolahenk</ismi>

<reference_tone>

<ton>D4</ton>

<fark> - 0.083 </fark>

</reference_tone>

</key_transposition>

...

<ahenkler>

I'd be inclined to just say "transposition"  instead of "key transposition" not sure the word key helps here. You would need to think about what key you are transposing from and to, so imagine perhaps the Western idea of transposition is rather more linked to ideas of modulation than maqam transposition I would guess. (You can also talk about transposing the same chord or phrase from  one key to another within a single piece of music).

Apart from that minor niggle, and Aaron etc do step in and correct if needed, seems ffine to me.

E.g you might talk about transposing a particular phrase or chord from one key to another within a piece of music so key transposition to me doesn't necessarily suggest transposing the entire piece. 

BTW  Omer, a few corrections to the English.dtd - attached. Only one that makes a difference to the xml example is that in English Rhythms is spelt with hy instead of i (goodness knows why!).

There are some other phrases where I'm not sure what they say, marked them as  <!-- ?? -->, which would need to be corrected at some point as it gets more developed - just left them for now as I can't read the turkish and auto translation often gives curious results from Turkish to English.

Thanks,

Robert

------------------------------

<!-- İlerde çeviri amacıyla entiteler-->

<!--Sabit metinler-->

<!ENTITY ent_dili "English">

<!ENTITY ent_titel "Maqam Music">

<!ENTITY ent_sistem "System">

<!ENTITY ent_değer_birimi "Unit">

<!ENTITY ent_ahenkler "Diapasons">

<!ENTITY ent_arızalar "Accidentals">

<!ENTITY ent_grafik "Graphics">

<!ENTITY ent_perdeler "Tones">

<!ENTITY ent_notalama "Written as">

<!ENTITY ent_çeşniler "Modules">

<!ENTITY ent_kararı "Tonic">

<!ENTITY ent_yedeni "Leading tone">

<!ENTITY ent_perde "Tone ">

<!ENTITY ent_makamlar "Maqams">

<!ENTITY ent_durağı "Tonic">

<!ENTITY ent_güçlüsü "Dominant">

<!ENTITY ent_seyri "Beginning orientation">

<!ENTITY ent_anadizisi "Mean scale"> <!-- ?? -->

<!ENTITY ent_donanımı "Keys">

<!ENTITY ent_makamın_çeşnileri "Maqam's modules">

<!ENTITY ent_yeri "Position">

<!ENTITY ent_karar_türü "Sort of ending">

<!ENTITY ent_değişiklikler "Alterations">

<!ENTITY ent_değişken_perde "Variable tone ">

<!ENTITY ent_ne_kadar "The more"> <!-- ?? -->

<!ENTITY ent_veya "or  ">

<!ENTITY ent_ve "  and  ">

<!ENTITY ent_o_kadar_farklı "the more altered"> <!-- ?? -->

<!ENTITY ent_asgarî "Minimum">

<!ENTITY ent_âzamî "Maximum">

<!ENTITY ent_usûller "Rhythms"> <!-- spelling -->

<!--Almaşıklı metinler-->

<!ENTITY ent_çıkıcı "Rising"> <!-- Uprising isn't a word in English- -->

<!ENTITY ent_inici "Falling">

<!ENTITY ent_çıkıcı_inici "Rising-falling">

<!ENTITY ent_inici_çıkıcı "Falling-rising">

<!ENTITY ent_tam_karar "Full-Stop">

<!ENTITY ent_yarım_karar "Semi-Stop">

<!ENTITY ent_asma_karar "Temporarily stop">  <!-- spelling of temporarily -->

<!ENTITY ent_çıkıcı_ise "rising">

<!ENTITY ent_inici_ise "falling">

<!ENTITY ent_karara_gidiyor_ise "going to the end">

<!ENTITY ent_karardan_uzak_ise "far of the end"> <!-- ?? -->

<!ENTITY ent_buruk_tercih_ise "a herb performance advanced"> <!-- ?? -->

<!ENTITY ent_parlak_tercih_ise "a brilliant performance advanced">

<!ENTITY ent_yerinde "Own position"> <!-- ?? -->

<!ENTITY ent_yok "None">

<!ENTITY % elementler SYSTEM "Makam.dtd" >

%elementler;

[Ozan Yarman]

How about:

<transpositions>

<key>

<name>Bolahenk</name>

<reference_tone>

     <rast>

<tone>D4</tone>

<offset> - 0.083 </offset>

</reference_tone>

</key>

...

<transpositions>

Of course, the relation of other tones to our reference of rast here should otherwise be stated in some fashion in the ToneXML.

As for confusing translations, here are the correct ones:

Anadizi = main/principal scale (like the Major scale).

Donanımı = Key Signature (of)

Notalama = engraving (for the score)

Çeşniler = Flavours // Makamın Çeşnileri = Flavours of the Maqam

Seyri = melodic progression (of)

Karar cinsi/takısı = Finalis genus ("türü" bad Turkish!)

ne kadar = offset amount

o kadar farklı = offset as much as...

çıkıcı = ascending

inici = descending

Tam karar = full cadence

yarım karar = incomplete cadence

asma karar = temporary/sustaining cadence

karara gidiyor ise = if proceeding unto cadence

karardan uzak ise = if distant from cadence

buruk tercih ise = if preference leans to minor (in intonation character)

parlak tercih ise = if preference leans to major (in intonation character)

yerinde = regular/normal/preferred key

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Robert Walker]

Looks okay except, why call it a key? 

In western music, a key is associated with a tonic, so the tonic for C major is C. 

But you say the reference tone here isn't a tonic, and if the reference tone isn't a tonic, ahenk can't be exactly a direct translation of key, seems to me. 

I may well be missing something.

Also don't want the discussion to get too bogged down with translation issues. Must be other things to discuss.

Thanks,

Robert

[Aaron Andrew Hunt]

Well, in Western music, modes and keys are pretty much separate entities until we get to the 20th century when people start mixing them up because of a misunderstanding of what modes were in the first place. Then we can have something like "the third mode of melodic minor in (the key of) Bb". Jazz musicians talk that way. Technically speaking it's just a modern invention.

I think since we are just inventing a modern translation here, and the point is for musicians to understand the structure of a maqam, it seems these words can be used with their modern meanings, since that what Western musicians mostly expect -- tonic, mode, key, transposition.

but this structure Ozan suggested isn't correct XML structure:

<transpositions>
<key>
</key>
<transpositions>

If you look at Omer's original and recall my remarks some messages ago, the structure of a plural tag should be a singular element inside the plural tag of the same name.

<transpositions>
<transposition>
</transposition>
<transpositions>

or

<keys>
<key>
</key>
</keys>

[Robert Walker]

Thanks Aaron, it's beginning to make sense to  me now :) Like changing from one mode to another within the same key then of course the tonic changes but the key remains the same.

Robert

[Ozan Yarman]

The reference tone is indeed the tonic for Rast as well as other maqams, but it certainly is not the tonic of Bolahenk. Bolahenk or any other Ahenk does not imply a tonic.

The reference tone here as a tag was intended for the whole set of perdes. You need to anchor a perde to a certain tone/frequency in order to have the rest follow suit in accordance with whatever temperament/tuning you may like to install (their relations pending to be specified in the XML code).

"Key" - at least to me - signifies the degree of a scale. Perde rast is a degree of the whole set of traditional perdes. You can take it as 4/3 if yegah is your tone of origin, or as 1/1 if you deem it the tone of origin. Whatever the case may be, taking an Ahenk as a key means that you transpose the whole set of perdes in relation to each other to a different pitch level.

Actually, I am stretching the term here too much, since I would have better associated "key" (given its tonality/modality zeitgeist) directly with "maqam". I did this years ago in the tuning list.

In light of this, and in consideration of Aaron's tags warning, let me try once more:

<key transpositions>

<degree>

<name>Bolahenk</name>

<tuning pitch>

     <rast>

<tone>D4</tone>

<offset> - 0.083 </offset>

</tuning pitch>

</degree>

...

<key transpositions>

You can have key transposition in the singular instead of degree, but saying the latter saves space and avoids confusion when editing the code.

Cordially,

Oz.

✩ ✩ ✩

www.ozanyarman.com

[Ömer Tulgan]

thanks

Ozan Yarman schrieb:

[Ömer Tulgan]

Makam.Xml now a little bit more developed:

http://www.tulgan.com/MakamXml/MakamXml.rar

tetracords and pentacords are now complete
and 4 maqams are completely defined.

Besides of the main scale, key signature, tonic and dominante,
a maqam is (here) mostly determined by a bundle of flavours (moduls),
most of them tetracords and pentacords, some times at the original place
but in general transposed to an other modul's tonic.

about each flavour some alterations or additional informations can (must not) exist.
for example,
 - the frequency of use of this flavour (often / sometimes / seldom / very seldom...)
   which can be connected with some conditions (when ascending / when descending...)

 - sometimes an axis of the melodies -  for example in maqam Isfahan / flavour Ussak tetrachord at original position: Segâh

 - sometimes even some melody-patterns - also there, 3 patterns:

Nevâ , Çargâh (long) , Segâh /
Çargâh (long) , Segâh , Dügâh , Segâh (long) /
Çargâh , Segâh (long) , Dügâh , Dügâh (long)

...

please have a look and let me know your opinion - greetings,
omer

[Aaron Andrew Hunt]

Omer, it has taken me too long to look at this as I am swamped with building keyboards, but it looks like good work!

I don't quite understand about the (often / sometimes / seldom / very seldom) etc. contingencies, and I unless I missed something, I would suggest giving a numerical value to those kinds of things, as constants ...

For example, is it a 4 point scale where (often / sometimes / seldom / very seldom) are each of equal weight? So each is 25%? Or is it a weighted scale, where there are different percentages? Is "often" twice "sometimes"? Obviously there are not strict empirical data for this, but it would be good to come up with something close to what is generally true, so some program using the data doesn't have to make that decision, but rather has a number already.

Cheers,
Aaron
=====

[Ömer Tulgan]

I want to use terms in the manner of fuzzy logic.
These are the terms, used by the performers of maqam music.
The exact definition would be leaved up to the software developers that
make use of this database...
..and maybe also up to some intelligent-learning programms.

Aaron Andrew Hunt schrieb:

> Omer, it has taken me too long to look at this as I am swamped with building keyboards, but it looks like good work!
>
> I don't quite understand about the (often / sometimes / seldom / very seldom) etc. contingencies, and I unless I missed something, I would suggest giving a numerical value to those kinds of things, as constants ...
>
> For example, is it a 4 point scale where (often / sometimes / seldom / very seldom) are each of equal weight? So each is 25%? Or is it a weighted scale, where there are different percentages? Is "often" twice "sometimes"? Obviously there are not strict empirical data for this, but it would be good to come up with something close to what is generally true, so some program using the data doesn't have to make that decision, but rather has a number already.
>
> Cheers,
> Aaron
> =====
>
>

> On Feb 8, 2012, at 2:09 PM, �mer Tulgan wrote:
>> Makam.Xml now a little bit more developed:
>>
>> http://www.tulgan.com/MakamXml/MakamXml.rar
>>
>> tetracords and pentacords are now complete
>> and 4 maqams are completely defined.
>>
>> Besides of the main scale, key signature, tonic and dominante,
>> a maqam is (here) mostly determined by a bundle of flavours (moduls),
>> most of them tetracords and pentacords, some times at the original place
>> but in general transposed to an other modul's tonic.
>>
>> about each flavour some alterations or additional informations can (must not) exist.
>> for example,
>> - the frequency of use of this flavour (often / sometimes / seldom / very seldom...)
>> which can be connected with some conditions (when ascending / when descending...)
>>

>> - sometimes an axis of the melodies - for example in maqam Isfahan / flavour Ussak tetrachord at original position: Seg�h

>>
>> - sometimes even some melody-patterns - also there, 3 patterns:

>> Nev� , �arg�h (long) , Seg�h /
>> �arg�h (long) , Seg�h , D�g�h , Seg�h (long) /
>> �arg�h , Seg�h (long) , D�g�h , D�g�h (long)