[TUN] Database usage

[AnaMark]

We can easily modify the .TUN format so that one file can contain multiple scales as is preferable for databases.

To achieve this, I suggest adding two markers having the syntax of a section: [Scale Begin] and [Scale End]. Everything outside those both markers has to be ignored. An additional feature is the ability to embed scale data in other text files such as xml. (Note: With the current specifications, single tuning files already can be embedded in xml without loss of compatibility as long as a few aspects are considered.)

As file extension I suggest .MSF for "Multiple Scale File".

[H-Pi Instruments]

We can easily modify the .TUN format so that one file can contain multiple scales as is preferable for databases.

To achieve this, I suggest adding two markers having the syntax of a section: [Scale Begin] and [Scale End]. Everything outside those both markers has to be ignored. An additional feature is the ability to embed scale data in other text files such as xml. (Note: With the current specifications, single tuning files already can be embedded in xml without loss of compatibility as long as a few aspects are considered.)

As file extension I suggest .MSF for "Multiple Scale File".

I think for a database having single scales in single files is better, but there is a real practical need for multiple scales in one file, for use with such instruments as the Tonal Plexus which have tuning tables mapped to multiple MIDI channels. What is needed is a way to contain up to 16 tables in one file, with MIDI channels specified for each table.

Could it be that adding a the following parameters to your [Exact Tuning] tags would do it?

index=i
channel=c

where i = an index number for the scale, and c is a MIDI channel.

[AnaMark]

I think for a database having single scales in single files is better,

NACK. Just have a look into the public scale libraries: There are hundreds of files. File systems're usually getting slower if a folder is filled with too many files. We waste storage space, as even a file with a few bytes takes 64kB or so.

It's easy to put it up - and we'll see whether the people use it or not. But at least, they have the chance to use it.

but there is a real practical need for multiple scales in one file, for use with such instruments as the Tonal Plexus which have tuning tables mapped to multiple MIDI channels. What is needed is a way to contain up to 16 tables in one file, with MIDI channels specified for each table.

Could it be that adding a the following parameters to your [Exact Tuning] tags would do it?

index=i
channel=c

where i = an index number for the scale, and c is a MIDI channel.

Got the point. Yes, the MSF-approach can also be used for this.

The question is: Do we need multiple [Info], [Usage], ... sections or not? I think we should make them optionally possible.

[H-Pi Instruments]

NACK. Just have a look into the public scale libraries: There are hundreds of files. File systems're usually getting slower if a folder is filled with too many files. We waste storage space, as even a file with a few bytes takes 64kB or so.

OK, do you mean there are libraries for .tun files? Can you post a link?

but there is a real practical need for multiple scales in one file, for use with such instruments as the Tonal Plexus which have tuning tables mapped to multiple MIDI channels. What is needed is a way to contain up to 16 tables in one file, with MIDI channels specified for each table.

Could it be that adding a the following parameters to your [Exact Tuning] tags would do it?

index=i
channel=c

where i = an index number for the scale, and c is a MIDI channel.

Got the point. Yes, the MSF-approach can also be used for this.

The question is: Do we need multiple [Info], [Usage], ... sections or not? I think we should make them optionally possible.

I agree; all the additional sections not directly affecting tuning itself should be optional for any scale.

[AnaMark]

OK, do you mean there are libraries for .tun files? Can you post a link?

http://www.xs4all.nl/~huygensf/scala/downloads.html

Go to the bottom of the site. The Scale Archive contains 3700 scales. I also had a link for a this archive (maybe an older version of it) converted to .TUN, but I don't find it any more.

I agree; all the additional sections not directly affecting tuning itself should be optional for any scale.

This means we have to make it optionally possible. In this case I would do something like that:

[Scale Begin]

[INFO]
; ... your keys and values
; And a new key working as a command which will set the
; data of the current INFO section as new default values for
; the following sections if no data is given there. That
; way we don't need to specify the same data again and again
; for each MIDI Channel, but just the differences
SetDefault = ()


[MIDI]
Channel = 1

;... other sections here

[Scale End]

[H-Pi Instruments]

The Scale (.scl) Archive contains 3700 scales.

OK. I know about that one. It is a lot of scales, but they are unorganized and in a format not designed for a database.

.. I would do something like that:

[Scale Begin]

[INFO]
; ... your keys and values
; And a new key working as a command which will set the
; data of the current INFO section as new default values for
; the following sections if no data is given there. That
; way we don't need to specify the same data again and again
; for each MIDI Channel, but just the differences
SetDefault = ()


[MIDI]
Channel = 1

;... other sections here

[Scale End]

1) In this case, would a [tag] such as [Global] make more sense?
2) Since there is a [MIDI] tag how will this be overridden? Will [Exact Tuning] have a [MIDI] within it?

At this point maybe you could flesh it out and give an example or two?

[AnaMark]

The Scale (.scl) Archive contains 3700 scales.

OK. I know about that one. It is a lot of scales, but they are unorganized and in a format not designed for a database.

This could change if there is a usable database editor.

; And a new key working as a command which will set the
; data of the current INFO section as new default values for
; the following sections if no data is given there. That
; way we don't need to specify the same data again and again
; for each MIDI Channel, but just the differences
SetDefault = ()

1) In this case, would a [tag] such as [Global] make more sense?
2) Since there is a [MIDI] tag how will this be overridden? Will [Exact Tuning] have a [MIDI] within it?

At this point maybe you could flesh it out and give an example or two?

Ad 1):
Making a "twin" (section with same properties, just the name differs) would be a possibility; right. Mmh. I'm not so lucky with that feature. As a consequence, the [Global] had to be outside [Scale Begin] and [Scale End]. And SetDefault() seems also to be misplaced within. I would like to keep it all within [Scale Begin] and [Scale End].

As 2):
Sections are in sequence. There is no hierarchy, which means: There cannot be a section within another one. It just is placed before or after.

An Example could be:

[Scale Begin]
[INFO]
; ... your keys and values
SetDefault = ()
[MIDI]
Channel = 1
[Exact Tuning]
;... the tuning data
[Scale End]

[Scale Begin]
[INFO]
; ... the keys whose values deviate from the default set above
[MIDI]
Channel = 2
[Exact Tuning]
;... the tuning data
[Scale End]

[Scale Begin]
[INFO]
; ... the keys whose values deviate from the default set above
[MIDI]
Channel = 3
[Exact Tuning]
;... the tuning data
[Scale End]

; ... and so on for channels 4-16

[H-Pi Instruments]

The Scale (.scl) Archive contains 3700 scales.

>> It is a lot of scales, but they are unorganized and in a format not designed for a database.

This could change if there is a usable database editor.

Right. I've already written one for myself, which I call ScalaVista. It just creates a single user local database from the huge folder of files. But without adding additional attributes in some systematic way, still only filenames, comments and scale data can be searched. I told Manuel Op de Coul that I had made this program for myself, and I asked about making a live database similar to those for my software, available online. He was receptive but wanted some time to think about it.

An Example could be:

[Scale Begin]
[INFO]
; ... your keys and values
SetDefault = ()
[MIDI]
Channel = 1
[Exact Tuning]
;... the tuning data
[Scale End]

[Scale Begin]
[INFO]
; ... the keys whose values deviate from the default set above
[MIDI]
Channel = 2
[Exact Tuning]
;... the tuning data
[Scale End]

[Scale Begin]
[INFO]
; ... the keys whose values deviate from the default set above
[MIDI]
Channel = 3
[Exact Tuning]
;... the tuning data
[Scale End]

; ... and so on for channels 4-16

It looks straightforward to me. I could use this! The only thing I don't quite get is the SetDefault = (). So () is a reference to the section containing the statement SetDefault, and it has to be = to something? Also, if there is no [INFO] different in any sections, MUST it be included?

Along with that - did you read the other post about the list of attributes? I posted on TL asking for input to help determine them. ( http://launch.groups.yahoo.com/group/tu ... sage/79664 )

[AnaMark]

It looks straightforward to me. I could use this! The only thing I don't quite get is the SetDefault = (). So () is a reference to the section containing the statement SetDefault, and it has to be = to something? Also, if there is no [INFO] different in any sections, MUST it be included?

I try to explain it:

The users know .ini files as storage for data. As the .tun syntax is similar to .ini files, they will read them the same way.

But SetDefault is different. It is not a
key = value
thing, but a command. When proposing the ability for commands I had in mind that in future, there might be commands with parameters. So the brackets have two functions:

a) They show, that this is a command, not a key entry
b) They contain the parameters of the command.

The meaning of SetDefault is: Take the values of the keys of the current [INFO] section as defaults for the following sections. (And of course, it is possible to place another SetDefault some datasets later).

SetDefault has no parameters, so the brackets are empty. The '=' is there to keep the syntax and to avoid errors when the file is read with older software.

Along with that - did you read the other post about the list of attributes? I posted on TL asking for input to help determine them. ( http://launch.groups.yahoo.com/group/tu ... sage/79664 )

Just 15 Minutes ago.

[H-Pi Instruments]

The meaning of SetDefault is: Take the values of the keys of the current [INFO] section as defaults for the following sections. (And of course, it is possible to place another SetDefault some datasets later).

SetDefault has no parameters, so the brackets are empty. The '=' is there to keep the syntax and to avoid errors when the file is read with older software.

OK, got it.

I guess your spec might be done soon. Unless there is something else?

Some new things I learned about XML mean I have to do some revisions to TuningXML, but I can still make it follow TUN.

[AnaMark]

I guess your spec might be done soon. Unless there is something else?

Some new things I learned about XML mean I have to do some revisions to TuningXML, but I can still make it follow TUN.

I think we should keep the topic open at least until the end of january. Then let's post a summary here. There might still be some details to clarify.