I think the emphasis on users modifying the source is a complete red herring for a tool like Ardour. At a minimum, you need to buy into the unix philosophy if you want your users to do that, and that means writing your programme to be small: to do one thing only, with the expectation that it will be used as a replaceable component in a much larger system. A DAW is not that.
Nevertheless, I’m running Ardour primarily because it is licensed under the GPL, and not because I want to modify it.
Here’s a short list of things I don’t want to care about:
hardware dongles that brick my DAW when they get broken or lost,
phone-home tech that bricks my DAW when the vendor goes out of business,
plugins I can no longer use because the vendor just stopped supporting them,
a DAW I can no longer use because eMagic got purchased by Apple,
hardware lock-in (see the previous point).
I already have plenty of unfinished projects or ideas that I will never see again because they were made with proprietary software. I know full well that I’ll lose a bunch more projects when my Mac finally packs up.
The only thing that guarantees against all those things for a user is the GPL, and that turns out to be a big deal for me.
This is not really true. There are a lot of things like math error fixes where any experience with some programing (even BASIC) will work.
Typing ./waf is 4 more keystrokes to be sure and I would think making sure the needed libs are available would be true for any language that interacts with the system. However, I think setting up a Linux box (or partition) may be a barrier for some people (in the same way setting up a windows or mac box would be a barrier for me)
All that aside, I think one of the biggest blocks for anyone is the size of the project. Fixing a math bug as listed above in any language first requires finding the file where that code is. Sometimes just ask works well, other times… learning grep is better. Aside from just being able to compile, one does need to know git and how to create a pr but that should be the same as many other projects. So the number of people who know c++ and the tools used to add a new feature is really small. Making a small fix, a few more people can do that. The other 99%, not so much. However, looking at the roots of the project, there was a time when most users could build the sw (when I first used Linux building the kernel for my hw was required for each update). So the number of people who could contribute was probably closer to 50% which made open source a much bigger thing for “make your own changes”. As with all things, as it became more useful, the number of people who understand the magic inside the box has grown smaller.
So, " Is Open Source a diversion from what users really want?" No. Ardour in it’s current form simply would not exist without open source. So in the same way that the average android user does not care in anyway shape or form that the kernel in that phone is open source (or started out that way), they would all using iPhones and wince phones without that open source beginning. So while many people may not care if Ardour is open source or closed, they do care that Ardour does exist and if they are comparing it to Reaper… it would seem they are using Ardour even with access to Reaper… I guess open source worked even if the result for most people is a magic box that does the things they find useful.
Indeed. There is a surprisingly large number of drive-by code contributions, some via github pull-request, others directly on tracker.ardour.org with varying degree of complexity.
There is a MSVC project for Ardour that builds the same way. However the problem is getting all dependent libraries for Windows.
On Mac one can use homebrew, or a similar scripted solutions. GNU/Linux most distros make it easy to get built dependencies, same on *BSD. It would be great to find a solution for windows, too.
Chocolatey is the closest I know of, but don’t know if it can be used to make a build environment in the same way, but may be worth looking at.
Honestly though I use[d] Ansible scripts when I was doing this for software builds previously (ffmpeg for instance) as I wrote them to create the build environment and then build the software, though I never tested them on Windows there shouldn’t be any reason they wouldn’t work.
Ardour’s code is quite modular which in away allows you do treat it as lots of individual programs that do specific things. So the few times I’ve tinkered with the code I’ve been able to dip in and out of the relevant parts fairly easily without needed to know much about the larger picture.
That’s true of any active large code base, but there’s still more code to navigate, more code to compile, more dependencies to install, and so on.
I had a look at investigating a problem with Ardour just the other week but here’s the laundry list of dependencies I would need to find and install before I can compile the software Ardour - Nightly Builds, and here are the build instructions to accompany them: ardour - the digital audio workstation.
Well of course you have to be able to compile it to test out your changes. Since I do a lot of compiling anyway I didn’t find installing the extra dependencies too much of a hassle, it’s all part of the process.
Right, but that’s kind of the point: you do a lot of compiling anyway.
I mean it’s clear from Ardour’s own documentation that even the Ardour devs don’t want to have to deal with the hassle of compiling on macOS, and they’re actual programmers who know what they’re doing. So what chance is your average music producer who wrote a website once going to have?
@paul’s original question was something like, is the ability to edit the source code really such a useful feature for end users? I think it is because it brought Harrison Mixbus to the market, which is at least useful enough to be worth the money its users spent on it, but I don’t think that’s what he meant.
I think what he meant was, why is Reaper’s lesser scripting feature so much more valued by its users than the superior option we provide them with? And the answer is probably that the lesser feature has a low enough barrier to entry as to actually be useful, whereas the superior option doesn’t.
A few days ago Microsoft released Windows Package Manager 1.0. Relevantly the tool includes an import option, which allows it to read a JSON formatted collection of packages (and install them) where you can describe 3rd party sources. It is available on github, which I’ve included a link to, as well as on their “App Store”. I use GNU/Linux so I can’t really help out much here if someone wants to use this.
Notably there is also WSL, or the Windows Subsystem for Linux, which does provide an integrated Linux environment quite well from what I’ve heard but I don’t really have much experience with it. Still, I think that could be an avenue for Windows users who want to contribute without having to go through the process of booting into a different environment to do it.
FWIW there’s an old thread here from someone else who wanted to get involved:-
To give him his credit, the OP spent months giving MSVC a try but eventually gave up. It might be worthwhile to post there and ask if he’ll describe his experiences - but as Robin said earlier, I think it was mostly due to problems compiling the support libs. I’m someone who does build Ardour with MSVC and I can confirm that Ardour itself is the easy bit. The support libs tend to have little or no support for building with MSVC any more
I think the real solution right now is to just not build with MSVC, there are ways around this that seem like they would be much less painful to deal with, even if you do have to learn to work with a different environment. Microsoft has had a very long time to deal with this growing problem of dying support for MSVC. Their “we <3 open source” initiative and native tools like wpm (which is not a replacement for a good build system) are a step in the right direction. Then again, it also looks like their actual solution to this problem might be slapping a GNU/Linux VM on top of Windows with some convenience features (WSL) and calling it a day. Take it for what you will, but I personally think anyone on Windows who wants to contribute would be better off using WSL, or MinGW.
Many years ago there was a third party project which aimed to distribute a full ‘dev’ version of the GTK+ stack for MSVC (i.e. pre-built binaries + header files). But back in those days,there was little compatibility between different MSVC versions - so if their stack was built with (say) VS2013, you couldn’t use it with any other version. But IIRC Microsoft itself became interested and improved the compatibility between different MSVC versions. Unfortunately, I can’t remember what the project was called - and I can’t remember if it offered GTK+2 libs or only GTK+3 Can anyone else remember this? I’m sure I didn’t imagine it.!
I found the project here - the good news is that the pre-built bundle supports GTK+ ver 2. The bad news is that it only goes as far as GTK itself. So there’s no support for atkmm / gtkmm etc. And of course it won’t include libraries which GTK itself doesn’t need - such as libsamplerate / vamp / serd / sratom etc.
Forgive me if I respond before reading all the responses. It seems to me that this post isn’t really about either Open Source or users. As a user, I wouldn’t use it if it wasn’t not only Open Source, but actually DFSG compliant. End of, I run Debian exclusively and have done for 20 years.
This seems to be about extending Ardour through scripting; what I would describe as ‘softcode’. Mostly you’re talking about Lua and Python, my two favourite scripting languages, because I’m one of the generation you’re talking about. Both of them are Open Source. You seem to have just said that “all this” isn’t possible through scripting as a result of your and Robin’s joint intention. I don’t really understand how it being Open Source is the problem here. That’s partly because I’m not a ‘real’ (i.e. C) programmer and partly because I’m a FOSS fanboy
I’m an occasional Ardour user but use other DAWs for my work. In the past I studied music (university level) then music technology, got into programming and have worked as a C/C++ programmer. More recently I’ve returned to the world of audio production working primarily as an audio editor.
A few years back I was interested in contributing to Ardour and went as far as trying to get a build working. This was on OS X (now macOS). To build the software was very time-consuming, in particular (as has been mentioned) building all the libraries especially GTK. I recall the build instructions starting with something like “Do you really want to do this?”! In the end I gave up because I didn’t have the time to devote to it. I just checked the link to the source code. Below the link is the following:
You’ll need to build this yourself. That can be a challenging and complex process, especially on Windows and macOS. We don’t provide help for this process, and we can’t support the end result. But if you’re hoping to modify Ardour or get involved in our development process, this is where to start.
If there’s no help and no support why would anyone spend their time on such a task?
Also, even if someone succeeds in building Ardour, what is the documentation like? Most OS projects (or ones that I’ve seen at least) have next to no documentation. If something were to happen to the lead developers the project would die a quick death. But without documentation it’s almost impossible for anyone to understand how a codebase like Ardour’s works. Now I haven’t checked Ardour’s documentation, but if it’s like other OS projects then it’s likely to be a major hindrance to new contributors to the project.
And just a bit more about the complexity of the build:
Ardour developers in general do not provide assistance with this task, so please don’t ask us for help.
Building GTK+ (the graphical toolkit we use) from source is a monumental task and can require a lot of other libraries to be built and installed along the way. This is particularly true on OS X, where many of GTK’s own dependencies are not easily (or correctly) available.
We don’t have the resources to make building the dependency stack simpler. Every once in a while, someone shows up with a promise/offer to e.g. build a Docker image. But it never happens. We’d rather work on features and bug fixes, and think that’s a better result for users. We could be wrong about that.
If there’s no help and no support why would anyone spend their time on such a task?
If there’s no help or support, why would anyone ever sit down to write a DAW? Intrinsic motivation is the main answer to both questions, IMO. If you plan to use a system running macOS to try to do development work on Ardour, I would assume that you have some fondness for macOS that makes it worth dealing with the issues the platform puts in your way. If that’s not the case, I’m not sure why you’d choose to do this.
We also can’t change the fact that neither Apple nor Microsoft have any declared or apparent interest in cross-platform development. The tools for doing this will always be “foreign” to both platforms - that’s just a cost of wanting/needing to do cross-platform stuff. The Apple-native and/or MS-native tools might be very nice, but you can’t use them in any meaningful sense to do work across platforms.
That’s fair enough and I completely understand. But I don’t think you can have it both ways. If you want to encourage new developers to join the project then the “price of admission” needs to be lower. I imagine most developers interested in contributing would only have a limited amount of time to dedicate to the project, say, a few hours a week. If they can’t get a build happening in that time then why would they stay? I was interested in doing this on a Mac because that’s what I was familiar with and had available. But from what I can see, support for a Linux build is similar:
We do not provide support for building from source. We do not make regular efforts to keep this page up to date. Please do not ask for help with this process.
To me, that’s a bit disheartening!
Now I’m not here to lecture anyone about how to run a project. I actually think Ardour is an amazing achievement. I do think though, that having a large and diverse group of people actively developing the project is “a good thing”. Because at some point the current developers will have to move on. What happens then?
