.dawproject songfile format

Ideas & suggestions
1

Please have a read here, I think this is a great idea and would make audio world a better place:

Also:

1 Like
2

offtopic: so, you are Hanz Meyzer :stuck_out_tongue:

3

I am the worst nightmare for any DAW dev :joy: I am always suggesting that the DAWs should be like Renoise and earn a lot of positive resonance, when suggesting a tracker view.

1 Like
4

For me personally - that would be so awesome! i would love to see redux as some rack extension/native integration in Reason. That would be so much awesome… possibility to program Reason midi/clips in tracker way… maaan :smiley: or in Bitwig…

1 Like
5

It is quite saddening that I’m unable to work on any of my files saved in my previous tracker Madtracker 2.
Due to this I feel quite wary about saving anything in Renoise format or anything other than .xm or .it

6

There’s been some interesting developments around this so wanted to bump it.

Multiple DAWs are already supported now by DAWproject and it can solve a lot of headaches like having moved samples (export and fix paths to samples etc.) and also cases where now people might load Renoise as a VST in another DAW (maybe i am the only one…) and for instance forget-to-save-the-renoise-project as it doesn’t get saved with the Ctrl+S habits.

Is there any hope for an export from Renoise to this DAWProject XML format? It hink it would be an amazing thing and in my mind though a bit tedious maybe not the most complicated feature to implement.

3 Likes
7

As both are structured data in plain text, could this not be done with a common script?

1 Like
8

I will make an attempt and report back my struggles and pains - and maybe some kind of script :'). Good suggestion, and sorry for not catching that obvious idea myself! Thanks!

1 Like
9

Perhaps host your progress in GitHub so anyone can chime in and contribute should they want to. Also, you could make a thread on this forum for discussing the development of the script if you’re attempting it.

10

FYI this xml2lua lib seems to fullfil all requirements:

It supports xml string to lua table, table to xml string and also attributes, and can be installed without luarocks AFAIK.

11

I can see a lot of elements map kind of 1:1 to dawproject format. There’s a bit of a sketchy:
Chunk
<![CDATA[ <loads of base64 + binary data here>

Kind of deal in the middle of my projects which seem to store parameter or plugin/vsti data.

I’ve found with a base64 decoder i can atleast get it to drop some paths on me of what the thing is for for some of them, others have other formats. it might be the active preset dumped into there, but i’ve yet to be able to confirm it. some have paths to presets or settings but others are just binary data. I’ll see if i can determine it. it will likely not translate so smoothly into something of dawproject as far as I can tell.

i found one referencing a .ens file of a NI plugin, but it was for sure not the contents of that file. who knows :smiley: another NI plugin had just binary stuff in there, yet another had some references to vst dsp names and types but in other places etc. - i don’t think it’s something renoise encodes, but rather dumps. i’'l have to hook up the ol debugger to see where it comes from - will take a lot more time :smiley:

edit9001:
got a little further, it does seem internal plugin or preset state, but decoding is so far unsuccesful :>
copied the cdata into a separate textfile.
ran:
base64 -d < blabla.txt > preset.nmsv
(nmsv is NI massive preset)

it gave me an ouch! but the file does seem very similar to a random other preset i open in texteditor.
gotta sleep :smiley: maybe tomorrow it will make sense when i have energy for a hexeditor.

Imgur: The magic of the Internet ouchie
Imgur: The magic of the Internet file contents in txteditor

12

sleep is for the wicked O_O

the first byte is wrong, or just different… it changes each plugin save and also each renoise dump of that data… At the end of this cdata ‘blob’ there’s like 60 bytes different / more than if i look at same preset saved via massive itself.

I have no clue why it adds these bytes. loading it like this causes Ouchie :frowning: computer says no!

If i delete these extra bytes in the version renoise dumped, the preset does load without Ouchies but it does nothing, no knobs are changed, hence, it’s the actual knob/preset settings which seems to be saved there? This weirds me out ,because the smaller original test.nmsv has not these bytes, but if i load that - the settings are loaded. so who knows :smiley: maybe someone else can weigh in, or i’ll spend more sleepless mondays digging until my alarm tells me i forgot to sleep!

this was a visual diff, maybe some stuff in the middle is different, i’ll have to analyse it properly rather than like a twoyearsold on coffee! :face_with_monocle:

it would be beneficial to find out, as then if anything, we can have a script pull out all those presets for plugins where we’re too lazy to go into project, open all plugins, and select ‘save preset’. :shushing_face: we could dump out track, dsp/vsti information + preset files. maybe its just a dream…

13

Huh I never realized that plugin presets are stored as binary data in xrns. Hopefully someone here could take have a look as well, I’m not good in this kind of stuff.

14

Also keep in mind that you most likely will have to use either the recent beta of Reaper or Bitwig to implement all features, since implementation still seems to be ongoing.