That’s what I love about Open Source: the traditional customer/supplier relationship is not there, and “the customer is always right” doesn’t apply.
Of course, that can lead to bad behaviour, and it has in the past with many Open Source projects. But I don’t see that here.
I actually think Paul treads the line pretty well.
Cheers,
Keith
Robin - something just occurred to me… I know that on Linux, you can build using either gcc or clang but what about Windows? Are you still restricted to mingw or is a clang version also buildable?
AFAIK clang (on Windows) uses the same name-mangling scheme as MSVC, so if a clang support stack was viable, that might be worth investigating…
I have not tried, but the compiler should not make any difference. We also use clang on macOS.
Interesting… is it the same physical compiler for both OS’s? According to the clang website it looks like there are only 2 x versions:- one for Windows and one for what it calls “Unix-like systems”
[Edit…] Apologies - I’d been looking at the build instructions, rather than the downloads. I
eventually found OS binaries here
I usually don’t chime in on discussions like this and make a mob, and Paul can obviously answer and defend himself. But with what Paul has emphasized in several posts here in addition to the OP in mind, it seems to me that you have some kind of alternative perception of what has been said in those posts.
It’s OK to have different opinions, but you really have to step back a little bit and slowly read and try to understand what is being said. To me, it looks like you haven’t read what he has said before and your meanings are quite contrary to these - they also have some conspiracy elements and I can’t see that they are rooted anywhere.
I myself do occasionally let my fingers speak a little bit too fast at the keyboard before the brain or someone else on a forum corrects me, and hate it when I understand what I have done, it’s so embarrassing. I really hope you can reconsider what you wrote here and instead show some gratitude to the developers of the Ardour environment. That you love Krita and their way of making money is ok by me, but that doesn’t make the Ardour way bad. Thanks to the GPL, you can get the source code and binaries gratis from any mainstream Linux distro if you don’t like the Ardour gang and do not want to support them.
I put in my vote to lock this topic 
Please don’t. Let other users read and listen and discuss. That topic is interesting.
Pretty amazing how Tenacity people still backport changes from upstream Audacity then. Well, I guess, the code doesn’t smell
I’d like to take a peek at that imaginary team that will presumably take over Ardour development. They must be mighty ninjas, staying hidden, biding their time.
They really don’t. Which is kinda sad, because it’s a very nice project.
Nooo, it won’t be the same, because binaries by Ardour come with a bunch of Harrison plugins. That’s something you would know if you ever used those builds.
Anyone can ask the team for that ~1GB large tarball with dependencies you need to be able to build the program for Windows. Somehow noone got any further after being offered that. This is ultra suspicious. You’d expect one of them mighty ninjas grabbing that tarball and beginning to distribute copies of Ardour for Windows left and right free of charge. But nope. Well, I guess we can’t have nice things then. Or can we?
The problem here is that Krita actually sells binaries. It’s $14,99 on Microsoft Store and $9.99 on Steam. That’s how they barely break even. For some reason our friend @AlexAlex here thinks that Ardour should follow that model and, I guess, also start barely breaking even instead of staying finanically safe. You’d almost wonder why someone would actively try to get a project run into the ground. But hey, that’s crazy talk, right?
It’s important to avoid using the bogus term “open source” which was specifically designed (thanks Eric!) to mislead and “trick” people into using Free Software while not having to think about the moral and ethical convictions behind the movement. Many of the responses I’ve read in this thread provide clear evidence this confusion has worked quite well. When people talk about “closed” (vs. “open”), or “free vs. commercial”, they reveal themselves to have taken the lazy approach around this subject. As Paul has correctly pointed out, Free Software is only that when the 4 freedoms are present. That said, there really are only 2 categories of software: freedom-restricting (non-free) and freedom-granting (free).
There is no amount of clever wording or imagination that can possibly change this fact… and yet people continue to try.
As someone who many years ago, had his data held hostage in a proprietary DAW’s file format, I can tell you it was one of the important “burns” that resulted in my discovery and eventual appreciation of Free Software. Unfortunately, I do believe people need to be burned (some, many times) in order to appreciate freedom.
For the past 5 years, I’ve been working with Qtractor… not because it has features foo or bar, but because it is Free Software. I looked at Ardour back then but couldn’t deal with the state of MIDI. Now that things have caught up on that side, I’m switching over and happily pay a small monthly subscription.
If Ardour was not free, it would not be installed on my box.
Hi Paul,
I did read through your whole post awhile ago, spent some time thinking about it, and then came back again to reply.
From the above-quoted part it seems to me that you are focused on compiling as an essential make-or-break aspect of whether budding contributors would join the project. I don’t think it is that important at all.
What I see at play here is the freedom to create something functional with as little overhead as possible. Scripting allows for this. Getting into the source and compiling adds a significant amount of hurdle to it. Working for hours and days on a PR only to be rejected by project managers is an even greater hurdle. On the other hand, creating super-low-latency code is impossible without compiling and without a low-level language, such as C/C++/etc. And users & contributors as well love them low latencies.
So basically, we want the ‘core’ part to be stable, efficient, low latency, and capable - but we also want to have the option to extend this core functionality with scripting that can’t disturb these properties. So, just like web developers you mentioned. Web developers need their backend engineers to ensure the system can support all the frontend stuff they are engineering.
But all this doesn’t mean that users don’t care about open source. Indeed, even if I’m currently a lousy programmer, I really love Ardour’s FOSS nature, because it gives me a certain security and peace of mind regarding nefarious actions. But until I become a better programmer, I won’t open Ardour’s code nor compile it (probably). And in general, I am fond of FLOSS - which doesn’t mean I won’t support / purchase closed source software that aligns with my values (e.g. Reaper, BitWig, etc.).
[Now, if you are wondering how do I feel secure (enough) when I can’t review Ardour’s source, the answer is that someone else can, and can sound an alarm should anything fishy be spotted. Not a perfect system, but a lot better than ‘we-are-spying-on-you-and-you-have-no-idea-nor-can-you-refuse-because-this-is-proprietary-blob’]
To come back to the original question: is OSS a diversion from what users want (or not)? Kinda, maybe, can’t say, something in the middle and neither.
All in all, I would suggest following Reaper’s model and allowing for extensive scripting capabilities, while creating limitations in order to retain stability and efficiency. There’s a script for almost anything in Reaper - and I’d love to see the same for Ardour as well.
Hi all,
If I may just add my thought. The only reason why I’ve spent months if not years working on an AAF library, was because there were a GPL licensed audio software called Ardour. I would never have done this for a closed source / non-libre software. Never.
Scripting/API have nothing to do with freedom offered by Free Software. Scripting is just a “feature” which can be pretty interesting and useful for the end user, but it will never be freedom related. Those are definitely two different things.
I would say, people who are in need to use a car are not necessary themselves car builders Regarding Ardour: It’s a tool for doing Audio stuff, creating and recording music and maybe sharing it with the world. If the tool is capable to do it in a fun and enjoyable way, it will have it’s loyal users. I would say, lets focus on the fun then.
Just a few ideas for more fun with Ardour 
Car owners may not want to do auto maintenance / repair themselves, but they have a strong expectation that they can take their vehicles to any variety of techs who can do so for them, without being beholden to the auto manufacturer for whatever support they deign to provide. Buying proprietary software without the right to repair it (including the right to rebuild from the source code) is like buying a car with the hood welded shut (or better, locked down with a key that belongs only to the manufacturer).
There are car owners who never take their car to anybody but the “factory authorized” dealer for maintenance and repair, but they are far from a majority, AFAIK.
True. But if you are a car owner you mostly have the expectation to use the car for the purpose of transportation. Regarding Ardour, the expectation is to use it to make Music, being creative and have fun with it while doing it.
Regarding customization.
Even with Ardour being Open Source, you can’t do anything 99% of the time. It’s the same Situation as if a Police Cop has access to the Blueprint of the car but no engineering skills. You might understand a few words and numbers but you can’t modify or re-design your car in a substantial manner.
And to make things worse regarding Ardour’s blueprints (the Source code). It’s not enough to know the C and C++ Programming Language and to know how use the programming tools. You also need a lot of experience and detail knowledge about the multiple Operating Systems, API usage, Data structures, how to use a version control system like git and a gazillion other things.
Plus: It doesn’t help if you used the C and C++ Programming languages in the past for developing a accounting Software but now you want to work for Nasa using your Programming skills for programming Rockets^^
I’m not sure why any of this is particularly relevant for most users. For all users there is an installer available that is no more difficult or complex to use than downloading and installing any other piece of software.
On the other hand, because it is open source, if a user does want to get involved in the development in some way, they do have that option, which they do not on closed-source software.
“Getting involved” could be using their own skills (and, yes, there’s a learning curve) or hiring a developer to make those changes for them. In the same way that, with the car analogy, a car owner can always hire an independent mechanic to do modifications to their car.
But the bottom line is:
The number of users who have to understand how to program or even how to compile/build in order to use Ardour is exactly zero!
I would also argue that all of the above have been achieved to one degree or another.
The trickiest one is “Easy and intuitive to use” because there is always a learning curve and a minimum level of knowledge required to use a DAW (any DAW, whether it’s Ardour, Logic, Bitwig, Reaper, Ableton) which is why there are, typically, lots of Youtuber’s providing tutorials on these things.
My personal view is that having a baseline set of tutorials to support the product is an essential capability, and that these tutorials need to be kept up to date with the latest product releases.
Part of the problem is that the things that many users struggle with are often things that are outside the scope of Ardour itself, such as audio interface and driver installation.
There’s also a whole load of basic concepts, like channel-strips, plugins, MIDI, and capabilities like EQ and compression that, typically, need to be understood before trying to use a DAW in anger (any DAW, not just Ardour).
DAWs are, by nature, complex beasts because they are designed to support a set of complex tasks. Video editing software is similarly complex.
I often see people struggling with DAWs (more often than not, with DAWs other than Ardour) because they’ve decided they want to do some recording, and have jumped into the deep-end without learning some basics first.
I’m not sure what can be done about that other than providing support and pointing them at the appropriate tutorials and other resources.
Cheers,
Keith
Yeah, DAW’s are tending to be complex but i ask myself sometimes - Is this really necessary?
Talking about intuitive and easy to use. I read a few years ago that Apple in it’s early years targeted mostly unskilled, non-technical People bc they knew from the start these are the customer with the money and will buy the product if it’s easy to use. So not Programmer or Technicians where the main Focus, but Teachers, Artist’s Lawyers, Musicians, Designers etc.
So they invented the Human interface Guidelines, consulting Psychologists and Expert’s in the field of Human/Machine interfacing best practices (how do people react to symbols and Dialogboxes, delays, disturbances, layers, abstractions etc). The Result was a Manual (HIG) which forbids for example recursive dialog boxes with more then 1 popup level bc people tend to get lost (and disturbed all the times: Telephone rings, Smartphone beeps, cat meows etc).
The main goal was to structure the GUI in way, so you are always aware where you at and what you was doing before you got disturbed. This also means you have to present a clean and structured interface, without ambiguities and not to many options to reduce the confusion level to a minimum, but also not fall short on customization options. It’s more the question “how to present” it.
Regarding Ardour:
I started a long time ago with Cubase and it is a Monster (even the light versions). But i also noticed i really don’t need all the gazillion features but there where say 10 up to 20 features i constantly use.
And i noticed that i really don’t like most of the Upgrades (if Cubase or another Software package). Bc speaking of Cubase, they tend to hide basic controls like locators/markers and Tempo control’s and highlighted unimportant stuff bc they want to sell you something and deprecating features or compatibility to older Project file format etc). This is one of the reasons i use Ardour now.
Now, if i compose a song, i have the Ardour Source code and the PlugIns and all my Soundset are at the same place. I know it will work in a few years - not like Cubase, which will not activate over the Internet bc. the activation server has ben shutdown or your changed PC Hardware components and you have to re-activate the Software but it doesn’t activate anymore. etc.
Apple’s HIG has never applied to its own “pro” creativity software (they don’t even use the same GUI toolkit).
Yeah, they are now to big and to lazy i guess. But they enforce it still on iOS. The Software quality is also problematic, even for stuff like XCode. Its so bloated and i really don’t like all the automatic/autogenerated code.
I try to stick to vim and make/cmake and gdb works best for me.
What the LLVM project calls “Unix-like systems” include Linux, MacOS and other BSD derivatives. There are many other Unix variants but those are the main ones in use today. Clang is the default compiler on MacOS, its iOS derivates and Free BSD. For Linux the default is gcc and Windows MSVC. Clang is an open source C++ front end for the LLVM tool chain (which is also used by Rust and Swift) which was originally developed by Apple to replace gcc on MacOS and iOS. Google is now a major contributor and has a large compiler development team working on it.
All three compilers (known by many C++ developers as the Big 3) are close enough to each other in language conformance that there is little advantage in not just using which ever is the default compiler for the system you are targeting. The real headache in C++ development is not longer compilers, it is build systems and dependency management. The situation is so bad that many Linux developers just use the system package manager to install dependencies which has the effect of making their applications less portable but also build system agnostic.
There are many build systems used for C++. Ardour uses a fairly obscure one called Waf which is based on Python. GTK also uses a slightly more popular Python based build system called Meson. The majority of C++ developers are now using a system called CMake which is cross platform and built using C++. The CMake developers work very closely with the developers of all the Big 3 compilers. Microsoft now directly supports CMake in Visual Studio (which now ships with CMake) for cross platform development.
There are also a few package managers in the C++ ecosystem. Conan is another Python based tool that works with CMake and other build systems. Vcpkg is a native app that is CMake based but makes heavy use of git too. It was written by Microsoft and is gaining popularity. About 2700 open source libraries are available via vcpkg.
If the open source C++ community can converge on one set of build and package management tools, I think it will become much easier to find C++ developers interested in working on the smaller open source projects.