Ardour 5 released(community.ardour.org)
community.ardour.org
Ardour 5 released
https://community.ardour.org/node/13842
6 comments
That is the biggest problem with FOSS for desktop use, you cannot hide it behind paywalls or consulting gigs, which makes very hard to make a living out of it.
I always try to donate to the projects I use frequently, as if I just had bought a software package.
I always try to donate to the projects I use frequently, as if I just had bought a software package.
I've purchased in the past just to support (and to keep going the illusion that I'll create some audio for /me/ in the future).
That's not that much money, they need grants from OSS foundations, OSS like that need to get better at funding. How many millions the Mozilla foundation gave away this year ? and to only what, 8 projects ? The Gnome foundation could also help , instead of the financing dubious programs I won't name. But I guess it's better to waste money on hype rather than supporting well established projects.
Agreed, qualifying 75 k$/yr in the US as "not much money" is hyperbole for a developer with 20 years experience of multithreaded multiplatform C++.
As to funding from big OSS players, the problem is that Ardour is niche software, far away from the interests of those big OSS players. Regarding your examples,
- Mozilla has interest and invests into web/infrastructure tech (see https://news.ycombinator.com/item?id=11956234 ), Ardour doesn't fit in here.
- GNOME... can you name these dubious programs you are referring to? To my eyes, GNOME just tries to survive with limited funding.
As to funding from big OSS players, the problem is that Ardour is niche software, far away from the interests of those big OSS players. Regarding your examples,
- Mozilla has interest and invests into web/infrastructure tech (see https://news.ycombinator.com/item?id=11956234 ), Ardour doesn't fit in here.
- GNOME... can you name these dubious programs you are referring to? To my eyes, GNOME just tries to survive with limited funding.
The GNOME program aims at getting more people involved in OSS projects:
https://www.gnome.org/outreachy/
Personally, I think it is awesome and appreciate the great contributors I've seen come in through the program.
https://www.gnome.org/outreachy/
Personally, I think it is awesome and appreciate the great contributors I've seen come in through the program.
> Currently, internships are open internationally to women (cis and trans), trans men, and genderqueer people. Additionally, they are open to residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander.
It's have been quicker to write, 'internships are open to everyone but white, heterosexual men,' but that would have been too honest.
How utterly despicable.
Perhaps Paul Davis could apply, and claim to be Pauline Davis for internship purposes.
It's have been quicker to write, 'internships are open to everyone but white, heterosexual men,' but that would have been too honest.
How utterly despicable.
Perhaps Paul Davis could apply, and claim to be Pauline Davis for internship purposes.
> "It's have been quicker to write, 'internships are open to everyone but white, heterosexual men,' but that would have been too honest."
Agreed.
But I don't think it's despicable. Our field needs diversity, and in a dominated ecosystem you don't get diversity by just letting natural forces do their job, because the ecosystem is already dominated/biased.
So to my eyes we need biased, opposed initiatives like this one, or PyLadies.
Does it remove available funding for Paul? (In other words, are the total available OSS funds the result of a zero-sum game)? I don't think so: some support the goals of Outreachy and contribute to it, some like Mozilla just contribute to what's in their field. These programs are about OSS fundings but I wouldn't categorize them as part of the same set.
Agreed.
But I don't think it's despicable. Our field needs diversity, and in a dominated ecosystem you don't get diversity by just letting natural forces do their job, because the ecosystem is already dominated/biased.
So to my eyes we need biased, opposed initiatives like this one, or PyLadies.
Does it remove available funding for Paul? (In other words, are the total available OSS funds the result of a zero-sum game)? I don't think so: some support the goals of Outreachy and contribute to it, some like Mozilla just contribute to what's in their field. These programs are about OSS fundings but I wouldn't categorize them as part of the same set.
I really don't know what I think about wtbob's comment, but it's awful that it got flagkilled.
Are the total available OSS funds the result of a zero-sum game?
I think at face-value it isn't zero-sum. I think this question can be restated as "If advocacy groups became convinced that this kind of discrimination is unproductive, would they spend their money on supporting open source, or on promoting minority groups in a different way?". I think it's pretty clear that the answer is the latter. But you can also step back and ask whether the advocacy groups would have less funding if these programs came to be considered ineffective, and I think they would, since people would lose trust in them. I'm sure a lot of that money would go toward some other kind of minority advocacy groups, but I'm also sure that many sources of funding are actually specifically interested in promoting open source (otherwise it would be more productive for them to support minorities in employment, not open source internships). I think it's reasonable to say some of that money might make its way to people like Paul.
This is terribly speculative, but it is to say that if you accept that discriminatory programs like outreachy are not productive, there's merit to the claim that they deprive heroes like Paul of funding.
Are the total available OSS funds the result of a zero-sum game?
I think at face-value it isn't zero-sum. I think this question can be restated as "If advocacy groups became convinced that this kind of discrimination is unproductive, would they spend their money on supporting open source, or on promoting minority groups in a different way?". I think it's pretty clear that the answer is the latter. But you can also step back and ask whether the advocacy groups would have less funding if these programs came to be considered ineffective, and I think they would, since people would lose trust in them. I'm sure a lot of that money would go toward some other kind of minority advocacy groups, but I'm also sure that many sources of funding are actually specifically interested in promoting open source (otherwise it would be more productive for them to support minorities in employment, not open source internships). I think it's reasonable to say some of that money might make its way to people like Paul.
This is terribly speculative, but it is to say that if you accept that discriminatory programs like outreachy are not productive, there's merit to the claim that they deprive heroes like Paul of funding.
> But I don't think it's despicable. Our field needs diversity, and in a dominated ecosystem you don't get diversity by just letting natural forces do their job, because the ecosystem is already dominated/biased.
Serious question: was this kind of stuff necessary for the huge increases over the decades in the percentage of lawyers and doctors who are women? If not, then it seems it's possible (if not necessarily desirable) to let "natural" forces do their work for achieving gender balance, and least for careers requiring well-educated individuals that provide high compensation and confer high status (those are both higher status than developers in most circles, by far). But maybe there were lots of women-only medical conferences or something at some point. Maybe there still are, I really don't know.
(I did a quick DDG search for this issue in law and medicine, but turned up nothing relevant aside from graphs demonstrating the shift)
Serious question: was this kind of stuff necessary for the huge increases over the decades in the percentage of lawyers and doctors who are women? If not, then it seems it's possible (if not necessarily desirable) to let "natural" forces do their work for achieving gender balance, and least for careers requiring well-educated individuals that provide high compensation and confer high status (those are both higher status than developers in most circles, by far). But maybe there were lots of women-only medical conferences or something at some point. Maybe there still are, I really don't know.
(I did a quick DDG search for this issue in law and medicine, but turned up nothing relevant aside from graphs demonstrating the shift)
I don't know either. Thoughts/questions:
- Can we compare the case of legal/medical to software? Especially, have the legal/medical fields been so unbalanced as software is right now? (Not implying it was, honestly asking). And if it was, as you ask yourself, what mechanisms helped bringing balance?
- Regarding the specific case of sexism in software, early research suggests that the unbalance may have emerged in the 1970s as "the idea that computers are for boys became a narrative", maybe due to ads: http://www.npr.org/sections/money/2014/10/21/357629765/when-... . Admitting this idea, what about now? Yes, unlike in the 1970s, software is part of everyone's daily lives. However, the "computers (and STEM) are for boys" myth isn't dead.
- Can we compare the case of legal/medical to software? Especially, have the legal/medical fields been so unbalanced as software is right now? (Not implying it was, honestly asking). And if it was, as you ask yourself, what mechanisms helped bringing balance?
- Regarding the specific case of sexism in software, early research suggests that the unbalance may have emerged in the 1970s as "the idea that computers are for boys became a narrative", maybe due to ads: http://www.npr.org/sections/money/2014/10/21/357629765/when-... . Admitting this idea, what about now? Yes, unlike in the 1970s, software is part of everyone's daily lives. However, the "computers (and STEM) are for boys" myth isn't dead.
The effect there was pretty rapid. Did it somehow take hold far more strongly than the earlier narrative (whatever that may have been)? It seems like the marketing has become quite a bit less dude-centric, yet the trend continues in spite of everything. One would hope a similarly sudden shift the other direction could be effected, but that doesn't appear to be happening.
Oddly enough, the two most obvious big drops on that graph appear to correspond pretty closely with drops in the total share of university students majoring in CS[1]. What significance that has, if any, I do not know.
[1] http://core0.staticworld.net/images/idge/imported/article/it...
Oddly enough, the two most obvious big drops on that graph appear to correspond pretty closely with drops in the total share of university students majoring in CS[1]. What significance that has, if any, I do not know.
[1] http://core0.staticworld.net/images/idge/imported/article/it...
> How utterly despicable.
> Perhaps Paul Davis could apply, and claim to be Pauline Davis for internship purposes.
How utterly reactionary.
Moreover, do you realize just how despicably transphobic or queerphobic this statement is? The irony in your comment is appalling. Your comment is a perfect example of precisely why we do need to support people who don't conform to heteronormative stereotypes.
> Perhaps Paul Davis could apply, and claim to be Pauline Davis for internship purposes.
How utterly reactionary.
Moreover, do you realize just how despicably transphobic or queerphobic this statement is? The irony in your comment is appalling. Your comment is a perfect example of precisely why we do need to support people who don't conform to heteronormative stereotypes.
This blatant encouragement that being a normal white male is not diversive enough is both anti-male and white-phobic. It conforms to that old age stereotype that white males are somehow superior to genders of other race.
Supporting such blatant discrimination against white males does nothing to encourage diversity. These kind of diversity out-reach programs operates under the assumption that diversity can only by achieve through discrimination against white males, which that is not true. Diversity can be achieved without discriminating against white males.
Supporting such blatant discrimination against white males does nothing to encourage diversity. These kind of diversity out-reach programs operates under the assumption that diversity can only by achieve through discrimination against white males, which that is not true. Diversity can be achieved without discriminating against white males.
> how despicably transphobic or queerphobic this statement is
How so? Nobody is claiming everyone lies about it, only that it might be possible to do so (since outreachy has no recourse to an objective test).
How so? Nobody is claiming everyone lies about it, only that it might be possible to do so (since outreachy has no recourse to an objective test).
Obviously getting way offtopic here, but I want to point out that from scanning that page it looks like that's a $5000 stipend for three months of 40-hour weeks. Not exactly the big bucks.
The Lua scripting is interesting, I wonder if it's possible to basically mix an album with a text file you can check into Git.
I've already made that transition with my music notation projects using Lilypond, I actually have a (very short) full orchestra film score written in Lilypond - full text, nice diffs, revision history, committed to github.
I've already made that transition with my music notation projects using Lilypond, I actually have a (very short) full orchestra film score written in Lilypond - full text, nice diffs, revision history, committed to github.
Ardour session files are just text files. Scripts used within the session are saved as part of the session file, so that the session can be used on any Ardour installationg, without having to 'get the scripts'.
I know of a few Ardour users who are using git to collaborate on sessions. Once you figure out how best to deal with the audio data, it seems quite promising.
I know of a few Ardour users who are using git to collaborate on sessions. Once you figure out how best to deal with the audio data, it seems quite promising.
Scripting with version control sounds very useful to me, since I typically use a very similar recording setup, but may do slight modifications.
Is there anyone on here who uses DAW's seriously, and has tried Ardour? Can it compete with the big boys?
I'd say that it's competitive with older versions of the major DAWs. It's reasonably stable and has a reasonably complete feature set.
The problem for Ardour on Linux is the plugin ecosystem. Any serious DAW user has invested thousands of dollars in plugins, none of which will run on Linux. For Linux to be a serious platform for audio work, it needs much more than just a DAW; it needs samplers, synths, reverbs, dynamics and EQ processors, pitch correction, restoration and mastering tools, etc etc.
Ardour is a noble effort, but I can't help feeling that it's a little bit futile. The sheer scale of the audio software ecosystem seems insurmountable for free software.
The problem for Ardour on Linux is the plugin ecosystem. Any serious DAW user has invested thousands of dollars in plugins, none of which will run on Linux. For Linux to be a serious platform for audio work, it needs much more than just a DAW; it needs samplers, synths, reverbs, dynamics and EQ processors, pitch correction, restoration and mastering tools, etc etc.
Ardour is a noble effort, but I can't help feeling that it's a little bit futile. The sheer scale of the audio software ecosystem seems insurmountable for free software.
Every day, there are NEW DAW users who have no plugins.
I think you're also not fully informed on the scale of existing plugin development on Linux. Several commercial developers now produce plugins for Linux, and there are some open source ones for many tasks that are actually outstanding. Noise removal/restoration is one particularly weak spot.
Finally, Ardour doesn't run on just Linux. Anyone on OS X or Windows can use the program, along with their full set of VST (Windows) or AU (OS X) plugins on those platforms.
I think you're also not fully informed on the scale of existing plugin development on Linux. Several commercial developers now produce plugins for Linux, and there are some open source ones for many tasks that are actually outstanding. Noise removal/restoration is one particularly weak spot.
Finally, Ardour doesn't run on just Linux. Anyone on OS X or Windows can use the program, along with their full set of VST (Windows) or AU (OS X) plugins on those platforms.
>Several commercial developers now produce plugins for Linux, and there are some open source ones for many tasks that are actually outstanding.
I've demoed a large number of open source or Linux-compatible plugins; with the exception of Pure Data and the Calf Studio plugins, they were uniformly awful. Pure Data is still substantially inferior to Reaktor. Last time I checked, the Calf Studio plugins weren't cross-platform and had considerable shortcomings compared to their proprietary equivalents.
A huge proportion of my bread-and-butter plugins have no Linux equivalent that is even remotely comparable: Kontakt, Vienna Symphonic Library, Omnisphere, Melodyne, Izotope Rx and Ozone, Bias FX, the UAD and Arturia emulations etc.
Producing music on Linux would be an exercise in frustration. The plugins available on Linux compare very badly to the bundled plugins that come with Logic or Cubase, let alone the whole market.
The very best open source plugins are mediocre at best. In many absolutely crucial categories, they are laughably bad - compare Freeverb3 with Vienna MIR or Altiverb, for example.
I've demoed a large number of open source or Linux-compatible plugins; with the exception of Pure Data and the Calf Studio plugins, they were uniformly awful. Pure Data is still substantially inferior to Reaktor. Last time I checked, the Calf Studio plugins weren't cross-platform and had considerable shortcomings compared to their proprietary equivalents.
A huge proportion of my bread-and-butter plugins have no Linux equivalent that is even remotely comparable: Kontakt, Vienna Symphonic Library, Omnisphere, Melodyne, Izotope Rx and Ozone, Bias FX, the UAD and Arturia emulations etc.
Producing music on Linux would be an exercise in frustration. The plugins available on Linux compare very badly to the bundled plugins that come with Logic or Cubase, let alone the whole market.
The very best open source plugins are mediocre at best. In many absolutely crucial categories, they are laughably bad - compare Freeverb3 with Vienna MIR or Altiverb, for example.
Pianoteq ? U-he ? Distrho? Harrison Consoles ? These are all proprietary plugins for Linux, all of them excellent.
PureData is a VERY VERY different program from Reaktor, capable of things not possible in Reaktor, but also with a totally different work flow and interaction model. There are many PD users who would absolutely disagree with your characterization.
My point was not to say "The plugin situation on Linux is totally comparable to the one of OS X or Windows", indeed far from it. But your post suggested that there's no signs of life at all there, and this just isn't true.
You also seem very focused on a style of music production that is really built around plugins. This is common today, but far from universal. I know many studio owners in the USA and Europe who use plugins very minimally, because they focus on recording performing musicians.
As I've said many times, if you have a workflow that is tightly bound with platform-specific plugins, you should stay on that platform. With this release of Ardour, people are now free to consider using Ardour on that platform. That is all.
PureData is a VERY VERY different program from Reaktor, capable of things not possible in Reaktor, but also with a totally different work flow and interaction model. There are many PD users who would absolutely disagree with your characterization.
My point was not to say "The plugin situation on Linux is totally comparable to the one of OS X or Windows", indeed far from it. But your post suggested that there's no signs of life at all there, and this just isn't true.
You also seem very focused on a style of music production that is really built around plugins. This is common today, but far from universal. I know many studio owners in the USA and Europe who use plugins very minimally, because they focus on recording performing musicians.
As I've said many times, if you have a workflow that is tightly bound with platform-specific plugins, you should stay on that platform. With this release of Ardour, people are now free to consider using Ardour on that platform. That is all.
I concur - been using DAW's for decades now, and Ardour out of the box on a newly installed Ubuntu Studio-based system has tons, and tons of plugins - there isn't a single category of plugin in the OP's list that isn't available. You just have to not shop for them, and rather look in the repository, because they're there ..
This is a Free Software antipattern. Yes, there are things that exist that claim to do the same thing as commercial software. No, that doesn't necessarily mean they're actually functional replacements for that software.
I mean some of them are, but there's no sampler that will painlessly play modern sample packs, no usable pitch correction, nothing a tenth as good at noise reduction / audio restoration as Izotope RX.
Also, maybe a violin is as good as a guitar, but you can't hand a guitarist a violin and expect them to be fine with that. Or vice versa, if you prefer.
I like, use and pay for Ardour, but I also like realism.
I mean some of them are, but there's no sampler that will painlessly play modern sample packs, no usable pitch correction, nothing a tenth as good at noise reduction / audio restoration as Izotope RX.
Also, maybe a violin is as good as a guitar, but you can't hand a guitarist a violin and expect them to be fine with that. Or vice versa, if you prefer.
I like, use and pay for Ardour, but I also like realism.
That's all fair and correct.
But why is there no Izotope on Linux? People gripe at free software developers for "not providing Izotope", when in reality that software represents years of dedicated R&D, something that most people are not willing to pay for (even on platforms other than Linux). The simple reason why Izotope and Kontakt and Melodyne are not available on Linux is not that free software developers haven't written them, it is that the companies that do write them have chosen not to make them available.
I was very fortunate to start Ardour at a time when I did not need the income. Expecting to see world-class plugins like these show up without the involvement of the companies that did the R&D (and/or defined the proprietary file formats in use) is naive.
FWIW, I have talked to Melodyne in the past about adding support for their non-linear data access API, but they have been "unable to come to a consensus about how we could permit this in an open source project".
So for sure, these kinds of plugins are not available on Linux: because their developers have chosen that.
But why is there no Izotope on Linux? People gripe at free software developers for "not providing Izotope", when in reality that software represents years of dedicated R&D, something that most people are not willing to pay for (even on platforms other than Linux). The simple reason why Izotope and Kontakt and Melodyne are not available on Linux is not that free software developers haven't written them, it is that the companies that do write them have chosen not to make them available.
I was very fortunate to start Ardour at a time when I did not need the income. Expecting to see world-class plugins like these show up without the involvement of the companies that did the R&D (and/or defined the proprietary file formats in use) is naive.
FWIW, I have talked to Melodyne in the past about adding support for their non-linear data access API, but they have been "unable to come to a consensus about how we could permit this in an open source project".
So for sure, these kinds of plugins are not available on Linux: because their developers have chosen that.
I don't gripe at free software developers for not providing Izotope, I gripe at people who pretend Audacity is the same thing. I think the usual result of this mis-selling is that people quickly go back to proprietary software with renewed hostility towards Free Software and its advocates.
Edit: To be clear that isn't intended as a gripe at Audacity, just at the misrepresentation of Audacity.
Edit: To be clear that isn't intended as a gripe at Audacity, just at the misrepresentation of Audacity.
On the other hand, there are audio tools in the Free Software world that wouldn't be possible in a commercial context.
The point is this: its up to the user to gain maximum value from their investment. Nobody is going to do that for you.
The point is this: its up to the user to gain maximum value from their investment. Nobody is going to do that for you.
I would say that with Ardour on Linux, the lack of plugins will allow you to jump straight up to hardware synths and effects.
The big boys are not using very much in the way of plugin synths, there are a few good plugins but they are at the price of hardware. Unless you intend to do your own mastering (don't) you're good to go with Ardour and a good analog mixing board plus a compatible high-quality DAC/ADC (if you're like me, an Apogee ONE is all you need).
That's actually not true. The "big boys" use tons of plugin synths. Hans Zimmer comes to mind (the entire soundtrack to Nolan's Batman series was done with U-he's Zebra2, which is an amazing synth).
What you tend not to see are large-scale touring bands playing live with plugin synths. This is mostly from fear - that something will crash. There are gazillion of smaller bands performing live with Ableton Live and its own plugins, along with 3rd party engines.
What you tend not to see are large-scale touring bands playing live with plugin synths. This is mostly from fear - that something will crash. There are gazillion of smaller bands performing live with Ableton Live and its own plugins, along with 3rd party engines.
I'm not qualified to comment as a "serious" user (as would be, say, someone doing mix/production for a living), but as a hobbyist it has been a joy and powerhouse to use and produce two little homebrew albums.
Another popular alternative for that kind of audiences is http://reaper.fm/ , from Cockos from Justin Frankel & co from Nullsoft who made WinAMP.
Another popular alternative for that kind of audiences is http://reaper.fm/ , from Cockos from Justin Frankel & co from Nullsoft who made WinAMP.
As a serious hobbyist, ardour is on the way to compete with pro tools. I decided to use ardour, musescore and ableton live for different purposes 3 years ago and I m happy. Reaper, logic pro, garage band etc don't give anything extra to Ardour after 6 months of trials I can say that.
> Is there anyone on here who uses DAW's seriously, and has tried Ardour? Can it compete with the big boys?
Can it compete? Yes, a DAW hardly decides what the final result sounds like. The problem is integration. Often controllers come with presets for Pro-tools,Logic, Cubase, Live so integration is seamless, there is virtually no need for configuration. Now Is Ardour popular ? right now not that much. But it's a great project non-less and perfectly capable.
Can it compete? Yes, a DAW hardly decides what the final result sounds like. The problem is integration. Often controllers come with presets for Pro-tools,Logic, Cubase, Live so integration is seamless, there is virtually no need for configuration. Now Is Ardour popular ? right now not that much. But it's a great project non-less and perfectly capable.
Ardour has builtin support for many hardware controllers. Our support for Mackie Control is as good as anything in the proprietary world, ditto for things like the FaderPort. Generic MIDI controllers can have MIDI maps, and we have at least a dozen predefined ones already.
Ardour 5.1 will also see support for the Ableton Push 2 device.
Popularity: right now, someone starts a bundle of Ardour obtained from ardour.org roughly once every 4 minutes. There were 10,000 downloads of Ardour 4.7 from ardour.org. We're more like the members of the Fight Club network than we are like the ProTools club: we're everywhere, but you can't see us. Every laptop distributed to the favelas by the Brazilan government comes with Ardour. There are at least 10,000 users of Ardour in each of the USA and Germany alone.
Are we "as popular" as Reaper, Logic or Cubase? Almost certainly not. Are we popular enough? Sure.
Ardour 5.1 will also see support for the Ableton Push 2 device.
Popularity: right now, someone starts a bundle of Ardour obtained from ardour.org roughly once every 4 minutes. There were 10,000 downloads of Ardour 4.7 from ardour.org. We're more like the members of the Fight Club network than we are like the ProTools club: we're everywhere, but you can't see us. Every laptop distributed to the favelas by the Brazilan government comes with Ardour. There are at least 10,000 users of Ardour in each of the USA and Germany alone.
Are we "as popular" as Reaper, Logic or Cubase? Almost certainly not. Are we popular enough? Sure.
>Ardour 5.1 will also see support for the Ableton Push 2 device.
that's goddamn great. Keep up the awesome work, this program is a masterpiece
that's goddamn great. Keep up the awesome work, this program is a masterpiece
In the interest of truth-in-comment-threads, it looks as if 5.1 will be a bug fix release, without the Push 2 support. That will land in 5.2, probably. The majority of the work is done, but I want it more polished before releasing it.
Eh, it's pretty good, but as another commentor noted, Ardour has tended to lag behind other DAWs.
For example: Ardour didn't get full Midi support until 2013, approximately twenty years after Pro Tools 1.0 launched with MIDI support from the start.
For example: Ardour didn't get full Midi support until 2013, approximately twenty years after Pro Tools 1.0 launched with MIDI support from the start.
Do you seriously want me to list all the features that Ardour had for 10 years before they showed up in ProTools?
This is a recent list of PT user's most-wanted features.
http://www.pro-tools-expert.com/home-page/2016/6/21/which-of...
Every single one of the 7 completed items out of the 20 existed in Ardour for years before they were in ProTools.
We were the first DAW to provide anything-to-anything routing. We were the first DAW to have sub-sample accurate timecode lock. We were the first DAW to have sample-accurate automation. We were the first DAW to allow in-track mixing (transparent regions). We were the first DAW to offer PFL/AFL solo models in addition to solo-in-place. We were the first DAW to offer a dedicated monitor section in addition to the master outs. We were for a very long time the only DAW that could handle multichannel master outs (used, for example, in ambisonics set ups - 40 channel master bus, anyone?).
There are certainly areas where our functionality is behind the current state of one or more other DAWs. That's true for all DAWs. Our MIDI workflow is still weak, but evolving. But the idea that we generally "lag" behind other DAWs is mostly a conception of people who like and use what I term "modern pop production techniques", which has never really been my own personal focus. If there's another DAW out there that works better for you than Ardour, you should use it. But you might also be surprised at how well Ardour works for you, especially if you record people playing instruments.
This is a recent list of PT user's most-wanted features.
http://www.pro-tools-expert.com/home-page/2016/6/21/which-of...
Every single one of the 7 completed items out of the 20 existed in Ardour for years before they were in ProTools.
We were the first DAW to provide anything-to-anything routing. We were the first DAW to have sub-sample accurate timecode lock. We were the first DAW to have sample-accurate automation. We were the first DAW to allow in-track mixing (transparent regions). We were the first DAW to offer PFL/AFL solo models in addition to solo-in-place. We were the first DAW to offer a dedicated monitor section in addition to the master outs. We were for a very long time the only DAW that could handle multichannel master outs (used, for example, in ambisonics set ups - 40 channel master bus, anyone?).
There are certainly areas where our functionality is behind the current state of one or more other DAWs. That's true for all DAWs. Our MIDI workflow is still weak, but evolving. But the idea that we generally "lag" behind other DAWs is mostly a conception of people who like and use what I term "modern pop production techniques", which has never really been my own personal focus. If there's another DAW out there that works better for you than Ardour, you should use it. But you might also be surprised at how well Ardour works for you, especially if you record people playing instruments.
I've been trying to use it off and on from the very beginning of its development. And, I've been a subscribing contributor off and on for a long time, too. I say "trying to use it" not so much because Ardour is inferior to other DAWs; it isn't. It's pretty solid, pretty capable, and pretty fast, compared to all the big ones (and I've used many of them in a professional and hobbyist context). It is a great piece of software, honestly.
But, I keep ending up doing my actual work in Reaper; not because Ardour is inferior, but because audio on Linux is inferior. At least, it historically has been. It's always been a bastard step child. To run Ardour, say, five years ago required a custom kernel, a non-standard audio server that was incompatible with any of the Gnome/KDE audio servers (there were compatibility layers, but they never worked, so switching back and forth was the only way to do anything...meaning your normal desktop lost sound when Ardour was in use, I wrote a script to switch them), running VSTs was possible but challenging and limited to those that would run under WINE (often with very buggy results), the surrounding ecosystem was just a mess, in general.
If you had the ability to build a perfect system, and never touch it, it might have been OK, but I never could keep the whole stack working for more than a couple of weeks; a kernel update or something else would break it, and I'd be in for another day or two of fucking around with kernels and ALSA drivers and WINE and whatever else. It just wasn't a usable system, even though it has always been a very powerful DAW.
Many things have improved in the intervening years. Enough of the RT work has been integrated into the mainline kernel that you don't need to patch your kernel anymore (though I think there are still some folks who apply some additional low latency patches, that's probably not necessary; Linux is now, I think, competitive with macOS and Windows when it comes to audio latency). WINE has gotten better, though running VSTs with Ardour is still a rough afternoon of effort, in my most recent experience. It's been a couple of years since I last tried to use Ardour for recording; the last time I gave up (again) and went back to Reaper, so I could get some recording done without spending two days making my system work for audio.
The sad thing is that Linux has been my primary desktop for over 20 years now; I never need to reboot into Windows anymore for anything, except audio...even games are fine, for me, on Linux now that Steam offers so many great titles for Linux. I never thought I'd be saying "games are fine" before I was able to say "audio is fine", and I've been trying to use Linux for audio all those years...I was working in recording studios and attending college for audio recording when I first started using Linux, even, so it was a thing I spent a ton of time tinkering with.
So, in short: I don't know where it stands today. But, I've been disappointed pretty much every time I've tried to use Ardour for anything serious; it's not Paul's fault. Ardour is great. But, it's historically just really tough to do audio work on Linux. I'd be surprised if it's gotten as good as Windows or macOS in the past two years; it's surely gotten better. But, I'd give good odds that it's still an afternoon, or even multi-day, project rather than a "install it and press the record button" process.
But, I keep ending up doing my actual work in Reaper; not because Ardour is inferior, but because audio on Linux is inferior. At least, it historically has been. It's always been a bastard step child. To run Ardour, say, five years ago required a custom kernel, a non-standard audio server that was incompatible with any of the Gnome/KDE audio servers (there were compatibility layers, but they never worked, so switching back and forth was the only way to do anything...meaning your normal desktop lost sound when Ardour was in use, I wrote a script to switch them), running VSTs was possible but challenging and limited to those that would run under WINE (often with very buggy results), the surrounding ecosystem was just a mess, in general.
If you had the ability to build a perfect system, and never touch it, it might have been OK, but I never could keep the whole stack working for more than a couple of weeks; a kernel update or something else would break it, and I'd be in for another day or two of fucking around with kernels and ALSA drivers and WINE and whatever else. It just wasn't a usable system, even though it has always been a very powerful DAW.
Many things have improved in the intervening years. Enough of the RT work has been integrated into the mainline kernel that you don't need to patch your kernel anymore (though I think there are still some folks who apply some additional low latency patches, that's probably not necessary; Linux is now, I think, competitive with macOS and Windows when it comes to audio latency). WINE has gotten better, though running VSTs with Ardour is still a rough afternoon of effort, in my most recent experience. It's been a couple of years since I last tried to use Ardour for recording; the last time I gave up (again) and went back to Reaper, so I could get some recording done without spending two days making my system work for audio.
The sad thing is that Linux has been my primary desktop for over 20 years now; I never need to reboot into Windows anymore for anything, except audio...even games are fine, for me, on Linux now that Steam offers so many great titles for Linux. I never thought I'd be saying "games are fine" before I was able to say "audio is fine", and I've been trying to use Linux for audio all those years...I was working in recording studios and attending college for audio recording when I first started using Linux, even, so it was a thing I spent a ton of time tinkering with.
So, in short: I don't know where it stands today. But, I've been disappointed pretty much every time I've tried to use Ardour for anything serious; it's not Paul's fault. Ardour is great. But, it's historically just really tough to do audio work on Linux. I'd be surprised if it's gotten as good as Windows or macOS in the past two years; it's surely gotten better. But, I'd give good odds that it's still an afternoon, or even multi-day, project rather than a "install it and press the record button" process.
The purely technical aspects of audio on Linux have always been better than Windows and OS X. Linux had lower latency than them more than a decade ago.
The user experience is a different story. That's the result of choices made by Linux distributions, most of which can be avoided by picking the right distribution or by doing some work. The biggest issue is the decision made some years (partly at my suggestion, ironically) to adopt PulseAudio as a desktop sound server (rather than JACK). This situation has been compounded by long-lived bugs in the versions of PulseAudio shipping with distributions that blocked the long-planned ways to tell PulseAudio to give up an audio device for "pro" use.
If you install the right Linux distribution (eg. AVLinux) then I would wager that its about 20 minutes from starting the install to "press the record button", with almost all of that being the distribution installation (it comes with Ardour already installed).
There's nothing to be done about the proliferation of Linux distributions that are not suitable for pro-audio or music creation workflows. It is a natural consequence of Linux' ecosystem that there are many, many distributions, each with different goals. A lot of people expect that "Linux is Linux is Linux", but for audio work, this isn't true. Installing Ubuntu and expecting that tools like Ardour will just work is incorrect and bound to lead to disappointment. It just isn't their target.
Note that Ardour no longer requires JACK on Linux. And this thread is actually about the release of Ardour 5.0, which runs on OS X, Linux and Windows. It seems a bit sad that people just want to talk about the situation on Linux as though that's the only place the program runs.
The user experience is a different story. That's the result of choices made by Linux distributions, most of which can be avoided by picking the right distribution or by doing some work. The biggest issue is the decision made some years (partly at my suggestion, ironically) to adopt PulseAudio as a desktop sound server (rather than JACK). This situation has been compounded by long-lived bugs in the versions of PulseAudio shipping with distributions that blocked the long-planned ways to tell PulseAudio to give up an audio device for "pro" use.
If you install the right Linux distribution (eg. AVLinux) then I would wager that its about 20 minutes from starting the install to "press the record button", with almost all of that being the distribution installation (it comes with Ardour already installed).
There's nothing to be done about the proliferation of Linux distributions that are not suitable for pro-audio or music creation workflows. It is a natural consequence of Linux' ecosystem that there are many, many distributions, each with different goals. A lot of people expect that "Linux is Linux is Linux", but for audio work, this isn't true. Installing Ubuntu and expecting that tools like Ardour will just work is incorrect and bound to lead to disappointment. It just isn't their target.
Note that Ardour no longer requires JACK on Linux. And this thread is actually about the release of Ardour 5.0, which runs on OS X, Linux and Windows. It seems a bit sad that people just want to talk about the situation on Linux as though that's the only place the program runs.
I am using the latest AVLinux with the latest Ardour on a machine dedicated to Linux-Audio. I get lots of dropouts/xruns, crashes in Ardour etc. MuSE not running properly at all (losing connection to jack).
The only things running reliable are Renoise, Tracktion, MuseScore and SuperCollider and only if I don't use jack, but just alsa exclusively.
Been very disappointed with Ardour. Always crashing with demanding plugins (e.g. drumgizmo), with "kind of" video support etc. Also disfunctional in some areas like Midi-Editing, CD-Cue-Export, layered Midi-recording. User interface too complicated and obscured. Hate to say it, but I considered dealing with Ardour to be a waste of time.
And this thread is actually about the release of Ardour 5.0, which runs on OS X, Linux and Windows.
Yeah, I noticed that, and that's awesome. But, I want to run it on Linux! That's one of the very big selling points of Ardour, for me, and one reason I would pick it over Reaper (on the day when I finally do pick it over Reaper).
I hope I was clear that I'm on your team. I want Ardour to be successful, and I want Linux to be a platform capable of media production. And, when I'm able, Ardour is one of the OSS projects I donate to.
But, maybe I'll try it on Windows sometime. That would certainly solve the VST problems, among several others.
Yeah, I noticed that, and that's awesome. But, I want to run it on Linux! That's one of the very big selling points of Ardour, for me, and one reason I would pick it over Reaper (on the day when I finally do pick it over Reaper).
I hope I was clear that I'm on your team. I want Ardour to be successful, and I want Linux to be a platform capable of media production. And, when I'm able, Ardour is one of the OSS projects I donate to.
But, maybe I'll try it on Windows sometime. That would certainly solve the VST problems, among several others.
For anyone who's doing personal podcasting, is this the software you'd use, or is there any (simpler) free/affordable software good for typical podcasting (I occasionally want to interview people over Skype and stuff)?
Definitely like the new feature for tempo ramps...great for dealing with decel/accelerandos.
It disappoints me that that they charge for pre-built binaries... Yes I can go and build it from source but it just doesn't feel right to have an open source project distributed like this. Shame on them for flaunting what I think is the spirit of Open Source.
- First there's nothing wrong per se about charging for binaries in a GPL project, other projects did it before them (XChat comes to mind) and others will do. Doing so is absolutely not flaunting anything for a GPL project, if you think so you should read about what Free Software means.
- Second, in the case of Ardour, just read https://community.ardour.org/node/8288 . These people are doing what they can to keep the project alive.
- Second, in the case of Ardour, just read https://community.ardour.org/node/8288 . These people are doing what they can to keep the project alive.
Thanks for digging up that link. I had forgotten I wrote that. Things have been better since it was written, but the project could still really use at least another 1/2 full time developer (it could use 50 more, but hey ...) let alone someone to do web stuff rather than me.
I think it is a great way to fund development. In any case various Linux distros will have gratis packages available at some point.
That's already happening: KXStudio, a Linux distro for audio work, has pre-packaged Ardour binaries.
Not just specialized distros like KX, Ardour is at your fingertips in vanilla Debian and Ubuntu
- http://packages.ubuntu.com/search?searchon=names&suite=all&s...
- https://packages.debian.org/search?keywords=ardour
- http://packages.ubuntu.com/search?searchon=names&suite=all&s...
- https://packages.debian.org/search?keywords=ardour
Note that because distros build Ardour using their stock GTK+ stack, there are a few issues with their builds that are not present in the bundles from ardour.org.
We (ardour.org) do not (and cannot) support distro-built versions of Ardour.
We (ardour.org) do not (and cannot) support distro-built versions of Ardour.
Why would stock GTK+ cause problems?
The most common reason is that we ship our own version of the clearlooks theme engine to ensure that we control the appearance of GTK+ widgets, and we load our own GTK2 RC file to define colors etc. for those widgets.
This leads to 2 errors, one irritating, one that prevents the program from functioning.
Irritating: GTK+ loads the system GTK theme during a call to gtk_init(). If this theme is based on clearlooks but contains declarations unknown to our (older) version of Clearlooks, you get errors.
Blocking: GTK+ loads the system GTK theme during a call to gtk_init(). If the theme file defines a "color theme", then when Ardour defines its own, GTK will block for ever, because of a bug in GTK+2. This doesn't happen if the system GTK theme has no color theme definition.
Those are the two main issues. They cannot be worked around without rebuilding the GTK+ stack so that it cannot or will not load the system GTK theme.
This leads to 2 errors, one irritating, one that prevents the program from functioning.
Irritating: GTK+ loads the system GTK theme during a call to gtk_init(). If this theme is based on clearlooks but contains declarations unknown to our (older) version of Clearlooks, you get errors.
Blocking: GTK+ loads the system GTK theme during a call to gtk_init(). If the theme file defines a "color theme", then when Ardour defines its own, GTK will block for ever, because of a bug in GTK+2. This doesn't happen if the system GTK theme has no color theme definition.
Those are the two main issues. They cannot be worked around without rebuilding the GTK+ stack so that it cannot or will not load the system GTK theme.
Thank you for explaining!
If you've contacted GTK about upstreaming your patches, what was their response? I'd be surprised if they didn't want to.
If you've contacted GTK about upstreaming your patches, what was their response? I'd be surprised if they didn't want to.
I interact regularly with GTK+ developers, and have been a regular contributor to GTK+ on OS X. They don't want our patches - they are very specialized and intended to deal with cases in Ardour that are not really a part of ordinary desktop apps. GTK+2 is now in maintainance mode anyway.
I think this is a great method. People always want more Open source software right? Look at this a different way, if you can't charge money for it to be OSS then it will have to be closed source right? (Advertising 'nstuff, I don't think that pays well...reddit...)
Just build your own binary if you don't want to pay. You can't really complain when they're giving the source code to you for free.
Yes you can, but that's beside the point. For a complicated application like this there obviously is value in both the source code and the pre-built binaries. I think people would be a little less annoyed if this didn't seem to be copping sales techniques from sketchy outdated proprietary business models (Prices not posted up front? Free version has time limitations??) and instead did something that was more sustainable. What this would be, I'm not quite sure of. Part of the problem probably is that desktop applications are not really a big market anymore. Maybe they should run a proper marketplace for free (as in freedom) audio plugins?
There is no price "up front" because you get to define the price (the model is taken from Radiohead's release of "In Rainbows", actually). What non-sketchy model do you have for a demo version? We used to make one that simply didn't save your plugin settings, but then realized that users could accidentally destroy an existing session like this. So we switched to "silence after 10 mins; ask for more time; silence after 5 mins; ask for more; silence after 2 mins; ask for more; silence after 1 min; ad infinitum". If you've got a better for how to create a demo copy that has some incentive for the user to change to the full one, I'm all ears.
And as you note, you don't know what the "something that was more sustainable is", whereas I've been doing this for 16 years, and have been through almost every "how to make money with open source" idea that there is. The vast majority don't apply to niche software, even on the odd occasion that they work for some other things.
I've made a living (of some kind) from working on Ardour for nearly 8 years now, and worked on it without need of income for 8 years before that. I think i'm
And as you note, you don't know what the "something that was more sustainable is", whereas I've been doing this for 16 years, and have been through almost every "how to make money with open source" idea that there is. The vast majority don't apply to niche software, even on the odd occasion that they work for some other things.
I've made a living (of some kind) from working on Ardour for nearly 8 years now, and worked on it without need of income for 8 years before that. I think i'm
Personally as a fellow free software developer, I take whatever opportunities I can to look closer at what value the software is really providing for the user. Is your primary user actually interested in the freedom and community the software provides, or are they just looking for "Pro Tools on GNU/Linux" with a low price tag? It's probably a combination of the two for most users, and as you have found there is tons of tweaking that can be done to optimize for the middle-ground. I personally choose to lean more towards optimizing for freedom and community, but the downside to this is it requires more infrastructure to support it.
From the download page it looks like your anchor point is a one-time $45 for unlimited upgrades. This is already fairly cheap for DAW software, but I would be interested to know which of your pricing options actually does generate the most revenue. That would probably give you clues as to how to build a stronger free (gratis) version that doesn't reduce overall value for the user. Subscriptions being popular means you can probably consider paid add-ons and services. User wants to use proprietary plugins? It's added maintenance costs, make them pay for it. One-time purchases being popular means you probably need to pursue sponsorships. Unfortunately I don't know a good way to do this at scale without either A) embedding obnoxious advertising, or B) finding generous corporate benefactors. Everyone obviously wants option B and option A sucks for everybody. Whoever can find the equilibrium in between these will get rich.
I also want to add that I tremendously respect what you're doing and how far you've come, and that I probably would not be a musician if Ardour did not exist :)
From the download page it looks like your anchor point is a one-time $45 for unlimited upgrades. This is already fairly cheap for DAW software, but I would be interested to know which of your pricing options actually does generate the most revenue. That would probably give you clues as to how to build a stronger free (gratis) version that doesn't reduce overall value for the user. Subscriptions being popular means you can probably consider paid add-ons and services. User wants to use proprietary plugins? It's added maintenance costs, make them pay for it. One-time purchases being popular means you probably need to pursue sponsorships. Unfortunately I don't know a good way to do this at scale without either A) embedding obnoxious advertising, or B) finding generous corporate benefactors. Everyone obviously wants option B and option A sucks for everybody. Whoever can find the equilibrium in between these will get rich.
I also want to add that I tremendously respect what you're doing and how far you've come, and that I probably would not be a musician if Ardour did not exist :)
> there obviously is value in [...]
> the pre-built binaries
- August goal: US$6200 (US$74.4k/yr)
- Total till now: US$2923.52
If you're into Linux/OSX audio (and now Windows, with Ardour 5!) and can afford it, I encourage you to donate :) . See the "Ardour Finance" sidebar of the linked post.
[1] https://community.ardour.org/node/8288