[TUN] TUN Information content

[koolkeys]

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

Apparently, only two people are interested. There WERE quite a few threads discussing the same topic though.

Brent

[Meffy]

Yes, when they began I was thinking of merging them (by quoting, there's no facility for actually joining threads together) but read the OP's rationale for separating the topics in what I suppose was the first of the threads. Not sure I agree that there should be separate threads but as long as they don't proliferate further I don't particularly object.

Other moderators might feel differently, and if they want to act on their feelings I won't presume to second-guess them.

[koolkeys]

I do have the ability to ignore threads, so I won't exactly lose sleep over it. I was just noticing. I do know that there was a reason for separating them, but it also seems that most of them have fallen off.

Brent

[Meffy]

*nod* Could be a slow discussion, a stop and start kind of thing.

[AnaMark]

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

Apparently, only two people are interested.

Sorry guys for bothering you.

The reason I decided to start this topic at KVR was that here there are a lot of developers and users. I wanted to give both sides the chance to take part.

I didn't expect we two are the only ones to discuss the topic here.

For my next threads I will first start a poll to see how many people would join

BTW: Not all [TUN] threads come from me but are copycats.

[H-Pi Instruments]

I know I'm new to this forum, but I joined in order to discuss this topic, because the person who started the topic wanted the discussion to take place here. As I understand the way forums usually work, posts added to a topic should be on that topic, which these recent chit-chat messages are not. Could the moderator please remove them (including this one) so this thread can continue on topic as it should?

Thank you!

[koolkeys]

I know I'm new to this forum, but I joined in order to discuss this topic, because the person who started the topic wanted the discussion to take place here. As I understand the way forums usually work, posts added to a topic should be on that topic, which these recent chit-chat messages are not. Could the moderator please remove them (including this one) so this thread can continue on topic as it should?

Thank you!

Some of those comments are BY a moderator.

Brent

[koolkeys]

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

Apparently, only two people are interested.

Sorry guys for bothering you.

The reason I decided to start this topic at KVR was that here there are a lot of developers and users. I wanted to give both sides the chance to take part.

I didn't expect we two are the only ones to discuss the topic here.

For my next threads I will first start a poll to see how many people would join

BTW: Not all [TUN] threads come from me but are copycats.

You're not really bothering anyone. I was just noticing. Trust me, if I had a problem with it, I would just have to get over it.

More people may join though. I just noticed that only two people were in the conversation at present.

Don't stress too much over it. We're just bored, I guess.

Brent

[Meffy]

@H-Pi: Just keep posting on topic and it'll re-rail itself. I'm done with the meta-discussion and hope others are too. I'd rather leave those posts there as they might avoid someone else bringing the same thing up and disrupting your conversation all over again. As above, if some other mod thinks otherwise they're welcome to split the digression away with no complaints from me.

Some of those comments are BY a moderator.

True, but they're of no particular worth. Just a little side issue that with luck is done with now.

[AnaMark]

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?

Indeed. Too many trees in the wood to find one. A better and for the next specs ideal solution would be using the [Scale Begin] and [Scale End] sections as they are defined for that purpose (And you are sure, that in future specs there won't arise problems.):

<TUN>
[Scale Begin]
Format = ...to be defined...
FormatVersion = ...to be defined...

[Tuning]
...
[Exact Tuning]
...
[Scale End]
</TUN>

[AnaMark]

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.

NACK:

1) Years ago no one knew why it would be such a big deal having only 255 chars per line, 8.3 file names, 640kB RAM... I see us discussing in 5 years where you try to convince me to allow spaces in the name, as (enter the arguments you wrote concerning the 255 chars limit )

2) If the NAME element of HTML and XML is not capable of this, take another one, e.g. ScaleName.

3) In software development it is important to see what belongs together and what not. Therefore, variable names in one piece (without spaces) help the developer to see that it is one variable and not two (or three...). It avoids misunderstandings if there are e.g. the variables best, cook and best cook. It is necessary to make source code unambiguous. None of these arguments fits the naming of scales.

4) Musicians are musicians and (in most cases) not software developers. Software developers think in structures and algorithms, musicians in chords and harmonies. Only few people can both. What is common usage for a developer can bother a musician and vice versa.

5) Most users - and even developers - use spaces in their file names. O.K., not for source code files but for text files, data bases, images and so on. Do you really name the images you took of your family "20083112MyDaughterWithHerDogInTheGarden"? I prefer "2008-31-12 My daughter with her dog in the garden".

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.

We can move the 255 chars limit, I think.

BTW: Giving a length limit is also a task of security. Many exploits and security holes rise from buffer overflows. So don't be too generous. How is string length detected? 32Bit? 64Bit? Signed? Unsigned? What happens if an overflow occurs? Is your software safe?

Therefore my question: Should we really remove the length limit? Or would it do the job setting it to 1 000 000 e.g.?

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?

Right. Currently all keys are optional. I think about making an exception for "Format" and "FormatVersion".


By the way: After reading you post at TL, I got mixed up with "Description" and "Comment". Maybe for a native language speaker it is clear. I would prefer renaming it, e.g.:

"ScaleDescription"
"UsageComment"

Or maybe you have a better idea.

[H-Pi Instruments]

1) Years ago no one knew why it would be such a big deal having only 255 chars per line, 8.3 file names, 640kB RAM... I see us discussing in 5 years where you try to convince me to allow spaces in the name, as (enter the arguments you wrote concerning the 255 chars limit )

2) If the NAME element of HTML and XML is not capable of this, take another one, e.g. ScaleName.

3) In software development it is important to see what belongs together and what not. Therefore, variable names in one piece (without spaces) help the developer to see that it is one variable and not two (or three...). It avoids misunderstandings if there are e.g. the variables best, cook and best cook. It is necessary to make source code unambiguous. None of these arguments fits the naming of scales.

4) Musicians are musicians and (in most cases) not software developers. Software developers think in structures and algorithms, musicians in chords and harmonies. Only few people can both. What is common usage for a developer can bother a musician and vice versa.

5) Most users - and even developers - use spaces in their file names. O.K., not for source code files but for text files, data bases, images and so on. Do you really name the images you took of your family "20083112MyDaughterWithHerDogInTheGarden"? I prefer "2008-31-12 My daughter with her dog in the garden".

OK, I found out some important things about XML I didn't get from my first readings. Affecting this discussion is that the name attribute does not *have* to be a token (no spaces), only the ID. For the rest of what you say there - fair enough : )

Should we really remove the length limit? Or would it do the job setting it to 1 000 000 e.g.?

Yes, that would do the job, and maintain security for PCs I suppose.

Currently all keys are optional. I think about making an exception for "Format" and "FormatVersion".

But to me those seem the least self-evident, meaning if I were to use them I probably would have to look this up each time if I did not have a template. Do you mean they are to be required to use the new TUN spec?

By the way: After reading you post at TL, I got mixed up with "Description" and "Comment". Maybe for a native language speaker it is clear. I would prefer renaming it, e.g.:

"ScaleDescription"
"UsageComment"

Comparing 'Description' and 'Comment' literally, the first implies formality while the second implies informality. So, a description is formal prose about essential characteristics of the item, and comments are more off-hand, non-essential, perhaps disconnected remarks about the item.

[AnaMark]

OK, I found out some important things about XML I didn't get from my first readings. Affecting this discussion is that the name attribute does not *have* to be a token (no spaces), only the ID.

Which charset is allowed for the ID? What's its syntax?

Currently all keys are optional. I think about making an exception for "Format" and "FormatVersion".

But to me those seem the least self-evident, meaning if I were to use them I probably would have to look this up each time if I did not have a template. Do you mean they are to be required to use the new TUN spec?

I'm not sure whether I understand correctly what you wrote; I especially don't get the point about the "template"-thing. Could you be a little bit more verbose? The old TUN specs do not require them (they don't know those keys); if the keys are missing, the old TUN specs are assumed. But the new specs will require them.


Another idea: What about a key "SpecsURL"? This key would contain the URL to where the specs can be found. This could help encouraging people to incorporate the format in their software.

[H-Pi Instruments]

Which charset is allowed for the ID? What's its syntax?

UTF-8. The only constraints are that it cannot begin with a number and it has no spaces.

I'm not sure whether I understand correctly what you wrote; I especially don't get the point about the "template"-thing. Could you be a little bit more verbose? The old TUN specs do not require them (they don't know those keys); if the keys are missing, the old TUN specs are assumed. But the new specs will require them.

Format and Format Version tags are only necessary if the specs of the document are going to be changing, as in software development. Unless you see TUN changing rapidly in this way, I don't see the need for such tags. They become boring unnecessary header information which basically does nothing functional. So I would leave them out for now, and if you find you want to change the format again, then you can introduce those tags to distinguish the later version from this version. Only one version does not need the tags.

Another idea: What about a key "SpecsURL"? This key would contain the URL to where the specs can be found. This could help encouraging people to incorporate the format in their software.

Sure, why not. That becomes more like an XML DTD. Which, BTW -- I found this awesome resource for XML - a whole university course online for free!
<http://dret.net/lectures/xml-fall08/>
Take a few minutes and poke around there and you may see why I like XML so much.

[AnaMark]

Format and Format Version tags [...]
So I would leave them out for now, and if you find you want to change the format again, then you can introduce those tags to distinguish the later version from this version. Only one version does not need the tags.

Err... We already have one version; we a designing the second one. And as you said: The first version of the specs didn't have those tags. But the second one might/should have.