-
Notifications
You must be signed in to change notification settings - Fork 28
Description
Currently there is quite a bit of "junk" information required in the dawproject xml to make it work in mainly Bitwig and Cubase, while Studio One seems to have the strongest dawproject interpreter:
-
Getting rid of most unneccessary ids. These are conceptually only required for nodes which need to be linked to each other, e.g. parameters. But all the other ids certainly are only required due to the xml interpreters used in Bitwig and Cubase, and also are explicitly marked as not required, though Bitwig will fail to import without all the dummy ids.
-
Lanes in Lanes in Lanes in Lanes... Ok, but seems to me a bit overcomplicating things? I would suggest that the format such really only represent the required data and structure in the context itself, not thinking in daw's structures at all.
-
Mixing child node types, and then many of each might break some table, object structures (and might not be part of normal xml spec?). Like:
<Devices><Vst3Plugin /><Vst3Plugin /><Vst2Plugin /><SomeOtherPlugin /><SomeOtherPlugin /></Devices>
will easily at least break the order of the children in a lot of common data structures. Better would be:
<Devices><Plugin type="vst3" /><Plugin type="vst3" /><Plugin type="vst2" /><Plugin type="other" />...
-
Channel nodes seem to be redundant data mostly, most might be moved into the parent track container instead. Is there any scenario where multiple channel nodes are inside a track? Should these infos part of the song data?
-
Track's contentType attribute is somewhat confusing and handled slightly different by each daw. Proper docs required here. Feels like a workaround.
-
Master is not the parent container? Ok then on which position should it be placed then (last one)? Is that obligatory? Should that be written iinto the documentation? Would there be a scenario with multiple masters?
-
Same for send tracks. Also could be inside Master parent container.
Thanks for consideration! Keep up the great work.