Another approach at the MPTM format

Started by Saga Musix, January 06, 2009, 14:32:52

Previous topic - Next topic

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.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

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.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

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.
"Heh, maybe I should've joined the compo only because it would've meant I wouldn't have had to worry about a damn EQ or compressor for a change. " - Atlantis
"yes.. I think in this case it was wishful thinking: MPT is makng my life hard so it must be wrong" - Rewbs

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. :D
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

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.
"Heh, maybe I should've joined the compo only because it would've meant I wouldn't have had to worry about a damn EQ or compressor for a change. " - Atlantis
"yes.. I think in this case it was wishful thinking: MPT is makng my life hard so it must be wrong" - Rewbs

Saga Musix

» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

älskling


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 :P).
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
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

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

Quote1. 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.

Quote2. 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.

Quote
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. :)

Quote
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.

Quote
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. :P

Quote7. 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)

Quote8. 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.

Quote
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? :)

Quote
10. Perhaps rename Workspace/Window/Tab to ActiveTab for clarity.
Done.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

Rakib

^^

g

Quote from: "Rakib"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. :P
If noone wants XML, I could also imagine an INI-Like text format, which would still be rather versatile.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.