Another approach at the MPTM format

[Saga Musix]

I disagree completely; I see nothing restricting future expansion.

The stuff that doesn't fit there can be saved elsewhere; not a big problem.

Sure, you can always tack stuff at the end of a file, but I can you also see that storing information about an instrument in 4 places in the same file is not a very good idea.

Also, I guess I'll work together on this with xaimus, who has already brought up another possible approach:
http://code.google.com/p/protobuf/

eally, easy for programmers to write utilities

yes and no. Think of the difficulties to get an easy to use, maintained, working and still light-weight XML library for your weapon of choice (= your favourite programming language). I don't think that this exists in all cases. And getting into XML programming would also be necessary. Once you have this all, it's a piece of cake of course.

[Relabsoluness]

And the benefit of a format like XML etc is that it's really, really, easy for non-programmers to see what's going on, and really, really, easy for programmers to write utilities.

Perhaps because I don't know about this, I tend to think that this is to some extend similar to "open your source and there'll be bunch of skilled developers working on the program"-hype. Are there easy to understand, concrete examples of such non-programmer made utilities for XRNS/OpenOffice etc.?

Sure, you can always tack stuff at the end of a file, but I can you also see that storing information about an instrument in 4 places in the same file is not a very good idea.

Yes, but I think this is more about prettiness than extensibility. And adding stuff at the end of file doesn't imply that the data must be spread. And what is good about this, is that there's no need to write everything from scratch - which is a type of plan that often tends to remain unfinished - but there's existing IT save/load functionality on top of which extensions can be included.

[bvanoudtshoorn]

And the benefit of a format like XML etc is that it's really, really, easy for non-programmers to see what's going on, and really, really, easy for programmers to write utilities.

Perhaps because I don't know about this, I tend to think that this is to some extend similar to "open your source and there'll be bunch of skilled developers working on the program"-hype. Are there easy to understand, concrete examples of such non-programmer made utilities for XRNS/OpenOffice etc.?

Yep! For example, http://sector-seven.net/software/rpg .

yes and no. Think of the difficulties to get an easy to use, maintained, working and still light-weight XML library for your weapon of choice (= your favourite programming language). I don't think that this exists in all cases. And getting into XML programming would also be necessary. Once you have this all, it's a piece of cake of course.

I dunno... Java, C#, C++, Delphi, Javascript, PHP, and lots more all have really good, solid, well-maintained XML management implementations. And to be honest, 'getting into XML programming' is a lot easier than getting into binary-format programming.

Think of the awesome possibilities an XML-filetype opens up for end users:

1. Using the HTML-5 <audio> tag, you could actually watch the contents of a file 'play' by syncing pattern switches (or whatever) to key points in the audio (fairly easily, too -- check out some of the examples at http://hacks.mozilla.org/2009/06/exploring-music-audio/ for more on this type of thing)

2. XSLT transformations -- with endless possibilities. For example, transposing the entire track up or down; automatically generating 'echo' channels; interpolating and smoothing effects according to various algorithms, not just linear; scaling effect data; collecting statistical information about the track; creating computational music; generating melodic phrases based on a 'seed'; just about anything! Yes, you could do this with a binary format, but you'd have trouble with it.

3. Back- and forward-compatibility. If an earlier version of the software doesn't know about a node, it won't look for it, and Relabs will keep a 'pretty' format.

There is, of course, more... You have to understand that the power of XML really shines when it comes to a) working with it in multiple environments, and b) transforming documents using XSLT. For me, (b) is really significant: at work, we use JSON for client/server interaction, but for producing PDF reports, we pull the data back as XML and use FOP+XSLT to transform and render it. You can't do that easily with JSON or a binary format -- with a binary format, you have to write a specific class/program to handle each report. With XML+XSLT, you can write much more generic code.

Think about it -- 'plugins' for OpenMPT could be as simple as loading up an XSLT file, using it transform the current selection/file, and then showing the results. It'd be fairly simple to implement -- much simpler than a 'real' scripting/plugin system.

[Rxn]

bvanoudtshoorn:

I don't understand quite everything what you have spoken about here, but it sure touched my heart:)