Another approach at the MPTM format

[Saga Musix]

Another idea that's worth discussing imho:
Why not use / adapt the XRNS format that's being used in renoise? Basically, XRNS is a zip file which contains the patterns in xml format and the samples as seperate FLAC/MP3/OGG Files. In my opinion, this is a really good and expansible container format.

[Relabsoluness]

Sounds like an idea worth keeping in mind. Are the format specs anywhere to be found?

[Saga Musix]

Well, there are some basic hints at http://www.renoise.com/board/index.php?showtopic=11892 and some more stuff at that board, but I'm sure it's easy to read the xml data. There are coming quite a few example songs with can be looked into.

[bvanoudtshoorn]

The question, of course, is whether OpenMPT should be compatible with Renoise. The XML+Binary compressed storage thing is used a lot nowadays (for example in OpenOffice and DocX). To be compatible with Renoise, there'd have to be some pretty substantial changes to OpenMPT itself, so perhaps just using the idea of the format is a good one. Or is that what you meant in the first place?

[LPChip]

I'm pretty sure thats what Jojo ment in the first place.

[Saga Musix]

Well, ModPlug is currently not really "compatible" with Renoise and vice versa, so I just thought about adapting the format - Or else, Renoise people would come up and claim we're raping their format.

[LPChip]

Its not really possible to fully support the renoise format yet. Simply because renoise offers more things like custon note width and effects column width. The GUI is simply not offering support for that.

[Saga Musix]

Duh, that's what I just said.

[älskling]

I think this is a great idea!

[Saga Musix]

Here's my first draft for the MPTM format. I began to write DTDs for the XML files, but I've realized that DTD is too limited for this (e.g. you only have #PCDATA as a data type), so I'd rather go for an XSD schema (but I have my lecture slides about XSD at my study place, so I can't do that right now ).
Anyway, here are all the xml files needed to describe a module file. Have I forgotten something? A review by someone who knows XML would be appreciated, as I'm not sure if the usage of attributes vs. elements is always logical.

http://sagamusix.de/openmpt/download/mptm_draft.zip

Basic structure:

• MPTM.xml
  Basic information about the module
  A document type definition (DTD) is available.
  
• Samples.xml
  Sample attributes
  
• Instruments.xml
  Instrument attributes
  
• Sequence.xml
  Order list + Restart position
  
• Channels.xml
  Channel attributes
  
• Patterns.xml
  Pattern data
  
• Plugins.xml
  Plugin attributes
  
• Macros.xml
  SFx + Z80-ZFF definitions
  
• MidiMapping.xml
  Stored midi mappings (incomplete)
  
• Tunings.xml
  Stored tunings (incomplete)
  
• Workspace.xml
  Window layout in OpenMPT
  

[bvanoudtshoorn]

Well, I work with XML an awful lot of work, so here are my thoughts.

1. Why have you split up the different parts into different files? To my mind, you'd have a cleaner structure if you had just one or two files, with different sections, rather than distinct files. This way'd actually be slightly easier to work with programatically, too, as you'd only have to load a single file, and then obtain references to the appropriate XML nodes (which you'd do with multiple files, anyway).

2. In instruments/instrument/envelopes//envelope, I would suggest putting some sort of ID attribute on the nodes, and then referencing this ID from within loop and sustainloop -- an XML document isn't guaranteed to have a particular order, and you don't really want to be linked from the tick number.

3. Module/Volume -- move the attribute "mixmode" into a subnode.

4. Module/Tempo -- move the attribute "mode" into a subnode.

5. This is just me, but I think Module/Flags would be more logically named Module/Options (although yes, they are called 'flags' in the system, but 'options' gives you more semantic scope.

6. Patterns//Pattern -- you need some sort of unique identifier for each distinct pattern, too.

7. How are you referencing the actual sample files? I can't see it... Perhaps you need to include a URI node that points to Samples/{{blah.wav}} for each sample. Again, nodes aren't ordered...

8. Given that the samples are stored, is it necessary to store redundant information like the sample's bitrate, channels, and length?

9. Patterns need some method of ordering them -- a "seq" attribute, perhaps, going from 0 to n.

10. Perhaps rename Workspace/Window/Tab to ActiveTab for clarity.

[Saga Musix]

1. Why have you split up the different parts into different files? To my mind, you'd have a cleaner structure if you had just one or two files, with different sections, rather than distinct files. This way'd actually be slightly easier to work with programatically, too, as you'd only have to load a single file, and then obtain references to the appropriate XML nodes (which you'd do with multiple files, anyway).

I don't really agree that less files would be easier to handle. Especially when I look at the XRNS format - it's terrible to keep everything in one file IMO.

2. In instruments/instrument/envelopes//envelope, I would suggest putting some sort of ID attribute on the nodes, and then referencing this ID from within loop and sustainloop -- an XML document isn't guaranteed to have a particular order, and you don't really want to be linked from the tick number.

Good catch, I actually forgot that loop points have to be linked to a node.

But actually, from what I know, the order in an XML document is important, so I don't see why I would have to use an ID here.

3. Module/Volume -- move the attribute "mixmode" into a subnode.
4. Module/Tempo -- move the attribute "mode" into a subnode.

Why? I consider attributes as "descriptions", and in this case, "mixmode" and "mode" describe how to interpret the child nodes. This is actually one of the few cases where I'd say that attributes make sense.

5. This is just me, but I think Module/Flags would be more logically named Module/Options (although yes, they are called 'flags' in the system, but 'options' gives you more semantic scope. Smile)

Good idea.

6. Patterns//Pattern -- you need some sort of unique identifier for each distinct pattern, too.

Why's that? Storing empty patterns (which are rare) as <Pattern /> would take less space than using IDs.

7. How are you referencing the actual sample files? I can't see it...

Not at all ATM, Because I still don't know if I should just take the sample number as a filename or something like "1 - Sample's filename.wav" (where sample's filename would be the <filename> tag)

8. Given that the samples are stored, is it necessary to store redundant information like the sample's bitrate, channels, and length?

Good question. I guess it can be omitted.

9. Patterns need some method of ordering them -- a "seq" attribute, perhaps, going from 0 to n.

I can't really see what this would be useful for, care to explain?

10. Perhaps rename Workspace/Window/Tab to ActiveTab for clarity.

Done.

[Rakib]

Some criticism about the rnsformat using the xml.

http://multimedia.cx/eggs/renoise-xrns/

[g]

Some criticism about the rnsformat using the xml.

http://multimedia.cx/eggs/renoise-xrns/

I think that's pretty much missing the point...

On a more general note, it would be sweet if there were some cross compatibilty with renoise.

[Saga Musix]

Yes, I don't like the structure of XRNS as well.
If noone wants XML, I could also imagine an INI-Like text format, which would still be rather versatile.