"Some people will no doubt laugh at a few of these "new features", given that they've been in some other DAWs for 20 years or more. That's OK — we laugh too when we see other DAWs finally adding things that Ardour could do in 2005."
I started using Ardour in 2007 and quickly transitioned our studio to it in a big move to Linux for audio production. I'll be excited to reacquaint myself with it later this year on the first analog restoration I've accepted in almost a decade.
The extent of its wonders escapes me now, but I recall with jack+ardour, the new lowlatency/preempt kernel, and some tcp/ip stack fun, we were able to get 40ms network audio latency on commodity hardware, vastly expanding our field processing workflows. Sort of how you can walk out of any venue today and immediately purchase an SD card of the event, we could produce MP3, CDs, and live webcasts of events, ready within minutes of closing with nothing more than a laptop, usb sound card, mics, and the internet.
I also had a little trick for transcription; shorthand with macros! Eventually, I could type them all one handed. Today, you can just pipe through whisper and have subs in every format and language. What an incredible time to be alive.
My lessons learned have been that free, open source software is amazing, and if you don't know something is supposed to be "hard", it can't stop you. Don't let greed or pride make you withhold from yourself.
I'm not a musician, but I've been happily using Ardour to edit a podcast for many years now (paying for a subscription the whole time too) and I really like the workflow I arrived at with it.
One particular feature I like is the ability to edit while playing the audio at 2x speed, which I use to do a quick first pass where I remove obvious things like dead air, coughs, uhms, etc., before doing a second pass at 1x looking for finer details to fix. However, I've found that this feature has been worsened a bit since v6, so I've been stuck at v5 this whole time despite the many new releases. Every time a new version comes out I try it out immediately, but so far v5 has been the superior one for my particular workflow.
I'm not complaining though, for as long as Ardour 5 still runs on my computer I'll be a happy user, and I'm very grateful for Ardour's existence, but I wonder if anyone else uses it the way I do and if they've had the same issue with newer versions.
I'm glad you've been able to see this issue fixed, but I'm wondering (genuinely) why you didn't bother reporting this issue, which kept you from upgrading software that you were paying a subscription for (!) for over three years (Ardour 6.0 was released in May 2020). As you can see from the thread, the Ardour developers were happy to improve the software based on your feedback.
In general (with a few exceptions), open source developers are happy to receive bug reports on their software. It's not like the situation in the Windows freeware world where software is just dumped on a web forum somewhere and reports go into a black hole.
I thought that my use case was too particular, since Ardour's focus is in music production, and that made me shy away from reporting it as I wasn't even sure I could call it a bug. But you're right, I should've.
In Ardour 5 I am able to simply slide the playback speed slider ("shuttle speed control") to start playing at >1x speed, and after releasing the mouse button it keeps on playing at that speed.
In v6+ the sliding part still works, but upon releasing it the slider springs immediately back to 1x, so I can't easily select a playback speed and keep it going. As a workaround there's the varispeed option, but for me it's not as intuitive (it uses semitones instead of "Xs" as its unit), and feels much less flexible. I could probably live with it if I was forced into it, but I much prefer v5's behavior.
Congratulations Paul. For those who don't know, the creator of Ardour is active here and was (historically) very active and helpful on Linux audio lists. I learnt a lot from dicussions on there on the intracies of audio programming. While my work has shifted from Linux audio to Max/MSP these days (I wrote Scheme for Max), in the mid 2000s linux audio hacking was my gateway to the world of programming, eventually leading to a very productive career in tech. Ardour was always a huge "hacker inspiration" to me, it's a truly shining example of how much one smart and dedicated programmer can do. I'm very glad to see it still going strong.
I still feel like track/bus groups, VCAs, and now ad-hoc groups are three different ways of doing roughly the same thing. Are there plans to unify them into a single concept, maybe?
(I know that especially VCAs are different here, but in the end, they are groups of groups if you squint hard enough, are they not?)
No, VCAs are quite different from the other two. They represent an external entity (the VCA) that can be used to control other entities, and they are mixer (signal flow) related only (i.e. have no impact on editing).
Persistent and quick groups are definitely related; we've already a few trenchant observations about what we've done with quick groups, and we will work on taking them into consideration as we refine how this works. But fundamentally, I see persistent groups and quick groups as orthogonal, and their main job is not to interfere (too much) with each other.
What was the main reason for keeping the select-groups from applying to control surfaces? I'm not sure what would be the point of multi-selecting otherwise.
As an aside, is there any way I can add functionality to a control surface (that isn't writing C)? I use a behringer X-Touch (heavily) and moved to Reaper because there were plugins that provided much deeper integration with my X-Touch (which as a result has me working a lot faster in certain areas).
We're still debating the control surface decision. There are two reasons for leaving things alone:
1. hardware surfaces have had different use conventions for a long time (certainly things that look like mixing consoles). They are effectively multitouch devices, and human interaction with them just isn't the same as with a mouse & GUI.
2. for Mackie Control Protocol devices, we already provide a nifty multi-target action there where you just press and hold one eg. solo button and then press another, to apply it to the range that was pressed.
We do not providing scripting for developing control surface support. I've written extensively about my thoughts on Reaper's scripting [0] and I remain conflicted by the questions it raises. There's nothing that can be done in Reaper via scripting that can't be done in Ardour via C++, and a huge amount that theoretically could be done in Ardour via C++ that cannot be done in Reaper. I know this is not a satisfactory answer for people who do not want to master (a) C++ (b) the build environment.
Totally minor feedback in case you value this kind of feedback: the website’s layout is freaking out on my iOS Safari. I can scroll sideways like four page widths and then see nothing at all. Same with the front page.
I've used Cubase historically, but started and now have transitioned back to FL Studio since I can get my thoughts and ideas out quicker than in Cubase.
I've seen Ardour for a long, long time but haven't ever tried it. What, if anything, would I be missing by switching? I primarily do composition, so lots of VSTs etc.
FL Studio is a very, very different sort of DAW than, well, just about every other DAW (including Ardour). If you were moving from Cubase, Logic, Studio One, ProTools, Digital Performer etc., then I'd say you would miss very little by switching to Ardour other than some of the builtin plugins for those DAWs.
But if you have become used to the FL Studio workflow, Ardour (and the list of DAWs above) are likely to feel clunky and unproductive.
MPE: nothng is required to record and playback MPE, it's just MIDI 1.0. There's no "nice" way to edit MPE at this time. I can't say right now what priority we attach to this.
I've just recently started using Ardour after wanting to do so for years. Once you learn the basics like tracks vs. busses and how to use EQ/compressor/limiter plugins it stops feeling daunting. Unfa's tutorials on YouTube were a lot of help.
The screenshot features the excellent Surge synth. Check it out if you don't know it, it's an excellent sounding synth with a gorgeous oscillators section.
There was a time when Sylenth and Serum-quality synthesizers didn't exist for free. Back then, shit like Serge and Helm were really the best you could rely on. Maybe a few free U-HE plugins or your DAW defaults. Today's producers are downright spoiled with so many excellent free options!
It's three times the size of the DAW itself, and unlike the DAW it requires using an installer during which it asks for admin password. Wow. Wonder what happened to "just drop this file into that dir" README.txt...
Users want an installer. You can see what the installers are doing by looking at the scripts in the repo (this is an open source project). Admin permission is necessary to write to the Global VST folder. You can direct your "Wow" at Steinberg if you want. The spec was recently updated to allow for a User install location which has been considered: https://steinbergmedia.github.io/vst3_dev_portal/pages/Techn...
> If you try to automate the task of adjusting the tempo to follow a human performance (e.g. by tracking transients/onsets), you invariably end up with a mess... With Ardour 8.0 ... switch to the Grid tool (shortcut: "y") and simply drag the grid (lines) to fit the measure and beat onsets that you feel while listening.... The resulting grid accommodates the way people actually perform, rather than how software sometimes thinks they ought to. <
Wow. THIS is something that's been needed for > 20 years. A lot of music has gotten poorer because of the mechanality of grids. Human tempos vary naturally (slightly at least) all over the board. (If you doubt that, drop a golden oldie into a DAW and just try to adjust the grid.)
Neither "Quantize" and "Humanize" helped. Tempo changes like ritardando, accelerando, rubato are essential for the musicality of real performances. Not that the grid/click-track HAS to have any effect on any one part, but it very much complicates, e.g., automated/samples parts.
Human performances vary tempos according to feelings. This feature may be manual, but it sounds like progress.
[QUOTE follows]
"A nice sort of music would result from such playing. Something like the singing of a good vocalist accompanied by a poor blockhead who hammers away in strict time without yielding to the singer who, in sheer despair, must renounce all artistic expression." - Constantin von Sternberg (1852–1924) (c. 1920). "Tempo rubato, and other essays".
Ardour is GPLv2 open-source, but they still do somewhat pointedly attempt to dissuade you from building from source ¹).
Now, I fully understand why. And I think charging for pre-built binaries is a totally valid way to attempt to finance an open-source project. The amount they're asking certainly is a pittance compared to the commercial offerings.
LMMS is a great little program too but in much the same way that a professional mix table is less 'friendly' than a four track recorder.
Both have their uses. What bugs me about LMMS is that it is hard to use its output in any other way than just to send it to your devices, interop with other software isn't all that good unless it is on the plugin side.
And neither Ardour nor LMMS come close to midieditor for the editing of raw midi files, and that's a shame because midieditor isn't very well supported and a bit fragile (it crashes with alarming regularity).
Readit News
"Some people will no doubt laugh at a few of these "new features", given that they've been in some other DAWs for 20 years or more. That's OK — we laugh too when we see other DAWs finally adding things that Ardour could do in 2005."
this made me laugh :-)
The extent of its wonders escapes me now, but I recall with jack+ardour, the new lowlatency/preempt kernel, and some tcp/ip stack fun, we were able to get 40ms network audio latency on commodity hardware, vastly expanding our field processing workflows. Sort of how you can walk out of any venue today and immediately purchase an SD card of the event, we could produce MP3, CDs, and live webcasts of events, ready within minutes of closing with nothing more than a laptop, usb sound card, mics, and the internet.
I also had a little trick for transcription; shorthand with macros! Eventually, I could type them all one handed. Today, you can just pipe through whisper and have subs in every format and language. What an incredible time to be alive.
My lessons learned have been that free, open source software is amazing, and if you don't know something is supposed to be "hard", it can't stop you. Don't let greed or pride make you withhold from yourself.
One particular feature I like is the ability to edit while playing the audio at 2x speed, which I use to do a quick first pass where I remove obvious things like dead air, coughs, uhms, etc., before doing a second pass at 1x looking for finer details to fix. However, I've found that this feature has been worsened a bit since v6, so I've been stuck at v5 this whole time despite the many new releases. Every time a new version comes out I try it out immediately, but so far v5 has been the superior one for my particular workflow.
I'm not complaining though, for as long as Ardour 5 still runs on my computer I'll be a happy user, and I'm very grateful for Ardour's existence, but I wonder if anyone else uses it the way I do and if they've had the same issue with newer versions.
In general (with a few exceptions), open source developers are happy to receive bug reports on their software. It's not like the situation in the Windows freeware world where software is just dumped on a web forum somewhere and reports go into a black hole.
How exactly?
In v6+ the sliding part still works, but upon releasing it the slider springs immediately back to 1x, so I can't easily select a playback speed and keep it going. As a workaround there's the varispeed option, but for me it's not as intuitive (it uses semitones instead of "Xs" as its unit), and feels much less flexible. I could probably live with it if I was forced into it, but I much prefer v5's behavior.
http://youtube.com/c/musicwithlisp
(I know that especially VCAs are different here, but in the end, they are groups of groups if you squint hard enough, are they not?)
Persistent and quick groups are definitely related; we've already a few trenchant observations about what we've done with quick groups, and we will work on taking them into consideration as we refine how this works. But fundamentally, I see persistent groups and quick groups as orthogonal, and their main job is not to interfere (too much) with each other.
As an aside, is there any way I can add functionality to a control surface (that isn't writing C)? I use a behringer X-Touch (heavily) and moved to Reaper because there were plugins that provided much deeper integration with my X-Touch (which as a result has me working a lot faster in certain areas).
1. hardware surfaces have had different use conventions for a long time (certainly things that look like mixing consoles). They are effectively multitouch devices, and human interaction with them just isn't the same as with a mouse & GUI.
2. for Mackie Control Protocol devices, we already provide a nifty multi-target action there where you just press and hold one eg. solo button and then press another, to apply it to the range that was pressed.
We do not providing scripting for developing control surface support. I've written extensively about my thoughts on Reaper's scripting [0] and I remain conflicted by the questions it raises. There's nothing that can be done in Reaper via scripting that can't be done in Ardour via C++, and a huge amount that theoretically could be done in Ardour via C++ that cannot be done in Reaper. I know this is not a satisfactory answer for people who do not want to master (a) C++ (b) the build environment.
[0] https://discourse.ardour.org/t/is-open-source-a-diversion-fr...
Totally minor feedback in case you value this kind of feedback: the website’s layout is freaking out on my iOS Safari. I can scroll sideways like four page widths and then see nothing at all. Same with the front page.
A short video if it helps: https://youtube.com/shorts/2dItDk_FtkI?si=WSsM2fgWR91IR7wU
I've seen Ardour for a long, long time but haven't ever tried it. What, if anything, would I be missing by switching? I primarily do composition, so lots of VSTs etc.
But if you have become used to the FL Studio workflow, Ardour (and the list of DAWs above) are likely to feel clunky and unproductive.
What about MIDI 2.0?
MIDI 2.0: no plans at this time.
There was a time when Sylenth and Serum-quality synthesizers didn't exist for free. Back then, shit like Serge and Helm were really the best you could rely on. Maybe a few free U-HE plugins or your DAW defaults. Today's producers are downright spoiled with so many excellent free options!
Dead Comment
If you don't want an installer, you can download the pluginsonly bundle on the release page and do it yourself: https://github.com/surge-synthesizer/releases-xt/releases
(e.g. C:\Program Files\VSTPlugins )
Wow. THIS is something that's been needed for > 20 years. A lot of music has gotten poorer because of the mechanality of grids. Human tempos vary naturally (slightly at least) all over the board. (If you doubt that, drop a golden oldie into a DAW and just try to adjust the grid.)
Neither "Quantize" and "Humanize" helped. Tempo changes like ritardando, accelerando, rubato are essential for the musicality of real performances. Not that the grid/click-track HAS to have any effect on any one part, but it very much complicates, e.g., automated/samples parts.
Human performances vary tempos according to feelings. This feature may be manual, but it sounds like progress.
[QUOTE follows]
"A nice sort of music would result from such playing. Something like the singing of a good vocalist accompanied by a poor blockhead who hammers away in strict time without yielding to the singer who, in sheer despair, must renounce all artistic expression." - Constantin von Sternberg (1852–1924) (c. 1920). "Tempo rubato, and other essays".
Now, I fully understand why. And I think charging for pre-built binaries is a totally valid way to attempt to finance an open-source project. The amount they're asking certainly is a pittance compared to the commercial offerings.
But LMMS just feels friendlier to me.
¹) https://ardour.org/building_linux.html
Both have their uses. What bugs me about LMMS is that it is hard to use its output in any other way than just to send it to your devices, interop with other software isn't all that good unless it is on the plugin side.
And neither Ardour nor LMMS come close to midieditor for the editing of raw midi files, and that's a shame because midieditor isn't very well supported and a bit fragile (it crashes with alarming regularity).