This article is technical. It covers Renoise 1.8.0 b2, XML file format revision 2.
It’s a great idea that we at last have the XML format. It opens a wide variety of new possibilities. Unfortunately, some of the ideas in the current implementation make it hard to use all the goodies that XML gives us. However, since the format is still undocumented, I hope some things may be either solved or just properly justified.
Disclaimer: Keep in mind that all my comments are written in good faith. Dispite me working for a company that bases its solutions on XML, I don’t consider myself God. My remarks may be wrong, and if they are, please explain why. Also, as I am not native English, bits of my advice may seem harsh but that’s only because of my poor vocabulary.
Let me go through some of them and give some hints how I would deal with the issues.
1. There are major inconsistencies in the list numbering area. I mean, handling of various serial data is done differently (and sometimes in a overly complicated way).
XML files are documents which means the order of elements in them is significant. That means we don’t need to specify numbers for things we present in series. But that is valid if we don’t skip any indices, ever. Plus, if we need access to specific indices in the XML at runtime, having an explicit index value is handy.
I’d propose to change all handling of series in a way that ensures these three things:
- for data that is always in the order and always fully specified, skip the indices. Example: Instruments/Instrument/VstiProperties/VstDeviceDoc/OptionalNodes/OptionalNode/ParameterN (where N is the parameter number). Skip the N. If it’s absolutely needed, do it as an attribute (so it can be queries using XPath tools in other software, maybe later you’ll gonna use it yourselves ).
- use attributes for indexing everywhere else (example below)
- for data that is rarely different from the default, assume the default (so when an element is not found in the document, 0 or another reasonable default depending on the context, is taken). Examples: Instruments/Instrument/SplitMap should be empty by default, assuming all Splits be zeroes. A single non-zero Split would be then presented as: Y where X and Y are numbers. Same goes for Tracks/Track/NoteNolumnStates (let’s assume all states as “Active” by default).
2. PatternPool/Patterns/Pattern/Tracks/Track/Lines/Line is raw text. Examples: 44:—…,—…,G#600… or 16:C-40340…. This is wrong because this raw text holds much information that should be available for XML parsers (line numbers, instrument numbers, sample numbers). This is required for XPath querying, for linking notes with the instruments within the document, etc. etc. Moreover, raw text representation is error-prone and not future proof.
I’d rather do elements like this: C-4. Some explanation: ‘id’ is the line number. As you can see, comment 1 also applies here. ‘col’ is the column number within the track (no need for —…,). ‘instr’, ‘sample’ are self-explanatory but notice that the presence of these attributes lets you join the information from a line with the instrument/sample within the document, without any other processing. Even though there is no explicit Instrument numbering in the format, XPath and other tools let you query for “the first” Instrument in the document, “the third” sample in the Instrument, etc. ‘pan’ is open for discussion. We could do 0% = totally LEFT, 100% = totally RIGHT. Or something else. You can think about surround panning (will Renoise still be stereophonic in 5 years? We don’t know ). ‘vol’ is self-explanatory.
Obviously, if you skip an attribute within the element, a default value is assumed. If you think that this approach would lead to bigger files, I can assure you that is hardly the case. Zip compression handles redundant text blocks very well. And the advantage of having proper data partition is big.
3. In XML it is usually considered a design defect if copious empty data structures must be presented to maintain document validity. It is often said that XML is used to present data, not the lack of it. So, using indexing on elements, you could rid of the empty PatternPool/Patterns/Pattern/Tracks/Track structures.
1. Why the complexity of VSTi information? I mean the path to parameters is: Instrument/VstiProperties/VstDeviceDoc/OptionalNodes/OptionalNode/
2. Why are all atomic data presented as text in the nodes? For instance 0 could be just . That’s usually easier to parse. But this one’s really a thing of preference. The important thing is to keep this consistent whithin all document. When we present atomic data as text, we do so everywhere (and you seem so, that’s good).
3. What are Parameter Chunks for and can’t they be presented in another way than binary?
4. Isn’t Tracks/Track/NoteNolumnStates a typo? I mean “Nolumn”?
I didn’t test the format very much (I downloaded RNS1.8 only a couple of hours ago) and in general it looks very promising. If you noticed any other issues or have other questions, add them here.