Live data from Hacker News

DAWproject: Open exchange format for DAWs

github.com

61–70 of 93 posts

Re: DAWproject: Open exchange format for DAWs

#61
post #42

Earlier quoted context omitted.

Why would they want to support AU? The only reason to use AU is Logic. Everything else (Protools excepted) supports VST, and all the plugin devs release in VST and AU, so it would be a waste of time. Bitwig is putting their time into CLAP, and for good reason. It's cross-platform, much easier to develop against, and much more advanced that all the alternatives. Even Avid has shown interest in CLAP. So has Image Line.…

For starters, AUs are "easier" to run under Roestta than VSTs since AUs run out-of-process by default. This means you can use a x86_64 AU without running the entire DAW under Rosetta on Apple Silicon.

It hadn’t occurred to me that AU run out of process, but this makes sense. Does this mean an AU crashing in theory won’t take down your DAW? (The same thing that Bitwig has it’s own isolation feature for)

I always default to AU just because I’m on a Mac and I arbitrarily decided to do so long ago. The Rosetta thing has been a nice bonus. Not sure what the other (dis)advantages are, these days I try to focus on using native Ableton and M4L stuff anyway!

Re: DAWproject: Open exchange format for DAWs

#62
post #2

Nice idea, but not useful unless each DAW manufacturer supports the format. And there are a lot of DAWs.

MIDI was enthusiastically supported by Yamaha and Roland, two of the biggest synth players of that era. So I imagine, for it to become widely successful, that this new standard would need the wholehearted support of at least 2 of Steinberg, Apple, Ableton, and Avid.

Indeed, MIDI 1.0 is one of the oldest implemented standards in existence. Unfortunately, MIDI 2.0 is not as successful. Let's hope Bitwig's initiative takes off.

Re: DAWproject: Open exchange format for DAWs

#63
post #3

XML, why? And... 99% of the issues will be around plug-in management.

Probably a relic of the musicxml format which still holds some popularity in programs based around sheet music/western notation

On the subject of MusicXML, there is currently ongoing work to develop a successor (currently named MNX): https://w3c.github.io/mnx/docs/

Re: DAWproject: Open exchange format for DAWs

#64
post #42

Earlier quoted context omitted.

Why would they want to support AU? The only reason to use AU is Logic. Everything else (Protools excepted) supports VST, and all the plugin devs release in VST and AU, so it would be a waste of time. Bitwig is putting their time into CLAP, and for good reason. It's cross-platform, much easier to develop against, and much more advanced that all the alternatives. Even Avid has shown interest in CLAP. So has Image Line.…

For starters, AUs are "easier" to run under Roestta than VSTs since AUs run out-of-process by default. This means you can use a x86_64 AU without running the entire DAW under Rosetta on Apple Silicon.

bitwig already does this with vsts because plugins are sandboxed

Re: DAWproject: Open exchange format for DAWs

#65

I found it interesting to discover that an Ableton Live project file is a gzipped xml file as well, so you can get at the xml by gunzipping it. I've played around with trying to generate a schema file from a project file with mixed results. I very much wish Ableton would support this format or at least publish their schema somewhere so translation could be done.

This. I've been trying to write a VCS for Ableton projects but their schema is way too complex to try to make sense of it.

Ableton is incredibly hostile to third party devs building upon their work. Eg: There is no official documentation for any of their Python APIs.

Re: DAWproject: Open exchange format for DAWs

#66
post #65

I found it interesting to discover that an Ableton Live project file is a gzipped xml file as well, so you can get at the xml by gunzipping it. I've played around with trying to generate a schema file from a project file with mixed results. I very much wish Ableton would support this format or at least publish their schema somewhere so translation could be done.

This. I've been trying to write a VCS for Ableton projects but their schema is way too complex to try to make sense of it. Ableton is incredibly hostile to third party devs building upon their work. Eg: There is no official documentation for any of their Python APIs.

Although the python API could be documented, it was not meant to be a public API. And it seems the open source community managed to generate the documentation.

I don't know any other DAW that allows as deep integration for third party devs through their Max for Live API.

Re: DAWproject: Open exchange format for DAWs

#67
post #9

Bitwig is quickly becoming my favorite DAW. Big fan of how they develop software.

And a very cool project of what can be done in Java based desktop software.

Yes it has has C++ under the hood, which is also a good example of how not to go full into a single stack, rather mix-and-match.

Re: DAWproject: Open exchange format for DAWs

#68
post #58
post #33

Earlier quoted context omitted.

MPE exists, and can handle microtuning of pitch. MIDI 2.0 supports per-note pitch bend. Old multitimbral MIDI synths can be used in an MPE-like fashion by using the one-note-per-channel and pitch bend trick. Modular synthesizers (and virtual modular synthesizers like VCVRack) use control voltage directly, which has no built-in assumptions about how or if the voltages are quantized. Microtonal music, or even just plai…

Idunno, half the instrument VSTs I have seem to support some form of microtuning or alternate tunings...

How do they achieve that?

Re: DAWproject: Open exchange format for DAWs

#69
post #43

Earlier quoted context omitted.

I mean, you could, but that would get really gross when implementing certain scales that are nowhere similar to the MIDI tuning (like working out the fractions for a 13-note scale)

Eh, it's fine. With two decimal points of precision you're basically working in cents, which is a pretty standard way of representing tuning. This doesn't need to be a trivially human-readable format, but I think maybe it would be nice to allow for multiple pitch representations: floating point frequency, floating point fractions of a semitone in any arbitrary EDO, fractional frequency as used in just intonation, etc…

Isn't the issue that pitch bends in midi apply to every sound on that channel, so if you play a chord with a different temperament and send the bend data of each note the result is that the whole chord will be tempered as normal but with every note the same amount higher or lower?

I've heard the recent midi 2 can get around this but it's still a pain with the 40 years of midi equipment that surrounds us.

Post reply on HN