you’re correct. I’m just trying to understand what this whole shenaniganing was about.
It seems like it’s a great time to review these: https://discourse.ardour.org/guidelines. The direction this thread’s ended up is a brilliant way to put people off contributing to the Ardour community.
3 Likes
it was a dead-end debate before it even began, however there is a lot of very great feedback from pretty much everybody as far as I can tell. I don’t think we need to ridicule the project leader’s competence of this project which is the impression I have reflected based off the OP text itself more than anything else. However, it’s not helpful it we remain clueless that we are not able to help others. The majority of the responses I see on this thread are indeed passively positive, so I think people are very well of the guidelines. If you mean the original OP-text and everything that is on it(if you have read it), users (other than me), still have the right to bring forth “concerns” more than personal misinterpretations or anything ad-hominem. If you are referring to me, supposedly I would accept your valid response, but I think you should be referring to everybody.
cheers.
I was the first responder and have kept abreast of the comments.
Thanks 
1 Like
Paul good point I never thought about that as I have not had to distribute. I am going to try and build Ardour from source and see how “bad” of an experience it is. Then reply back here. Great thread sir! I would also say I love this community for the passion it has. Paul I appreciate all that you bring to the table and the unlimited amount of love that goes into this project. I can not say enough thank you! Now to go donate and put some money where my mouth is.
I don’t get it, what’s wrong with GTK? It’s an excellent toolkit and it’s starting to attract much more investors and developers in recent days. Soon enough you’ll have some form of Glade like xml rapid gui prototyping solution available in GNOME Builder. Afaik there already is some stuff for that in Builder but it’s going to get developed for real to be a standard in the recent future.
1 Like
Ideology can afford to be, well, ideal. The world and it’s population of 7.6 billion+ humans, un/fortunately, is not. I see no need for the Ardour developers to second guess what they’ve achieved. It’s pretty damned amazing. IMHO Nor is there any need for developers following either model, opensource or proprietary, to justify or defend their chosen development or distribution models. There’s enough to go around. 
1 Like
Just joined the forum after reading Pauls entry post here. Came initially to check out Ardour VST3 implementation and got curious, this seems to be healthy and lively community.
Ardour beeing open source is what makes it stand out for all the reasons mentioned by others here: Project compatibility, platform choices, core access etc. Imho, scripting APIs alone does not provide enough freedom.
Here are some thoughts why more extensive scriptability might still make sense:
- C++ is fine but boilerplaty, compared to most DSL APIs. System languages require jumping a lot of hoops while proper DSL APIs shield the user from exactly those.
- C++ requires not only rebuilding the software, but also restarting it. Scripting in Blender, Renoise, REAPER, HALion or monome Norns can be done at runtime.
- scripts do not require messing with compiler flags to enable/disable features. If you need a feature on your laptop, and another on your studio box, but not always, you just enable the script.
- Stability and safety are another concern, blender is not the best example here, but Renoise is. It is easy to mess up the memory and crash everything with C++ but not in LUA. The Renoise crew claims that their core is not destructible by their scripting engine.
Some ideas:
- GIT is a great script module storage, vundle for VIM or the norns use it in a nice way.
- Extending the LUA API with access to basic graphic elements (windows, basic geometry, strings) would be nice because it allows stuff such as customized HUDs for midicontroller mappings, context switching for input devices, dashboards and other highly individual stuff that has nothing to do with the core.
I am new to Ardour, so forgive me if I state the obvious somewhere.
Edit: Forgot one important point. If you develop scripts to extend a proprietary software, your efforts will be lost, once that software is discontinued. Writing extensions for open source software is much more future proof. (as open source software is in general)
Edit2: Forgot to add a reference to the initial thread title.
Open source is a necessity for many reasons. Users never need it, but it empowers them anyway. Users need features to achieve their goals. Nobody need source access until they need it, and when they need it, it is a necessity.
Edit3: I just realised we have February 2021… and 2020 was a year ago 
1 Like
Just started digging into the docs, impressive. I might actually switch away from REAPER now…
1 Like
In Ardour we just expose the C++ API calls as-is. While Lua protects you from null pointers, there are still plenty of ways to mess things up.
Ardour’s backend provides mechanism. Most policy restrictions happen in the GUI and with scripts you can bypass those.
1 Like
Sounds dangerous but good to know and powerful. Read earlier in the docs that almost all the calls are bound, pretty cool. Thanks for the warning/clarification.
I think that open-source is not only a useful and ethical choice, but also a guarantee of reliability, a possibility open to the acquisition of new personal skills, a beautiful community of beautiful people who cooperate for noble purposes. And I believe that this beautiful software is a demonstration of how open-source is synonymous with pro!
2 Likes
I think, you are missing one aspect: If you are a audio engineer, you don’t want to edit source code upon a certain point.
Reaper has a growing sound designers community for video games and movies because it is customizeable deep enough without learning a real programming language. It’s much quicker to do for a not-programmer.
In the music industry there is AFAIK (in my bubble) mostly Pro Tools and Cubase used by pros, because they were the big DAWs for ages and some of the very first. They got used to it and can’t switch that easy – learning for ages the new DAWs, and maybe never use them because they are lacking some essential features for their workflow. Tho there is no real need for it.
Long story short: Most users are simple users and no programmers. They want to get things done.
For me, it’s a nice to have, if I use a FLOSS application, because I like the way to think about freedom of doing anything. But since my c++ skills does not cover anything above a simple calculator BUT I can do anything with Ardour/Reaper, there is no need to learn it.
3 Likes
I will provide my position on this.
A) I am a back-end developer, so I’m comfortable with “building” (so to speak) but I primarily work in an intermediate language (C#/.NET) so for me a “build” is as simple as hitting F5 on my keyboard within my IDE (Visual Studio). When I start having to deal with installing multiple pieces of software to allow me to build, setting up MAKE scripts, etc. It quickly gets very overwhelming to me and makes me move to a different piece of software that doesn’t require this. Not to say if I had a heavy investment in a project I wouldn’t be willing to learn it an use it, but it does create a barrier to entry for most “casual” developers or developers in higher languages.
B) I am intermediate level proficient in C# but I have very, very little experience with C/C++ so for me, I would love to be able to contribute but my lack of skills in C cause me to avoid getting involved.
C) I would be willing to learn the language to get involved, but, because of the power of C it really is not something you can just take a 4 hour read on and then start coding… to be useful in the language you have to spend a lot of time in it to become proficient.
D) Regardless of reasons A-C, I still would pick an open-source product over a closed-source product any day of the week if they are both comparable. This is because I firmly believe in open source and I want to support it and I want to have the freedom to access/use the source code if it ever did become important enough for me to cross hurdles A-C.
E) I agree with others, I don’t think this is going to make a difference for a majority of the users. Only a subset will really care either way.
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.
2 Likes
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.
SeabladeArdour’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.
In contrast, here are the build instructions for my window manager: README - dwm - dynamic window manager