Comment by stevefolta | Hacker News Reader

Comment by stevefolta | Hacker News Reader

Parent Full thread

> Using git itself is a little problematic because it is very line-oriented and most project file formats for DAWs are not.

Ardour and Reaper use plaintext project formats that work well with Git, at least for basic versioning.

> Regarding plugins, I know that I'm not the only lead developer of a DAW who, if they possibly could, would refuse to support plugins entirely. The problem is that most users want more functionality than a DAW itself could feasibly provide (they also sometimes like to use the same functionality (plugin) in different DAWs or different workflows).

I think the answer to this would be something like Reaper's "JS" plugins, which are written in a small compiled language and distributed as source code. Compared to "JS", it would need to: 1) be open source; 2) be a better language; and 3) support pretty skeuomorphic graphics ('cause people seem to really want that in their plugins). Ardour seems to be working on something like this using Lua (don't know about the graphics, or if the plugins could be supported in other DAWs).

Ardour uses XML for its session format, which is not a line-oriented format. Git can handle it, most of the time, but is not ideal. Something that groks the concept of XML nodes would do a better job (i.e. less conflicts duing merge resolution).

Ardour comes with a small set of basic "curated" plugins written in C or C++, that are "blessed" by us. Writing DSP plugins in Lua is also possible, but generally discouraged and, as you guessed, you can't provide a dedicated GUI for them, nor can they be used elsewhere (same limitation as Reaper's Jesusonic plugins).

However, even if those details were improved, the idea that a DAW manufacturer is going to be able to supply the precise EQ that demanding users want, let alone noise reduction, polyphonic pitch correction, and so, so much more, strikes me as unrealistc.

Note that git's diffs and merges are customisable. If somebody wants to put in the effort for a particular format, they can write tools that perform these two specific tasks and git can be told "Here are the tools for this repo" and deliver the benefits of improved tooling. It's definitely possible that could be worth doing for a DAW if used with git.

Git even understands that it's possible that you can neatly summarise a change in text (for display e.g. as part of the change log) but that summary is not actionable (so the data stored to implement that change is different), e.g. I believe git's man pages provide an example showing how you can get EXIF from a JPEG so that your git tools say the change was from "Photo of Pam and mummy" to "Cropped image of Pam" when actually it's a huge binary data change that is unintelligible to reader.

I mean, If git's been around for ages by now, and this doesn't exist for even json + xml already and robustly, there must be some sort of problem?

The tools don't preserve the literal contents of the file; only the JSON / XML semantics. This makes them unpopular. (Source: I decided not to use them because of this; I needed hashes to remain stable for some reason I can't quite recall.)

The problem is quite simple: if it isn't supported by the base installation it might as well not exist. Github/Gitlab is how most companies and people now experience git, and afaik you can't add those custom plug-ins to those platforms easily if at all.

> you can't provide a dedicated GUI for them

You could expose enough GTK bits to expose an event loop to the LGI lua library. It's gobject-introspection for Lua. Since you already use these libs, it would not make Ardour any bigger.

I am not saying it's a great idea to mix GUI and a realtime DSP in the same thread, but it would be supported in you see some demand there.

I've previously written a long-ish article about the role of Lua/scripting in general in the context of a libre & open-source DAW before:

https://discourse.ardour.org/t/is-open-source-a-diversion-fr...

There's really no technological reason for not allowing Lua to create GUIs within Ardour. It's more a question of whether or not we actually want to. Either way, you would not be mixing GUI and realtime code - the architecture of Ardour doesn't allow that.

Nice article Paul. It is motivating me to take another look at Ardour. I have also worked on some very large audio/video authoring tools. When we made the new lighting tools at Dreamworks, you could only create the UI using the scripting system. I am not sure if that discipline is still observed, but it was a good way to make sure that there wasn't a 2nd class citizen status given to extending the UI.

Thanks. Thing is, in an open source system, there are no 2nd class citizens caused by the "eat your own dogfood" rules (or lack thereof). You want to change the GUI in Ardour? The code is all right there.

The question I was raising (which I think you understand) is whether most users care that this is possible if it can't be done without a rebuild (compiling).

Right. In the case of the studio tools, artists could extend the application but not touch the core. Much like Ardour, having to build the application from source was more complex and who wants to make their users do that?

I've been reading all of your comments in this thread and the links provided carefully, thank you for all the great work on Ardour and the degree of forethought that goes into it, it really shows in the final product.

Just use DVC for any non-line-oriented files. If you don't want cloud backing stores, it's pretty easy to set up using the "local remote" pointing to a custom path (e.g. External drive) if you are the only person working on it. Otherwise I'd recommend symlinks.

www.dvc.org

Reply on news.ycombinator.com