[TUN] TUN Information content

[AnaMark]

Although the .TUN format facilitates side informations using comments, these cannot be analyzed automatically. This is a problem for databases and makes the user looking into the source to get additional informations. Search functionality is very limited.

We can add new sections and new parameters without losing downwards compatibility because according to the current .TUN specification unknown sections/parameters have to be ignored and thus don't bother existing software.

My proposal:

0) New value types
Although the value type "string" was already mentioned in the current specification, it is not used. Therefore, modifying its definition does not break downward compatibility:

String: A string is enclosed in "". Special characters are encoded using a C-like syntax (Means e.g. tabulatur = \t). A string value is concatenated to the current parameter value. An empty string ("") resets the parameter value. This means:
Param1 = "123"
Param1 = ""
Param1 = "ABC\r\n"
Param1 = "DEF"

results in "ABC\r\nDEF". It is recommended to use multiple entries at line breaks ("\n") or to avoid entries exceeding the max line length.

LString: Certain parameters are not Strings but LStrings: Each parameter entry in the .TUN file adds an entry to a string list (string array). An empty string ("") clears the list. E.g.:

Keyword = "Ambient"
Keyword = "Techno"

results in a string list containing the two entries "Ambient" and "Techno".

1) New section [Info]
Usage: Contains "hard facts" about the scale
Keys:
- Format = [String] File format. Will be a constant value which declares the file compatible with .TUN specifications.
- FormatVersion = [Int] Version of the file format.
- Name = [String] Name of the scale. If not given: use file name instead (without extension).
- File = [String] Filename suggested for the scale. If not given: use value for Name instead.
- Editor = [String] Software used to create/edit the file/scale
- Author = [String] Who created the scale
- Contact = [String] Contact information of the author
- Date = [string, date format YYYY-MM-DD according to DIN specifications ] Creation date of the scale. If not given: use file date instead.
- Keyword = [LString] Keywords which may help categorizing the scale
- Comment = [String] Free comment value for informations not covered by the other keys.

I'm not sure whether adding the keys "Format" and "FormatVersion" is a good idea. If this encourages developers to create their own derivative format leading to format confusions, we should forget them. On the other side it could be important for future use.

2) New section [Usage]
Usage: What's the context of the scale? Notes about the usage.
Keys:
- History = [String] Description of the "historical context"
- Geography = [String] Description of the "geographical context"
- Ethnics = [String] Description of the "ethnical context"
- Style = [String] Description of the musical style the scale is typical for
- Instrument = [String] Description of the instrument the scale is typical for
- Song = [LString] Song in which the scale was used. Format: "Musician or Band | Album | Title | Year | Misc"
- Usage = [String] Free comment value for additional usage informations not covered by the other keys.

3) Enhancing [Exact Tuning] section or new section [Absolute Tuning]
In [Absolute Tuning] section: Keys note 0 to note 127 as in [Exact Tuning], but tunings are given in Hz instead of Cents.
As an alternative: Would you prefer including this into the [Exact Tuning] section? Let's say: "note #" for cent values and "noteHz #" for Hz values?

4) New section [Mapping]
Usage: Keyboard mapping of the tuning.
- MiddleKey = [Int] Middle key of the scale. If not given, take the note number with the lowest absolute Cent value. Note: BaseFreq may but must not specify the base tuning of the middle key. In fact, the current specification does not require positive Cent values. Without losing downwards compatibility we can give the BaseFreq parameter the tuning of *any* note by specifying negative Cent values for the notes tuned below.
- key # = [Int] corresponding note number. For keys not specified here, key #i will result in note #i.

5) New section [Editor Specifics]
This section contains keys which are specific to the software used to create the file (See section [Info], key "Editor"). The software developer can freely add keys here.

[H-Pi Instruments]

0) New value types
Although the value type "string" was already mentioned in the current specification, it is not used. Therefore, modifying its definition does not break downward compatibility:

String: A string is enclosed in "". Special characters are encoded using a C-like syntax (Means e.g. tabulatur = \t). A string value is concatenated to the current parameter value. An empty string ("") resets the parameter value. This means:
Param1 = "123"
Param1 = ""
Param1 = "ABC\r\n"
Param1 = "DEF"

results in "ABC\r\nDEF". It is recommended to use multiple entries at line breaks ("\n") or to avoid entries exceeding the max line length.

LString: Certain parameters are not Strings but LStrings: Each parameter entry in the .TUN file adds an entry to a string list (string array). An empty string ("") clears the list. E.g.:

Keyword = "Ambient"
Keyword = "Techno"

results in a string list containing the two entries "Ambient" and "Techno".

OK, I see this sets up the ability to include parameters or attributes as strings.

1) New section [Info]
Usage: Contains "hard facts" about the scale
Keys:
- Format = [String] File format. Will be a constant value which declares the file compatible with .TUN specifications.
- FormatVersion = [Int] Version of the file format.
- Name = [String] Name of the scale. If not given: use file name instead (without extension).
- File = [String] Filename suggested for the scale. If not given: use value for Name instead.
- Editor = [String] Software used to create/edit the file/scale
- Author = [String] Who created the scale
- Contact = [String] Contact information of the author
- Date = [string, date format YYYY-MM-DD according to DIN specifications ] Creation date of the scale. If not given: use file date instead.
- Keyword = [LString] Keywords which may help categorizing the scale
- Comment = [String] Free comment value for informations not covered by the other keys.

I'm not sure whether adding the keys "Format" and "FormatVersion" is a good idea. If this encourages developers to create their own derivative format leading to format confusions, we should forget them. On the other side it could be important for future use.

2) New section [Usage]
Usage: What's the context of the scale? Notes about the usage.
Keys:
- History = [String] Description of the "historical context"
- Geography = [String] Description of the "geographical context"
- Ethnics = [String] Description of the "ethnical context"
- Style = [String] Description of the musical style the scale is typical for
- Instrument = [String] Description of the instrument the scale is typical for
- Song = [LString] Song in which the scale was used. Format: "Musician or Band | Album | Title | Year | Misc"
- Usage = [String] Free comment value for additional usage informations not covered by the other keys.

These sections ( [Info] and [Usage] ) look almost identical to my proposals for TuningXML: http://www.h-pi.com/phpBB2/viewtopic.php?t=87 so please let's work together to keep these in sync, as doing so will ensure that the formats can easily transport one to the other. I have changed the Geography attribute to Location, for example. I had gotten rid of Ethnics, thinking maybe this was too racist sounding but I could put it back in. I like the additions of Style, Instrument, Song, Usage.

3) Enhancing [Exact Tuning] section or new section [Absolute Tuning]
In [Absolute Tuning] section: Keys note 0 to note 127 as in [Exact Tuning], but tunings are given in Hz instead of Cents.
As an alternative: Would you prefer including this into the [Exact Tuning] section? Let's say: "note #" for cent values and "noteHz #" for Hz values?

In terms of backward compatibility, I think keeping the [Exact Tuning] as it is and adding a new section for Hz would be better.

4) New section [Mapping]
Usage: Keyboard mapping of the tuning.
- MiddleKey = [Int] Middle key of the scale. If not given, take the note number with the lowest absolute Cent value. Note: BaseFreq may but must not specify the base tuning of the middle key. In fact, the current specification does not require positive Cent values. Without losing downwards compatibility we can give the BaseFreq parameter the tuning of *any* note by specifying negative Cent values for the notes tuned below.
- key # = [Int] corresponding note number. For keys not specified here, key #i will result in note #i.

So this looks more like the scala .kbm ( http://www.xs4all.nl/~huygensf/scala/help.htm#mappings ) approach to mapping a scale to MIDI notes. Here I think things might get confusing, because already in the .tun AnaMark [Exact Tuning] there is a method for mapping different from the scala approach but which has its own logic. But I wonder how many people even use the AnaMark mapping capability in their files? The only files I have seen always have 128 values in them, but I have not seen that many .tun files.

5) New section [Editor Specifics]
This section contains keys which are specific to the software used to create the file (See section [Info], key "Editor"). The software developer can freely add keys here.

To me this sounds dangerous. It would require some strict rules about what can be placed there, or if multiple developers decide to use similar keys (tags) - which can happen with programmers since data are often similar in different applications -then some big problems could result.

[AnaMark]

0) New value types
[...]

OK, I see this sets up the ability to include parameters or attributes as strings.

Strings where already mentioned in the current specification as parameter type due to "future" (from the past point of view ) requirements, but they're not used.

1) New section [Info]
[...]
2) New section [Usage]
[...]

These sections ( [Info] and [Usage] ) look almost identical to my proposals for TuningXML: http://www.h-pi.com/phpBB2/viewtopic.php?t=87 so please let's work together to keep these in sync, as doing so will ensure that the formats can easily transport one to the other.

Two people same thoughts - who wonders, the keys are rather obvious.

To the other point: Yes we should try to correlate the keys and parameters. Nowadays, for xml I see the problem of the missing downwards compatibility which might prevent the format from common use. In 5 years, e.g., the "new" TUN specification might be spread widely and as it can be embedded into e.g. xml (if it's still up-to-date in 5 years...), we can then easily make a shift to xml without bothering people. And the last step might be pure xml. It takes a little bit longer, but people can stay concentrated on their music instead of dealing with file formats.

I have changed the Geography attribute to Location, for example. I had gotten rid of Ethnics, thinking maybe this was too racist sounding but I could put it back in. I like the additions of Style, Instrument, Song, Usage.

I'm not a native english speaker (I don't know if you are.). But in one hour I will meet one from Australia. I'll ask him what's the best english translation for it.

3) Enhancing [Exact Tuning] section or new section [Absolute Tuning]
[...]

In terms of backward compatibility, I think keeping the [Exact Tuning] as it is and adding a new section for Hz would be better.

Adding noteHz # keys to the Exact Tuning section does not break downwards compatibility as long as for each noteHz # entry there is a note # entry. The noteHz # keys will be ignored by the old software. But putting both into the same section gives the possibility to easily mix them in the future.

4) New section [Mapping]
[...]

So this looks more like the scala .kbm ( http://www.xs4all.nl/~huygensf/scala/help.htm#mappings ) approach to mapping a scale to MIDI notes. Here I think things might get confusing, because already in the .tun AnaMark [Exact Tuning] there is a method for mapping different from the scala approach but which has its own logic. But I wonder how many people even use the AnaMark mapping capability in their files? The only files I have seen always have 128 values in them, but I have not seen that many .tun files.

That's right; it's similar to Scala. I don't think this will mix up with the auto completion capability, as it requires periodicity. The keyboard mapping is free from any periodicity needs. It is applied after the auto completion is applied. The auto completion fills the table "note # => frequency", the mapping fills the table "key # => note #", so it works independently.

5) New section [Editor Specifics]
[...]

To me this sounds dangerous. It would require some strict rules about what can be placed there, or if multiple developers decide to use similar keys (tags) - which can happen with programmers since data are often similar in different applications -then some big problems could result.

The rules are: It must be according to the common file syntax, this means:

key = value

whereas value might me "anything" which fits into a single line and is plain 8-Bit ASCII.

It won't lead to confusion. Before reading the [Editor Specifics] section, the software must compare the value of the key "Editor" in the [Info] section. If it fits, the editor specific keys fit as well. If it does not fit, the software should keep the hands away from the editor specifics.

But this section is a chance to give people the freedom to add what they need. In some years, we will see what they added and can think about adding it to the next specifications.

[H-Pi Instruments]

These sections ( [Info] and [Usage] ) look almost identical to my proposals for TuningXML: http://www.h-pi.com/phpBB2/viewtopic.php?t=87 so please let's work together to keep these in sync, as doing so will ensure that the formats can easily transport one to the other.

Two people same thoughts - who wonders, the keys are rather obvious.

... hey, I emailed you my draft of TuningXML on Dec 22, you posted your proposals on Dec 26, and major parts of your proposals are obviously based exactly on my proposals for TuningXML (link above). In my proposals, I cite your previous work, and the work of Manuel Op de Coul (who I CCd on emails, BTW).

Yes we should try to correlate the keys and parameters. Nowadays, for xml I see the problem of the missing downwards compatibility which might prevent the format from common use. In 5 years, e.g., the "new" TUN specification might be spread widely and as it can be embedded into e.g. xml (if it's still up-to-date in 5 years...), we can then easily make a shift to xml without bothering people. And the last step might be pure xml. It takes a little bit longer, but people can stay concentrated on their music instead of dealing with file formats.

The point is to make a better standard... I say it should be TuningXML, and you say it should be updated .tun. I don't want to be combative about this; I want to collaborate. Since .tun is already in use, what you say makes good sense and it's fine with me, and as I am developing TuningXML anyway, and I am involved here, I feel whatever improvements and enhancements may happen to .tun should also be implemented in TuningXML, which means it will become a co-authored format (which was my desire from the outset).

But from developers I would like to know - if a developer is going to put any time at all into making parser changes to support a file format alteration, wouldn't that developer rather go for the step which gains huge advantages rather than a stepping stone gaining small ones, even if it may mean a little more work? I don't know what others would say, but for myself I go for the quantum leap, which IMO would be TuningXML.

I'm not a native english speaker (I don't know if you are.).

I am ... (sometimes not obviously).

Adding noteHz # keys to the Exact Tuning section does not break downwards compatibility as long as for each noteHz # entry there is a note # entry. The noteHz # keys will be ignored by the old software. But putting both into the same section gives the possibility to easily mix them in the future.

OK, but mixing formats or units then begs the question: why not allow decimals (float values like 1.5), slash ratios (like scala does, 3/2) and colon ratios (interval ratios like 2:3). TuningXML allows for all of these.

4) New section [Mapping]
...
I don't think this will mix up with the auto completion capability, as it requires periodicity. The keyboard mapping is free from any periodicity needs. It is applied after the auto completion is applied. The auto completion fills the table "note # => frequency", the mapping fills the table "key # => note #", so it works independently.

OK. I get it.

5) New section [Editor Specifics]

The rules are: It must be according to the common file syntax, this means:

key = value

whereas value might me "anything" which fits into a single line and is plain 8-Bit ASCII.

It won't lead to confusion. Before reading the [Editor Specifics] section, the software must compare the value of the key "Editor" in the [Info] section. If it fits, the editor specific keys fit as well. If it does not fit, the software should keep the hands away from the editor specifics.

But this section is a chance to give people the freedom to add what they need. In some years, we will see what they added and can think about adding it to the next specifications.

OK. But why the limitation to single line? Is this an 80 character limit?

[AnaMark]

These sections ( [Info] and [Usage] ) look almost identical to my proposals for TuningXML: http://www.h-pi.com/phpBB2/viewtopic.php?t=87

Two people same thoughts - who wonders, the keys are rather obvious.

... hey, I emailed you my draft of TuningXML on Dec 22, you posted your proposals on Dec 26, and major parts of your proposals are obviously based exactly on my proposals for TuningXML (link above). In my proposals, I cite your previous work, and the work of Manuel Op de Coul (who I CCd on emails, BTW).

Calm down. Do you believe I started thinking about a new specification set after getting your email? O.K., I cannot prove the contrary. I didn't read your proposals in detail yet, had just the time flying over it. You can get the "copyright" for those keys. That's fine with me.

The point is to make a better standard... I say it should be TuningXML, and you say it should be updated .tun.

That's not the point. I don't say, xml is worse. I just think it won't be successful today due to the compatibility reasons. Tomorrow, the world may look different. I agree with you: Let's make things together; I'm willing to support it. And let the people decide which next step to take. BTW: That's why I noted the ability to embed .TUN data into xml without loss of downwards compatibility right with the current specs. So you just have to add something like <TUNData> ... </TUNData> and to care for some things, and your file will be readable by both: The existing TUN algorithms as well as xml-based.

Mmh. This could make stepping to xml easier because downwards compatibility can be ensured right at this stage.

I don't want to be combative about this; I want to collaborate. Since .tun is already in use, what you say makes good sense and it's fine with me, and as I am developing TuningXML anyway, and I am involved here, I feel whatever improvements and enhancements may happen to .tun should also be implemented in TuningXML, which means it will become a co-authored format (which was my desire from the outset).

Same with me.

But from developers I would like to know - if a developer is going to put any time at all into making parser changes to support a file format alteration, wouldn't that developer rather go for the step which gains huge advantages rather than a stepping stone gaining small ones, even if it may mean a little more work? I don't know what others would say, but for myself I go for the quantum leap, which IMO would be TuningXML.

ACK. That's the question.

I'm not a native english speaker (I don't know if you are.).

I am ... (sometimes not obviously).

O.K., then there's no further guessing. Let's take "Location" for it.

Adding noteHz # keys to the Exact Tuning section does not break downwards compatibility as long as for each noteHz # entry there is a note # entry. The noteHz # keys will be ignored by the old software. But putting both into the same section gives the possibility to easily mix them in the future.

OK, but mixing formats or units then begs the question: why not allow decimals (float values like 1.5), slash ratios (like scala does, 3/2) and colon ratios (interval ratios like 2:3). TuningXML allows for all of these.

ACK. Float values are already there, even in scientific notation. But in fact, adding something like 3/2 or 2:3 to the existing note # keys will break downwards compatibility.

In the origin, .TUN was not designed as a format for editing scales but as a simple base to share them with others and amongst ones VSTis. It should never superseed .scl & Co..

By the way: What about "relative" or functional tunings with cross-references between notes, I mean something like that (I don't know whether this is already included):

note 2 = freq_of_note_1 + 5 Cents
note 3 = freq_of_note_1 + 10 Hz
note 4 = freq_of_note_1 * 1.2
note 5 = freq_of_note_1 / 1.4
note 6 = freq_of_note_1 * 1.2 / 1.4

In XML you could represent it like this:
<NOTE ID="1" HZ="123" />
<NOTE ID="2" REL="1" CENTS="5" />
<NOTE ID="3" REL="1" HZ="5" />
<NOTE ID="4" REL="1" MUL="1.2" />
<NOTE ID="5" REL="1" DIV="1.4" />
<NOTE ID="6" REL="1" MUL="1.2" DIV="1.4" />

And: Using MUL, DIV, ... saves the work of doing formular parsing. We could define it like this:

Default values (if not specified) are:
REL = -1, whereas -1 is the index of a virtual note with the "Main" BaseFreq
CENTS = 0
HZ = 0
MUL = 1
DIV = 1

Just do a one-line stupid calculation:

ResultingFreq = ((BaseFreq[REL] * MUL / DIV) + CENTS) + HZ

No if/then, no string parsing, no special cases. And straight forward.

OK. But why the limitation to single line? Is this an 80 character limit?

Max. 255 characters per line; e.g. in C and with certain stream functions in C++ as well it's convenient to know what max. size a string can have. That's why the max. line length was given in the specs. But no one prevents you from defining something like that:

Param1 = SomethingVeryLong
Param1 =+ ContinueWhateverYouWantToSay

...or as it is done with the strings.

[H-Pi Instruments]

I don't say, xml is worse. I just think it won't be successful today due to the compatibility reasons. Tomorrow, the world may look different. I agree with you: Let's make things together; I'm willing to support it. And let the people decide which next step to take. BTW: That's why I noted the ability to embed .TUN data into xml without loss of downwards compatibility right with the current specs. So you just have to add something like <TUNData> ... </TUNData> and to care for some things, and your file will be readable by both: The existing TUN algorithms as well as xml-based.
Mmh. This could make stepping to xml easier because downwards compatibility can be ensured right at this stage.

Yes, I had already added a <TUN> tag, as well as <SCL> and <KBM> tags. ( http://www.h-pi.com/phpBB2/viewtopic.php?p=173#172 )

Float values are already there, even in scientific notation.

But your float values are CENTS, not decimal representation of a ratio. I mean decimal representation of a ratio such as 1.5 = 3/2 is a tone, where the boundaries are the octave and the decimal value is expected to be 1.0 >= x <= 2.0 within an octave.

But in fact, adding something like 3/2 or 2:3 to the existing note # keys will break downwards compatibility.

Right, because these are strings.

In the origin, .TUN was not designed as a format for editing scales but as a simple base to share them with others and amongst ones VSTis. It should never superseed .scl & Co..

In that case, I wonder if maybe the .tun format should just remain as simple, forgetting other external things and just allowing multiple scales / MIDI channels in the file?

By the way: What about "relative" or functional tunings with cross-references between notes, I mean something like that (I don't know whether this is already included):

note 2 = freq_of_note_1 + 5 Cents
note 3 = freq_of_note_1 + 10 Hz
note 4 = freq_of_note_1 * 1.2
note 5 = freq_of_note_1 / 1.4
note 6 = freq_of_note_1 * 1.2 / 1.4

In XML you could represent it like this:
<NOTE ID="1" HZ="123" />
<NOTE ID="2" REL="1" CENTS="5" />
<NOTE ID="3" REL="1" HZ="5" />
<NOTE ID="4" REL="1" MUL="1.2" />
<NOTE ID="5" REL="1" DIV="1.4" />
<NOTE ID="6" REL="1" MUL="1.2" DIV="1.4" />

My CSE and TPXE software does this, but I had not thought of putting it in TuningXML ...

And: Using MUL, DIV, ... saves the work of doing formular parsing. We could define it like this:

Default values (if not specified) are:
REL = -1, whereas -1 is the index of a virtual note with the "Main" BaseFreq
CENTS = 0
HZ = 0
MUL = 1
DIV = 1

Just do a one-line stupid calculation:

ResultingFreq = ((BaseFreq[REL] * MUL / DIV) + CENTS) + HZ

No if/then, no string parsing, no special cases. And straight forward.

Almost. You know Cents and Hz can't be combined this way. You have to do logarithmic conversion.

Max. 255 characters per line; e.g. in C and with certain stream functions in C++ as well it's convenient to know what max. size a string can have. That's why the max. line length was given in the specs. But no one prevents you from defining something like that:

Param1 = SomethingVeryLong
Param1 =+ ContinueWhateverYouWantToSay

...or as it is done with the strings.

Well, if it's possible to get rid of limitations like that, I say get rid of them; strings should be allowed to be any length with no limitation.

[H-Pi Instruments]

I've been looking over the proposed Info and Usage sections, comparing them to my previous draft, and I have these suggestions. First, as you proposed:

1) New section [Info]
Usage: Contains "hard facts" about the scale
Keys:
- Format = [String] File format. Will be a constant value which declares the file compatible with .TUN specifications.
- FormatVersion = [Int] Version of the file format.
- Name = [String] Name of the scale. If not given: use file name instead (without extension).
- File = [String] Filename suggested for the scale. If not given: use value for Name instead.
- Editor = [String] Software used to create/edit the file/scale
- Author = [String] Who created the scale
- Contact = [String] Contact information of the author
- Date = [string, date format YYYY-MM-DD according to DIN specifications ] Creation date of the scale. If not given: use file date instead.
- Keyword = [LString] Keywords which may help categorizing the scale
- Comment = [String] Free comment value for informations not covered by the other keys.

I'm not sure whether adding the keys "Format" and "FormatVersion" is a good idea. If this encourages developers to create their own derivative format leading to format confusions, we should forget them. On the other side it could be important for future use.

The Format and FormatVersion I think would be better as header information if possible, like a !DOCTYPE header in an XML document. It tells the parser what to expect for the whole document. Only the creator of the file format should have control over that part.

About Name and File - I have never liked the practice of including the filename as a data point in the file itself, because the file has a name already, and then the file name can be changed and the data in the file is not changed, then there is an annoying problem where they don't agree. Scala files do that, for example. I think the practice should be avoided.

Trying to make these attributes agree with TuningXML, I think under the [info] section should be:

- Name = a no-spaces identifier
- ID = a shorter alternate no-spaces identifier
- Description = an unlimited string
- Author = a string
- Location = a string
- Contact = a string
- Date = a string in any standard date format
- Editor = a string

The Comment becomes Description. Location here means where the Author resides.

2) New section [Usage]
Usage: What's the context of the scale? Notes about the usage.
Keys:
- History = [String] Description of the "historical context"
- Geography = [String] Description of the "geographical context"
- Ethnics = [String] Description of the "ethnical context"
- Style = [String] Description of the musical style the scale is typical for
- Instrument = [String] Description of the instrument the scale is typical for
- Song = [LString] Song in which the scale was used. Format: "Musician or Band | Album | Title | Year | Misc"
- Usage = [String] Free comment value for additional usage informations not covered by the other keys.

Of these attributes, I would suggest these small changes:

- History = a string
- Geography = a string
- Instrument = a string
- Composition = a string
- Comments = a string

Song becomes Composition. Style is omitted as it sounds too prescriptive to me. Ethnic still sounds too racist to me; if some remark needs to be made along those lines it can be done in Comments.

I'm not sure there needs to be a separate section called [Usage]. If all these attributes can fall under [info], I think it helps simplify the overall impression of this expansion to the format.

[Info]
Editor = "SuperCoolEditor Version 1.0"
Name = "aName"
ID = "anID"
Description = "A description of the scale"
Author = "John Q. Public"
Location = "Podunk Nowhere"
Contact = "http://www.johnqpublic.com"
Date = "December 26, 2008"
History = "A scale of Archytas"
Geography = "Greece"
Instrument = "plucked string"
Composition = "My awesome piece"
Comments = "Archytas was a Greek."


An important thing is that these should not need to be in any particular order. Does such order have to be prescribed in .tun? Again, the advantage of <> is that order does not matter.

3) Enhancing [Exact Tuning] section or new section [Absolute Tuning]
In [Absolute Tuning] section: Keys note 0 to note 127 as in [Exact Tuning], but tunings are given in Hz instead of Cents.
As an alternative: Would you prefer including this into the [Exact Tuning] section? Let's say: "note #" for cent values and "noteHz #" for Hz values?

I didn't say anything about this previously, but mixing Hz and Cents is kind of an odd idea unless the use of Hz is as a Hz *offset*, but that is a strange way to use Hz. Scala mixes cents and ratios. So, the main reason I suggest a different section for Hz is that it really only makes sense if all values are in Hz and are considered fixed frequencies for the desired MIDI notes. Such a section does not require any note mapping or base frequency. Each MIDI note has an absolute Hz value and that's all there is to it.

[AnaMark]

BTW: That's why I noted the ability to embed .TUN data into xml without loss of downwards compatibility right with the current specs. So you just have to add something like <TUNData> ... </TUNData> and to care for some things, and your file will be readable by both: The existing TUN algorithms as well as xml-based.

Yes, I had already added a <TUN> tag, as well as <SCL> and <KBM> tags. ( http://www.h-pi.com/phpBB2/viewtopic.php?p=173#172 )

Just placing the text into <TUN></TUN> won't work. You must do it this way:
<XML>
... Here comes your complete data
... But there must be no line starting with a '['
<TUN>
... Here comes the TUN data as it would be written into a .TUN file
__FakeKey = </TUN></XML>

The bold line is important. Software which works according to my TUN specs skips everything before the first section. So everything before (and including) <TUN> is ignored. The rest of the file must then confirm the TUN syntax. The key __FakeKey is not defined in the TUN specs and thus THE closing </TUN></XML> are ignored. Et voila. And you can read the file as normal XML file and just have to care for the __FakeKey line.

Float values are already there, even in scientific notation.

But your float values are CENTS, not decimal representation of a ratio.

Oh, now I see what you mean. Right: they aren't ratios.

But in fact, adding something like 3/2 or 2:3 to the existing note # keys will break downwards compatibility.

Right, because these are strings.

However, if we decide to not include noteHz into [Exact Tuning] but create another section [Editable Tuning], we can define keys and values like this:

note i = "#a*b/c%d+e-f"

#a: a denotes the reference note (a >= 0: absolute index, a < 0: relative)
*b: Multiply the frequency by b
/c: Divide the frequency by c
%d: Apply d Cents
+e: Add e Hz
-f: Subtract f Hz

Easy to parse and you can do almost anything you want.

In the origin, .TUN was not designed as a format for editing scales but as a simple base to share them with others and amongst ones VSTis. It should never superseed .scl & Co..

In that case, I wonder if maybe the .tun format should just remain as simple, forgetting other external things and just allowing multiple scales / MIDI channels in the file?

The users may decide so.

ResultingFreq = ((BaseFreq[REL] * MUL / DIV) + CENTS) + HZ

Almost. You know Cents and Hz can't be combined this way. You have to do logarithmic conversion.

Yes. No.

Yes, I know. It was a principle description.
No. There is no logarithmic conversion, but the opposite:
ResultingFreq = ((BaseFreq[REL] * MUL / DIV) * 2^(CENTS/1200)) + HZ

Max. 255 characters per line

Well, if it's possible to get rid of limitations like that, I say get rid of them; strings should be allowed to be any length with no limitation.

This may cause trouble with older software.

[AnaMark]

The Format and FormatVersion I think would be better as header information if possible, like a !DOCTYPE header in an XML document.

ACK. It could be part of [Scale Begin]. But to be flexible in the future, it should be valid for one dataset, not for the whole document.

About Name and File - I have never liked the practice of including the filename as a data point in the file itself, because the file has a name already, and then the file name can be changed and the data in the file is not changed, then there is an annoying problem where they don't agree. Scala files do that, for example. I think the practice should be avoided.

In the case, an old TUN is read we have to give it some name; therefore it should do the job. But you are right: the field NAME should not be optional.

Trying to make these attributes agree with TuningXML, I think under the [info] section should be:

- Name = a no-spaces identifier
- ID = a shorter alternate no-spaces identifier
- Description = an unlimited string
- Author = a string
- Location = a string
- Contact = a string
- Date = a string in any standard date format
- Editor = a string

The Comment becomes Description. Location here means where the Author resides.

For descriptive names and due to readability, spaces are a must-be. Imho. Such limitations sound like "back to MS-DOS!" in my ears. 8.3 and so. No, I had enough of it. But ID can be defined without white spaces (Take care for tabulators and other things). I suggest a restriction like "a-z0-9" for the ID.

About Date: To make it searchable, the format should be clearly defined. There is an international standard about how to write dates (ISO 8601). We should use it. Localization should happen in the GUI - not in the file.

2) New section [Usage]
...

Of these attributes, I would suggest these small changes:

- History = a string
- Geography = a string
- Instrument = a string
- Composition = a string
- Comments = a string

Song becomes Composition. Style is omitted as it sounds too prescriptive to me. Ethnic still sounds too racist to me; if some remark needs to be made along those lines it can be done in Comments.

ACK about style. About ethnic: You are the native speaker. If you say, "ethnic" is a problem, then I believe it. The information can also be stored in Geography.

We can merge [Info] and [Usage].

An important thing is that these should not need to be in any particular order. Does such order have to be prescribed in .tun? Again, the advantage of <> is that order does not matter.

No. This is no advantage. In TUN you can freely decide for which parts order does matter and for which not (in the current specs, order does not matter). If you want you can say "section A: order does not matter, but section B: order does matter". In TUN you have the choice. In XML there is no choice.

[H-Pi Instruments]

Just placing the text into <TUN></TUN> won't work. You must do it this way:
<XML>
... Here comes your complete data
... But there must be no line starting with a '['
<TUN>
... Here comes the TUN data as it would be written into a .TUN file
__FakeKey = </TUN></XML>

Ok, I hadn't thought of TUN being parsed directly from the XML. But according to your spec as I read it, the same could be accomplished with this:

<TUN>
[Tuning]
...
[Exact Tuning]
...
[END]
</TUN>

because as soon as [END] is found the rest is ignored, right?

if we decide to not include noteHz into [Exact Tuning] but create another section [Editable Tuning], we can define keys and values like this:

note i = "#a*b/c%d+e-f"

#a: a denotes the reference note (a >= 0: absolute index, a < 0: relative)
*b: Multiply the frequency by b
/c: Divide the frequency by c
%d: Apply d Cents
+e: Add e Hz
-f: Subtract f Hz

Easy to parse and you can do almost anything you want.

That is quite clever, and sure if you want to implement it it's cool, but personally I think features like this belong in editor software, where this and a lot more can be done much better, and I think also you also had expressed this same opinion at the outset. It just begs questions - if it can do this, then why can't it do that and the other? IMO it leads to too much complexity and things that should reside in software, but if you want it, why not? See if anyone uses it.

Yes, I know. It was a principle description.
No. There is no logarithmic conversion, but the opposite:
ResultingFreq = ((BaseFreq[REL] * MUL / DIV) * 2^(CENTS/1200)) + HZ

OK, log one way, exponent the other, depends which units you wanted - I was expecting cents based on your current spec. Anyway, it's cool but my response is above... I think it's better to keep it simple - whatever the section units type, the values should be single discrete values, only transposable by one reference parameter global to that scale or all the scales in the file.

Max. 255 characters per line
(getting rid of)
This may cause trouble with older software.

Well, shouldn't those older softwares just update or go the way of the dinosaur? I think limits like that are long obsolete by now.

[H-Pi Instruments]

... (sorry I missed this entire post previously)

For descriptive names and due to readability, spaces are a must-be. Imho. Such limitations sound like "back to MS-DOS!" in my ears. 8.3 and so. No, I had enough of it. But ID can be defined without white spaces (Take care for tabulators and other things). I suggest a restriction like "a-z0-9" for the ID.

The Name and ID should be no-spaces to conform to basic web practice for these elements, as seen in both HTML and XML. I don't know why this would be such a big deal as in programming we do this all the time whereEverythingIsOneBigString. The thing which is obsolete and annoying IMO is string length limitation to 255 characters. Strings in our 'modern age' should be (and *are* in the language I use anyway) of any length, limited only by available memory.

About Date: To make it searchable, the format should be clearly defined. There is an international standard about how to write dates (ISO 8601). We should use it. Localization should happen in the GUI - not in the file.

Agreed. This is also standard web practice for the 'datetime' object, which is

YYYY-MM-DDThh:mm:ssTZD

where T after DD is a separator between date and time, and TZD is a Time Zone Designator.

So, we want only the date YYYY-MM-DD, like you said to begin with

No. This is no advantage. In TUN you can freely decide for which parts order does matter and for which not (in the current specs, order does not matter). If you want you can say "section A: order does not matter, but section B: order does matter". In TUN you have the choice. In XML there is no choice.

No; XML *does* have the option to force elements to be in some order, but who wants that? It's unnecessarily difficult and unreasonable for hand coding. The node structure of XML is simple object orientation common to modern programming languages, which I feel is a big advantage.

I didn't know you could specify in your format that order doesn't matter. Great! Then I assume based on other things you have written that your format also (like XML) does not require all the key/value pairs to be there? For example in the [INFO] section if I only want to include Author and nothing else, that's OK?

[Chuck E. Jesus]

get a room you two...

[Meffy]

Psst... we're in their room. C'mon, other threads this way.

[Chuck E. Jesus]

well, there were quite a few threads...and one of the dudes signed up the day the threads started, the other dude was here forever...no one else is posting...i don't get it, i'm sure what they are discussing is important and that's about it...

[Meffy]

It's a developer thing, but of interest to some instrument users too. Otherwise I'd say these topics belonged in the DSP forum.