Ardour 7.0
ardour.org
ardour.org
[EDIT: if you can work with playback only (e.g. during editing or mixing), we also have a PulseAudio backend on Linux that will (like JACK) also talk to PipeWire. ]
You can choose to pay us for the service of building it for you, or if you like, providing a ready-to-run version that we can actually support. That revenue allows myself and other Ardour contributors to work on Ardour as a way of making a living.
what was your motivation to start this project?
how do you use ardour yourself?
do you have any music to share ?
I don't use Ardour much myself. When I make music, I mostly use the amazing VCV Rack or its slightly-more-FLOSS fork, Cardinal
As for music, not really but last December I did release this: https://pauldavismusic.bandcamp.com/album/suspended-generati...
There are zero plans to ever move to GTK3 or GTK4 or GTKN.
There are dreams & aspirations to drop our use of GTK and fall back on GDK (just a window & event abstraction), but this is not on any timetable because it means reimplementing text-entry, menus, tree/list views and the file browser.
One major feature that gtk3+ (or SDL2) brings is Wayland compatibility.
We did it once before, from GTK1 to GTK2, which should have been easy. And indeed, the actual GUI toolkit switchover was relatively easy. The problem is that along the way, you keep running into other issues and ideas. We likely could have done GTK1 to GTK2 in a month, but it took nearly a year.
We have no need of traditional desktop GUI toolkits (or SDL) except for the 4 widget classes I mentioned. We have our own internal canvas-based "toolkit" that is Cairo-based, and thus only requires a window+rgba-buffer+event abstraction.
what tips would you give me for making ardour feel a bit more familiar? i understand that’s a very vague question, and a vague response would be justified :)
CLAP doesn't really much for an Ardour user that isn't already addressed by LV2 or VST3, so although we do want to support it, it's not really on any critical path (other than wanting to support the general move to a not-owned-by-one-company plugin API).
Running this sort of thing in a browser has become more and more feasible, but I still consider it fundamentally a broken idea. Even if the browser environment started to offer sufficient low level OS interaction (e.g. setting relative real time thread priorities, using SIMD correctly for metering and gain control, and lots more), I can only really see one reason to want to do this: ease of "delivery" of the software to the user.
Porting the 80+ libraries we use to wasm is no laughing matter, and it would be even harder to run plugins, since each of them would have to be ported by their respective developers (in the case of proprietary plugins. A browser based version that could not run Kontakt or Valhalla Shimmer would be a significant step backwards for most serious users.
However, you can already run Cardinal (the FLOSS-ier fork of VCV Rack) in the browser, so at this point it's anyone's guess where this idea might lead us.
2. If you're doing in-the-box composition, every sound you work with probably comes from a plugin. So the idea the plugins are mostly used only by pros is not really true. Synth choice is a hot topic and highly subjective issue, I don't think people would want to be heavily constrained there.
3. "quick editing" is already available online. Not much point with us trying to compete with that.
The other day I bought Bitwig because I was looking for this exact thing on Linux. I don't regret it one bit, but it's amazing to see the beginnings of an open source solution to this! Hats off to the contributors who pulled through and made this happen.
JSFX can also be run in most DAWs using ReaJS, a JSFX VST host written by Cockos (not updated in a while, so some recent features of the language won't work), or another similar thing called YSFX.
Playtime probably uses Reaper-specific API calls and UI manipulation, but why the author chose to write a Reaper-specific VST instead of a plugin, IDK.
They aren't VSTs but that's my point. A "Reaper plugin" to the community usually means a JSFX plugin.
Playtime is a VST plugin, not a JSFX plugin, but it also relies on Reaper specific API calls making it incompatible with other DAWs that support VST.
It matters because you'll find it in the VST section of your Reaper plugin list and I believe Steinberg also requires you to use the VST branding on any plugins using the VST SDK
VST isn't an open plugin format and it doesn't guarantee compatibility across all hosts. It's a source-available format owned by Steinberg who grants financial free use of it (but not free use in the FOSS sense)
Were you caught in the Bitwig drama around the release of their plug-ins last week? ;)
Most recent incident
https://www.reddit.com/r/Bitwig/comments/nvikhf/psa_dont_ope...
https://www.reddit.com/r/Bitwig/comments/nvhy81/bitwig_rever...
The thing with the licensing server has been fixed. I tried that by turning off my router. No session closing and no data loss whatsoever.
It's actually a different issue. If the servers are completely down, or inaccessible (blocked or you're actually offline) it uses the offline license check and works fine.
If you're online and the servers are online but having issues, like returning a status 504, your local license gets revoked. Even if you chose offline activation during installation it still tries the online activation method every few minutes. If there is a server response but it's not status=200 Bitwig considers it a failed license check. Offline activation checks will then no longer work until their servers give you a good response.
Glad to see they've added a clip based workflow, makes it a lot more useful for the way I do my sequencing and arranging.
What motivated you writing such complicated application?
P.S.: I have the GUI layout and I don't care what people say about GTK!
A longer version is here: https://discourse.ardour.org/t/ardour-20th-birthday/102333
Ardour is awesome and shows that specialized niche software can compete or even out-compete commercial proprietary software (like QGIS in the GIS space).
I hope it will be around for a long time and it's a nice piece of software, thx Paul.
i'd like to hear more about that.
Don't ask me why my fingers typed "have" instead of "love" lol, I have no idea! O.o
Ardour -Audacity Alternative to Record, Edit, and Mix on Linux, OS X and Windows - https://news.ycombinator.com/item?id=27740936 - July 2021 (55 comments)
Paul Davis, lead developer of Ardour on fixing big Linux audio issues - https://news.ycombinator.com/item?id=23739517 - July 2020 (41 comments)
Ardour 5.9 released - https://news.ycombinator.com/item?id=14347758 - May 2017 (46 comments)
Ardour 5 released - https://news.ycombinator.com/item?id=12281137 - Aug 2016 (64 comments)
Ardour 4.0 released - https://news.ycombinator.com/item?id=9403131 - April 2015 (1 comment)
I installed Ardour and spent a couple of hours trying to get Jack to work or something like that and gave up.
Ardour is a digital audio workstation, which mostly implies that it is a non-destructive, non-linear system. Edits in Ardour do not change any of the media data on disk (everything is done with meta-data). Ardour is designed to handle track counts that Audacity could not dream of (100+), does realtime FX processing (coming to Audacity in the next version) rather than having to process the data and write a new file on disk, and is generally much more capable for handling multi-track audio.
Each one has its place. If you are really just editing an audio file, Audacity is likely to have less of a learning curve. If you involved in music creation or composition or recording, Ardour is much more likely to be the appropriate tool.
Not suggesting this is any fault of Ardour's.
But yes, it is true that to some extent, there was a tradition from the late 90s to the 20-teens to create synths as standalone apps for Linux, connected via JACK.
That is really going away now, and you can run U-he synths, Helm, Vitalium, Serge and many others as plugins just like you do on macOS and Windows.
And of course there are bleeding edge lessons learned, applied in things like monome, etc.
Congrats on shipping
I kept my subscription for ardour, though, because I think the project is awesome.
Sadly now I've grown used to another set of quirks (reaper's), so switching back seems quite unlikely. Still gonna keep that subscription running...
sudo dnf install ardour6 lv2-calf-plugins-gui ladspa-autotalent-plugins lsp-plugins-lv2 lv2-zam-plugins lv2-synthv1 lv2-amsynth-plugin
If you'd like, you can listen to myself (lead dev of Ardour) spend 2.5hrs chatting with Justin Frankel (lead dev of Reaper). It won't do much to answer your specific question, but might reveal that the similarities in our development processes and history and goals are much broader than you might expect: http://adc.equalarea.com/2022/02/07/adc1/
If you're a user of Ardour, why would our choice of GUI toolkit have much impact on your use of the program?
Regarding GTK, I could never stomach the specific "feel" that it has, and it's also been incredibly buggy for me on platforms other than Linux, and I use macOS and Windows a lot too. I haven't found a single GTK app that I can tolerate using on Windows or macOS so far. I find QT a lot better in that regard.
I was a heavy user of Inkscape (GTK) back when there were no free alternatives, but when Krita (QT) matured I switched to it and never looked back.
Hard disagree. DAWs like Logic, Ableton, and Bitwig have consistent, straightforward, and (given the amount of data) relatively uncluttered UIs. The open source or cheaper DAWs, like Ardour and Reaper, are a veritable explosion of inconsistent and different sized widgets, fonts, and styles. Reaper also apparently likes massive walls of random text for its menu system too. This is only too typical of open source software: there's no UI designer who can rein in the chaos.
It's fine to say "I don't like (Ardour|Reaper)'s GUI, but I do like Logic, Ableton and Bitwig". There's not much point trying to go beyond that. I get email from about 1 person a week, with about a 50/50 chance of either "I used Logic/other-DAW for years, but Ardour is so much better looking and easier to use" or "Ardour is a piece of shit and ugly as hell, nobody can use this crap". Which is pretty great hint that large swathes of DAW UI/UX design remains extremely subjective and path dependent.
So do you have a professional UI designer or not, and who is he?
I think UI design is all about being consistent across modes, being tolerant, making common things easy to do and easy to discover while still making the less common things possible. I think it's a pretty well understood field at this point. I do not think it's about prettiness or visual consistency, but visual consistency is certainly a signal that tells us that the other elements in the UI design may be lacking a designer's touch. So let's look at that.
Let's take this image for example:
https://ardour.org/images/retina_no_plugs2.png
I count no less than eight different fonts and font sizes on this screen. Use of whitespace throughout is terrible: for example, look at the placement of the red light snugged up right next to the "Lock" button rather than the Iso button. Speaking which, I presume Iso means "Isolate" while "Grp" means, well, let's assume it doesn't refer to the Grp A4 Synthesizer. Why do you shorten in some ways by removing vowels, and in others by brute truncation?
You also have literally dozens of different button heights. Consider just your faders. Put aside the giant red button. The R/L pans are 32 pixels tall. The In button is 38 pixels tall. The Lock button is 36 pixels tall. The Solo button is 42 pixels tall. The buttons at the bottom are 32 pixels tall. For no reason at all it seems.
You also seem to have tons of different widget widths. Let's consider the VU meters. The Meterbridge meters are 28 pixels wide: the Mixer meters are 24 pixels wide, and its stereo channels are 14 pixels wide (and with completely different dB markings as well) The per-instrument meters at the far left are 16 pixels wide The stereo meters above them are for some reason 10 pixels wide, and together they're 22 pixels wide and so don't line up with the mono meters below them. And finally the global stereo meters up top are 28 pixels wide. What?...
Text styling, justification and clipping is just kooky. Look above the second fader. Vocal, 2, and 0 (which looks like the null set, not a zero, due to weird width) are all centered. Then Fader and AuDynamicsPro are left-justified (And AuDynamicsPro is cut off because it's not getting resized). THEN all the parameters underneath (compression threshold -- again cut off in an ugly way, headroom, expansion ratio, etc.) are all centered again. And they are for no good reason lower-case only. So you have both capitalized case, lower-case-only, and upper-case-only strewn throughout your layout.
To the left of the fader you have "Strips" and "Show". The Show checkboxes are almost invisible thanks to the dark-charcoal-on-black color scheme. Also thanks to your nearly invisible charcoal-on-charcoal scrollbar, you can't read the strips. What's "Claps F"? Why is the "+" so gigantic,and why is it gradiated when no other icons are? I presume the divider can be expanded, but again it's nearly impossible to tell due the charcoal-on-charcoal.
Why are your In, Out, Solo, Audition, and Feedback buttons different colors from the other ones? Why are some of your icons antialised, but others (like the thing to the left of the scissors, or the thing to the left of "No Grid") not? Why are the console buttons (play/record/etc.) smashed together horizontally into thin strips, rather than giving them the standard width afforded to buttons of this importance? At least you could make them square to match their icons. Why is your Tempo and Meter in an incomprehensibly small font? Why do you have two different green colors for fonts?
I am not a big fan of Ableton (say). But its interface is more consistent, much less busy, and much more approachable than Ardour. This is the hallmark of open source software: it tends to lack a hegemon who will sit down and (1) remove features to simplify the interface and (2) force a consistency in design and modality on the software. I will say that what I don't like about Ableton is that it tends to have a lot of mystery-meat interface widgets which don't explain their purpose. But at least they're consistent. :-)
Now Ardour is FAR better than the interface nightmare that is Reaper, a veritable explosion of every single interface style, coupled with a seeming lack of understanding regarding how menus work best. Reaper's interface is objectively bad, full stop. Now there might be people who love it, but I'd wager that's primarily because those people have ego investiture in the product, and ego investiture comes with blinkers. We get heavily involved or invested in a product and it becomes our identity. This should never be an excuse for making a poor product. And compared to practically everyone else out there, Reaper's interface is really, really bad.
I always liked Reaper's UI best. Am I objectively wrong?
However, you could have started with a screenshot of something current instead of 7 years old. Several if not many of the issues you've mentioned have already been addressed.
The problem with the UI/UX paradigm of "making common things easy to do and easy to discover while still making the less common things possible." in the context of a DAW is that what's common and less common depends a lot on workflow.
Specific details;
> Why are your In, Out, Solo, Audition, and Feedback buttons different colors from the other ones?
In, Out and several other buttons are tri-state, not bi-state, to indicate, for example "muted because you soloed something else" rather than "not muted" and "muted because you muted it". The Solo/Audition/Feedback buttons are global indicators that also function as buttons.
> You also have literally dozens of different button heights.
Vertical space is at a premium in a mixer-style layout, so many buttons are sized to fit their contents rather than have consistent sizing. And in general, we eschew "all buttons should be the same size" anyway, because we want to prioritize some and deprioritize others.
Ableton is much less busy, but also presents way, way less functionality in their mixer (compared to Ardour's, or a large scale mixing console, it's almost a toy). You can certainly argue that it offers the right level of functionality for most people, and that busying it up is a negative for most users. I'm not even sure I'd disagree with you, but we've tried to build software for the sorts of people who are comfortable with large scale mixing consoles (or would be, if they could afford one), rather than bedroom producers who get just what they need and not much more.
> Why do you shorten in some ways by removing vowels, and in others by brute truncation?
22yrs of user feedback, mostly.
> And compared to practically everyone else out there, Reaper's interface is really, really bad.
Although your explanation of why this might be could have some truth, the sheer number of people who love Reaper's interface really argues against the claim that there's some sort of "objectively bad" here.
> Then Fader and AuDynamicsPro are left-justified (And AuDynamicsPro is cut off because it's not getting resized). THEN all the parameters underneath (compression threshold -- again cut off in an ugly way, headroom, expansion ratio, etc.) are all centered again.
"Fader" and "AuDynamicsPro" are processor (plugin) names. The centered texts are parameter names (indicated here by justification, not just color), and the actual text shown there is based on the names assigned by the plugin, not by Ardour. We do not ever resize-text-to-fit, which I consider appalling UI design.
> Why are the console buttons (play/record/etc.) smashed together horizontally into thin strips, rather than giving them the standard width afforded to buttons of this importance?
Because a large fraction of the user base will use either (a) a control surface of some type to control these, or (b) keyboard shortcuts (the ubiquitous space bar, for example). Because of this they are not actually very important when it comes to mouse-ability, but play the role of indicators more of the time.
I'm really looking forward to trying out the new clip launcher and the smart ripple editing. I think Ardour just might be the sequencer that all the outboard gear I've accumulated in the meantime is waiting for. I definitely hope so! I guess I just gotta wait a few more days for my distro to upgrade the package (https://github.com/NixOS/nixpkgs/pull/196290) - but that's completely fine.
What I'd like to ask is whether you consider important the issues that I've pointed out on this screenshot (from 6.9):
1. IMHO, the grid lines being Too Damn Bright is hands down the most jarring thing for any newcomer to Ardour. Basically, there's too much contrast on the very thing that delineates/delimits empty, user-editable space, relative to the contrast in screen areas that contain fixed UI controls. It just creates the impression of a barrier in the wrong place. Changing the line color from 100% white to 100% black would be at least a 200% improvement in terms of more betterness; a slider from 100% black to 100% white would bump that up to 300%.
The rest is mostly 1px misalignments that just sort of add up:
2. Top row of pixels in the menu bar is not active. So in full screen if you move the mouse all the way to the top edge of the screen the menus don't work. You can see this when opening a menu - GNOME didn't let me take a screenshot with a menu open lol
3. The 4px gradient border causes the "transport" and "editing" toolbars to look very misaligned.
4. The above border ends a few pixels above the "scrollbar/overview". Apparently there's a dragging handle there - but no hint that it's there.
5. These are the only toolbar buttons that don't have a border. If this is meant to signify that the button is inactive (why does "solo" behave differently from the others?), it would benefit from also making the text a tad dimmer.
6. Icon noclips out of the button.
7. Why the monospace here? It's not aligned to anything.
8. Separators would benefit from either being more prominent, or just being blank spaces. All separators except the one that the arrow points to have N pixels to one side and N+1 pixels to the other. Button text is also 1 pixel below the center of the button (and below the baseline of neighboring labels).
These things are noticeable, and annoying, on a 24" 1440p monitor at 150% zoom. Is this due to the scaling or something else? It simply looks slightly unappealing and "broken-ish", which does not do justice to the underlying engineering effort.
I think this problem plagues virtually all native GUI apps based on FOSS toolkits, and hampers migration away from proprietary solutions, to a degree that is often underestimated. I have some experience trying to get people to migrate to FOSS solutions, and I realize that it's an uphill struggle against BigCos that have whole design departments and can afford to condition people as to "what things should look like".
Computers are scary enough beasts as it is - it's too easy to present either too much or too little information to users, who just expect things to be "intuitive" (i.e. learned helplessness). People who have looked proprietary apps all their lives are prone to viscerally rejecting a solid FOSS product that might even be a better fit for their workflow, just because of superficial glitches like the ones I listed above.
One funny effect of this: users might even identify the problem at the wrong level. They may object to the semantics of the interface ("I don't understand it"), while the problem actually is on the level of ergonomics ("it doesn't feel right"). Maybe they don't want to seem petty.
I know my way around Ardour and the general Linux audio ecosystem well enough to get things done with it, but the reason I don't bring Ardour with me everywhere is ... basically the grid lines and alignment! Please tell me there's a dotfile for that, or that a fix is on the roadmap? :-)
I realize this might be just my "OCD" speaking; I'm still recovering from the heartbreak that was Qt's default font rendering (maybe still is; I think Krita started to look fine at some point, I don't use many other Qt apps...)
But I feel like Ardour might be missing out on a big chunk of useful feedback from people that don't even engage with the product deeply enough to provide feedback - because of admittedly silly things (like 10 individual widgets on the main screen being 1 pixel off) that make them automatically disengage.
Some might say that such users don't have a serious attitude, so why would they be owed any consideration? I believe proprietary software has conditioned them to believe that their opinions don't matter anyway - which in the case of FOSS couldn't be further from the truth, but then again how are they supposed to know that.
So, here I am seriously engaging with this topic in their stead. Sorry for not filing this on the issue tracker I guess . (1) its Web UI basically creates the same impression and (2) I'm weird about creating accounts, that's 1 external and 1 internal reason that combine into nudging me in the direction of speaking up here instead :-)
We're not going to get into a discussion if this useful feedback on HN, but I will file it in our bug tracker. If you'd like to participate in a discussion / the resolution, you know what to do.
> But I feel like Ardour might be missing out on a big chunk of useful feedback from people that don't even engage with the product deeply enough to provide feedback
this is a liability for all software, especially large, complex, creative-tools style software.