Skip to main content

dawproject

Posted

Hi Andre

How about implementing export to .dawproject format, which is the new open source DAW exchange format from Presonus covering StudioOne and Bitwig for now https://www.soundonsound.com/news/bitwig-and-presonus-new-dawproject-format

https://github.com/bitwig/dawproject?tab=readme-ov-file

Looks like it would be really easy to simply extend the musicxml export to cover this format, just adding in the CC data and perhaps in time containerisation.

I wrote a script to convert your musicxml export format to .dawproject xml in about 5 mins using AI, but it of course it doesn’t include CC data.


Mon, 2024-05-06 - 17:42 Permalink

We've had that recently. Yes, interesting. It would be even more interesting if more DAWs supported it. As an export-only format that would be easy to implement.

That AI generated script actually works? My experience with coding assistants is not so positive.

Mon, 2024-05-06 - 17:55 Permalink

Snippets could be exported as "Clips", albeit that would turn them into static notes.

My initial expectation was, hey, this might take only a day to implement, but a first look into the XML specs is a bit sobering. Clearly XML is not their primary domain of expertise. We should hope that this doesn't impede its adoption. Steinberg is known to be hands-on and pragmatic (their specs are sometimes unorthodox as well), but my guess is that Apple won't implement any of it, unless there is real market pressure.

In short: If we implement this, it will take some trial and error due to lack of specifics (i.e. not anytime soon).

Mon, 2024-05-06 - 19:54 Permalink

The implementation is quite simple actually because you can start with the basics and add more features later. For example you could just implement trackname, notes, CC and channel, and the importer in Studio One and Bitwig would use that info and nothing else. You don’t need to implement all the xml. Using a decent AI makes this quite easy as it can write the script and it’s easy to debug.

Tue, 2024-05-07 - 09:46 Permalink

This is more involved than scripting XML. AI can't help much either.

The devil is in the details. How to deal with notes that overlap a region (container). Dealing with devices (plug-ins) that serve multiple instruments. Translating from custom controllers to automation lanes, articulations to expression maps, etc. The specs lack any prose about this, so you have to find out by trial and error. Straightforward but time consuming.

The main benefit of this format is that plug-ins and their setup are preserved. And that containers somehow translate to MIDI regions, preserving the names, colors, comments, maybe even the nesting (if that's supported by a DAW). The prospect of seeing your Synfire project imported into a DAW with most of its structure and appearance retained -- ready to play -- that really convinced me to add this to the todo list.

 

Fri, 2024-05-10 - 19:29 Permalink

Managed a build a decent .dawproject converter based on .mid files exported from Synfire. It sets all the vst3 plugins for each track as Vienna Ensemble Pro Event. 

However, what’s stumped me is how to export the .vstpreset data from Synfire.

EDIT: If I can get this working with track channels and vstpresets, then I’ll upload the whole code to Github for anyone to use.

Sat, 2024-05-11 - 17:33 Permalink

Cool. I'm curious to see how you did that. Getting MIDI over to the DAW is not actually hard though. 

Preserving VST preset data and all Master, Aux, send/insert FX modules is the main reason to implement this format (parts of the global rack also need to be exported). Such that your project sounds 100% the same from the start.

I started an implementation as a test, but the details and debugging with actual DAWs make this a project of more than a few days. We currently have not enough capacity, but it's now high on the list. If it works as advertised it's a game changer, at least for Studio One and Bitwig users for now.

Sat, 2024-05-11 - 20:14 Permalink

Yes, getting midi over to Studio One is simply a case of drag and dropping the .mid file LOL!

It's when implementing the VST3 plugins that it starts to become helpful. But I can't seem to set track midi channel in Studio One, and there seems absolutely no way to programmatically get plugin data out of Synfire without using drones.

EDIT: Here is the github repository for the code: (https://github.com/ruchirlives/dawproject)

Here is the structure of the code in case it helps:

Here's an annotated outline of the code, with personal folder locations removed:

I. Import necessary libraries
  A. lxml for XML processing
  B. midifunctions for MIDI file processing
  C. zipfile for creating ZIP archives
  D. os for file and directory operations
  E. vstanalyser for modifying VST3 preset files

II. Define global variables
  A. deviceID for the Vienna Ensemble Pro Event VST3 plugin

III. Function: process_musicxml(musicxml_file)
  A. Parse the MusicXML file
  B. Create a list of devices for parts in the MusicXML
     1. Extract part ID, part name, device, and channel information
  C. Create a list of tracks for parts in the MusicXML
     1. Extract part name, device, and channel information
  D. Return the list of tracks

IV. Function: create_project_file(miditracks)
  A. Create the root element for the new XML
  B. Create the Application element
  C. Create the Structure element
     1. Iterate over the MIDI tracks
        a. Extract metadata (track name, channel, instrument name)
        b. Create Track, Channel, Devices, and Vst3Plugin elements
        c. Create the State element for the VST3 plugin
  D. Create the Arrangement element
     1. Create Lanes elements for each MIDI track
        a. Create Clips elements
        b. Create Notes elements and populate with note information
        c. Extract and create Points elements for CC messages
  E. Return the project XML

V. Function: extract_cc_messages_lists(messages)
  A. Extract CC messages from the MIDI messages
  B. Group CC messages by controller number
  C. Return a list of CC message lists

VI. Function: validate(projectxmlfile)
  A. Create an XML schema validator using the XSD schema
  B. Validate the project XML against the XSD schema
  C. Print validation results

VII. Function: create_dawproject_archive(project, name)
  A. Save the project XML file
  B. Create the plugin folder
  C. Create a ZIP archive (.dawproject file)
     1. Add the project XML file to the archive
     2. Add the plugin folder and its contents to the archive
  D. Return the paths of the XML file and .dawproject file

VIII. Function: create_plugin_folder(midi_file)
  A. Create a folder for the VST3 plugin
  B. Iterate over tracks in the MIDI file
     1. Create a VST3 preset file for each track
     2. Save the preset file in the plugin folder
  C. Return the plugin folder path

IX. Function: convert(midi_file)
  A. Load the MIDI file
  B. Extract the name from the file path
  C. Create the project XML using create_project_file()
  D. Create the .dawproject archive using create_dawproject_archive()
  E. Validate the project XML using validate()

Sat, 2024-05-11 - 23:09 Permalink

Also cockos reaper users, as they already have a dawproject converter implemented. So for now, studio one, bitwig and reaper.

Sun, 2024-05-12 - 03:48 Permalink

Major props to both Andre and Ruchir! You guys are doing God's work. To be honest, I'm surprised that more of the major DAWs have not implemented the dawproject protocol (except maybe Reason Studios, where they seem to be allergic to cooperating anything outside of Reason). If/when you are able to get this up and working, it will be a significant boost to the Synfire workflow.