Hobbyist game dev here. Getting into audio and music effects has been fun but I constantly feel overwhelmed. I chose Ardour as my DAW (digital audio workstation) and have been excitedly working on learning. I also bought the book “ Writing Interactive Music for Video Games: A Composer's Guide” which has been very helpful at understanding high level vocabulary.
It’s a lot of work. I slightly enjoy it but boooooy is getting into audio and music pretty challenging. It’ll be good if I ever need to know what I’m talking about when working with others… in the future where I can dedicate myself full time to game dev… One day one day…
I don’t really have a point here. If anyone has any resources, tips, or recommendations on this subject let me know.
At the risk of sending you down a giant rabbit hole, the book Designing Sound is all about making programmatic sounds with Pure Data, and open source low-code programming environment available for all platforms. From what I've read, the book is considered a classic in the video game sound world. It's really good. Combine that with the Cipriani book on PD and learning Ardour would give you a very good learning path.
I recently dated someone in her 30s with a DMA, and she she told me how proud she was to know me because I was the first non-musician friend she's ever had. It's a very deep and insular world.
Pablo Casals famously replied when asked why he was still practicing in his 70s that he "felt like we was making progress", so don't let yourself feel inadequate.
Stuff like that sends me down rabbit holes and when I finally come up for air, I say, "Gee, now I see how people can build their entire career around this!"
In the Axiom Verge noclip documentary, the dev talks about how everyone is surprised about how he really made the whole game himself (except localization + marketing (and I imagine final testing but...)).
And he was like "people say 'even the music?' The music was the easiest part!!!'
It does make me feel like once you get into the right headspace and figure out how most of the tooling works all of this becomes quite smooth.
A light weight journaling of your learnings as you go along would probably be real beneficial to many (such as myself who has zero knowledge on the subject of DAWs and creating music effects for games). And since you said it’s very challenging maybe writing about it in small bite-sized learnings might make the process easier? Going from “I must learn all this stuff!!” to “let’s see what audio gems we pick up in our adventure today”.
Good point w/ journaling and maybe even preparing stuff to share. Right now it feels like trying to eat a whale whole. …That’s the beauty of doing something in a new (to me) domain though. Even if I don’t share, the practice of formulating how I would explain to someone is beneficial.
I've been making music now for 8 months and have absolutely fallen in love with it. I'd love to write music for a game, what kind of game are you creating?
Sounds like you’re ahead of me then! The game I’m working on off & on is a 32v32 moba. I want the gameplay of Heroes of the Storm but with the match size of a battlefield server.
I wish I could dedicate myself full time to the effort (and in fact I’m working with my financial planner to figure out a plan) but this is a side project that is prioritized behind a few things. I wouldn’t feel too comfortable collaborating right now since I would be unpredictable. I’ll keep you in mind for when that changes though!
Congratulations on the new release! I've seen some forum discussions on this in the past, and I'd imagine it's a frequently debated topic. However, I'd like to ask about the technical feasibility of implementing a feature similar to Ableton's 'Warp' within Ardour. I understand that Ardour and Ableton have fundamentally different architectures and that different DAWs can prioritize different workflows. Given the current state of the codebase and the development roadmap, I'm curious how realistic the implementation of BPM-synced time-stretching actually is or if it remains significantly outside the project's scope.
The biggest issue here is that the best library for doing audio warping (ZPlane) is not available to us. We already do realtime audio warping for clip playback, just like Ableton, using RubberBand (and might consider using Staffpad at some point, which we have available for static stretches).
However, following the tempo map is a very different challenge than following user-directed edits between warp markers, and neither RubberBand nor Staffpad really offer a good API for this.
In addition, the GUI side of this poses a lot of questions: do you regenerate waveforms on the fly to be accurate, or just use a GUI-only scaling of an existing waveform, to display things during the editing operation.
We would certainly like to do this, and have a pretty good idea of how to do it. The devil, as usual, is in the details, and there are rather a lot of them.
There's also the detail that having clips be bpm-synced addresses somewhere between 50% and 90% of user needs for audio warping, which reduces the priority for doing the human-edited workflow.
>do you regenerate waveforms on the fly to be accurate, or just use a GUI-only scaling of an existing waveform, to display things during the editing operation
just use GUI scaling, and only IF the prior is too challenging
You often want sample accurate waveform visualization when tuning samples that are time or pitch warped to set start and loop points at zero crossings to avoid clicks without needing fades.
Overwhelmingly, there's no such thing as a zero crossing. Your closest real world case is a point in time (between samples) where the previous sample is positive and next one is negative (or vice versa). However, by truncating the next sample to zero, you create distortion (and if the absolute value of the preceding sample is large, very significant distortion.
Zero crossings were an early myth in digital audio promulgated by people who didn't know enough.
Fades are always the best solution in terms of limiting distortion (though even then, they can fail in pathological situations).
There's definitely such thing as a zero crossing, it's where sign(x[n-1]) != sign(x[n]) (or rather, there's "no such thing as a zero crossing" in the same way there's no such thing as a peak). Picking a suitable `n` as a start/end point for sample editing is a judgement call, because what you're trying to minimize is the difference between two samples since it's conceptually a unit impulse in the sequence.
I don't think people who talk about zero crossings were totally misguided. It's a legitimate technique for picking start/end points of your samples and tracks. Even as a first step before BLEP or fades.
Theoretically, it makes sense (go look at any of the diagrams of what a "zero crossing" is online, and it totally does.
The problem is that sign(x[n-1]) != sign(x[n]) describes a place where two successive samples differ in sign, but no sample is actually has a value of zero. Thus, to perform an edit there, if your goal is to avoid a click by truncating with a non-zero sample value, you need to add/assign a value of zero to a sample. This introduces distortion - you are artifically changing the shape of the waveform, which implies the introduction of all kinds of frequency artifacts.
Zero crossings are not computed by finding a minimum between two consecutive samples - that would almost never involve a sign change. And if they are computed by finding the minimum between two consecutive samples that also involves a sign change, there's a very good chance that you'll be long way from your desired cut point, even if you ignore the distortion issue.
It really was a completely misguided idea. If the situation was:
sign(x[n-2) != sign(x[n]) && x[n-1] == 0
then it would be great. But this essentially never happens in real audio.
> Thus, to perform an edit there, if your goal is to avoid a click by truncating with a non-zero sample value, you need to add/assign a value of zero to a sample.
No, you (the editor, not an algorithm) look at the waveform and see where the amplitude begins to significantly oscillate and place the edit at a reasonable point, like where the signal is near the noise floor and at a point where it crosses zero. There's no zero stuffing.
This kind of thing isn't computed, a human being is looking at the waveform and listening back to choose where to drop the edit point. You don't always get it pop-free but it's much better than an arbitrary point as the sample is rising.
I mean, you could use an algorithm for this. It would be a pair of averaging filters with like a VAD, but with lookahead, picking an arbitrary point some position before activity is detected (peak - noise_floor > threshold)) which could be where avg(x[n-N..n]) ~= noise_floor && sign(x[n]) != (sign(x[n-1]).
> You don't always get it pop-free but it's much better than an arbitrary point as the sample is rising.
I agree with this, but that doesn't invalidate anything I've said. When you or a bit of software decide to make the cut at x[n], you are faced with the near certainty that the x[n] != 0. If you set it (or x[n+1]) to zero, you add distortion; if you don't, the risk of a pop is significant.
By contrast, if you apply a fade, the risk of getting a pop is negligible and you can make the cut anywhere you want without paying attention to 1 sample-per-pixel or finer zoom level and the details of the waveform.
Thanks very much, this sub-thread has been illuminating for me, and has the compelling quality of being obvious-in-retrospect. I now wonder what my MPC is doing, exactly, when I make an action at what appears to be a zero point. Thanks.
Well, I can't answer for @x42 (Robin Gareus) but for me personally the refactoring of the Editor code so that we could have multiple "editors" was both interesting and hugely challenging.
I didn't want to replicate the code we already had for the Editor, and figuring out to refactor this took a lot of time and experimentation and failures. Although there are still some rough spots, in general I'm very happy with how things turned out.
Clip recording was also a bit of a challenge. It uses an entirely different mechanism than timeline recording, and as usual I got the basics working in a couple of days, followed by months of polishing (and likely, quite a few more to go as we get feedback from users).
We have been running Ardour 9 for a while now during band rehearsals. Currently 12 channels that we record and monitor in realtime with some effects on top.
Thank you Paul, for all the years you've been doing this. For the patience and keeping subscription for your binaries affordable. For how you managed to keep it opensource, alive AND expanding.
You likely could not buy a single coffee with my lousy subscription contribution over a decade ago - the more I have respect for how it was developed.
I've got 9.0 running self built on Fedora 43; it's working OK, I have had a couple of crashes (which I can't figure out how to report);
a seg:
#1 0x00007f5085ea1663 in jack_port_type_to_ardour_data_type (jack_type=0x0)
at ../libs/backends/jack/jack_portengine.cc:71
#2 0x00007f5085ea346a in ARDOUR::JACKAudioBackend::port_data_type (this=0x1ac84ad0, port=...)
at ../libs/backends/jack/jack_portengine.cc:465
#3 0x0000000000e3c719 in PortGroupList::gather
which I think is a lack of cast check in port_data_type?
(from IOSelector::setup_ports -> PortMatrix::setup_global_ports )
I also got an assert in;
#5 0x00000000011fa927 in StartupFSM::check_session_parameters (this=0x3dcf00a0, must_be_new=true)
at ../gtk2_ardour/startup_fsm.cc:740
#6 0x00000000011f80d2 in StartupFSM::dialog_response_handler
(this=0x3dcf00a0, response=-3, dialog_id=StartupFSM::NewSessionDialog) at ../gtk2_ardour/startup_fsm.cc:267
I think this was opening an existing ardour project that I'd copied onto this machine and was the first run of ardour on this machine.
Bug tracker is at https://tracker.ardour.org/ (sorry that it requires a separate login, but hey, that's Mantis for you)
ps. if you downvoted this, you're welcome to offer support for the full 80+ external libraries in our build stack. Reach out here or at discourse.ardour.org ...
The problem is that not a single person has reported this before, so until it's confirmed as affecting the official builds from ardour.org, it can't be a priority for us.
Hi! I have been happily using Ardour as a hobbyist since version 5. At the same time I also started learning Pure Data. I was wondering how difficult it would be to implement a feature similar to "The Grid" from Bitwig. I’m not sure whether this could be done as a simple plugin, or if it would require much deeper integration with Ardour.
You can already load Cardinal as a plugin and get the full scope of is power(s) (or VCV Rack if you paid for the "pro" version). You just don't get the GUI "integrated" into Ardour, and its tied to a specific track.
We might do this via I/O plugins (an existing Ardour feature), which would make the inputs & outputs of Cardinal be just like your hardware. Lots of details to that sort of design, however.
There is also PlugData which could theoretically be handled in a similar way.
What we will not try to do is to implement Yet Another Software Modular Environment ourselves. Cardinal/Rack (or even PD) are approximately infinitely better than anything we could or would do.
Do you test on different kernel preemption models? If so, do you feel PREEMPT_RT really gives an advantage over full preemption with threadirqs?
(Cyclictest gives me between a 3x and 5x worst-case latency improvement depending on the background load, but I'm not nearly musically skilled enough to try a real-world test.)
We don't care much about "full preemption" because the only threads that have time-critical behavior are all scheduled in the SCHED_FIFO and/or SCHED_RR classes. If you had other workloads that could benefit from preemption without using realtime scheduling, then full preemption could be the way to go.
We haven't really tested this sort of thing for quite a few years.
Every set of release notes that's intended to double as a press release needs to involve the judicious inclusion of a blurb that immediately explains what the hell the thing actually is.
document.querySelector("#content .section-header + p").className = "date"
document.querySelector("#content .date + p").outerHTML = (`
<p>
We are pleased to announce the release of Ardour 9.0.
</p>
<p style="font-style:italic; font-size:smaller; margin:2em
4em">Ardour is a free and open-source digital audio workstation
app that works cross-platform on Linux desktops, Mac OS, and
Windows. Get Ardour or get involved with the community at <a
href="https://ardour.org/">Ardour.org</a>.</p>
<p>
Ardour 9.0 is a major release for the project, seeing several
substantive new features that users have asked for over a long
period of time. Region FX, clip recording, a touch-sensitive
GUI, pianoroll windows, clip editing and more, not to mention
dozens of bug fixes, new MIDI binding maps, improved GUI
performance on macOS (for most)...
</p>
`)
Hi! I recently (2 weeks) chose this software to invest time into in order to make music/sfx for video games. Do you personally use this software to create music yourself? Just curious!
Not really. My only released music is a single album at https://pauldavismusic.bandcamp.com/album/suspended-generati... which was made almost entirely with VCV Rack (Ardour was used for some pretty minimal editing). I've also used it for a short podcast series ("Audio Developer Chats") that is currently offline. I do try to talk to musicians and engineers almost every single day about what they're doing, however.
Ardour's great. I've been donating $4/month for enough months that I probably could've bought one of the fancier “professional” DAWs, but why bother when Ardour does it all?
A couple friends and I started a band a couple months ago and we've started to use Ardour + a Behringer UMC1820 for some basic recording work; it's wild how quick we've been able to get up and running with it (to the point where our only limitation right now is scrounging up enough cables to hook up all our instruments to the UMC1820). Create tracks, pick each track's input, arm tracks for recording, hit record, hit play, and make noises. Our lead guitarist is more familiar with Cubase, but I had him try out Ardour and he's already putting together recordings; just had to point him to a couple manual pages and he was off to the races with it.
Curious to see how quick 9.0 will hit Ubuntu Studio (which is what we're using in our practice room). Cool to see Ardour finally get a dedicated piano roll window (presumably ported over from MixBus?); even though it's neat to be able to do MIDI editing directly from the main editor window, having the option to focus on a specific snippet will be handy. And the continued improvements with the new cue-based flow will be cool to play around with (and maybe work into live performances once we've got enough material down solid for shows?).
Glad you're enjoying Ardour and thanks for supporting our work.
Things aren't often "ported over from Mixbus", though there are a few features that do start life there (the new perceptual analyzer is one good example).
The pianoroll stuff was started so that we could do clip editing. It appeared in Mixbus first because ... well, let's just say that there was some disagreement about when it was appropriate for that stuff to go public, and the release of Ardour 9.0 represents the ardour team's judgement on that :)
Ardour is very good and needs more attentions. My respects to the developers, I use it every day, and I am very happy with it and its community. I also like the paying / open source model, and I wouldn’t change it for a proprietary DAW 99% of the musicians use.
Is this similar to Ableton? Wanted to "create" music as a hobby, but don't really wanna pay for Ableton. I tried once https://lmms.io/ but didn't stick. Never heard of Ardour.
Ardour is not as focused on "in the box composition" (i.e. making music entirely on your computer) as Live or Bitwig are. It originated as something closer to ProTools or Logic or Digital Performer in the sense that it was focused on recording people doing stuff (blowing,hitting,singing,speaker,scraping etc. etc).
However, in recent years, we've added a lot of the stuff you need for "in the box composition" and many people do use it that way. There's (always) more to do, but it's fairly capable in this sort of workflow now too and will continue to improve over time.
Ardour has been around for more than 25 years.
Please be aware that almost any fully-capable DAW (everything named here except lmms) has a steep, challenging learning curve. Don't jump in thinking it will be easy.
Similar but not quite. One of the problems that you might face is a lot of tutorials are for Ableton, Logic, Cubase etc. It shouldn't actually matter, but you might find it confusing what you can and cant do if you are following what someone else is doing in another program. It’s like learning C# from a Java course. Once you understand the fundamentals it does not matter what you use within reason.
But I’ve used Ardour a long time ago and I don’t see why you couldn’t release music with it. Another alternative is Reaper.
if you mean you just want to make music and arent too bothered about recording then Cardinal is a free modular eurorack synth you could mess around with
or you use a VST host like Kushview's Element and load up on all the free VST instruments and effects that are out there. you would just need a midi keyboard hooked to it then or use Cardinal to generate note patterns
Ardour is top tier software. I've been _so_ excited for the "Cue Recording" feature. Until now I've had to resort to other software for live looping. Can't wait to give it a shot / use Ardour for "everything"!
Please use our forums to keep us in the loop if you have problems.
There's approximately 736 different workflows for this; the ones we've tested work as intended, but regularly we hear from folks who use a different one and something breaks ... we want to fix it.
You might wanna give Bitwig a try, it’s one of the best commercial DAWs available on Linux. You can record live loops, similar to Ableton (it was originally built by ex-Ableton developers)
I just setup my first little Linux home studio and Ardour is a large part of that. It's a great piece of software with an admittedly high learning curve for a novice like myself, but it's been incredibly fun learning.
GTK doesn't play much of a role in our GUI. When you're looking at most of the main tabs in Ardour (editor, mixer, recorder window, cue page) almost everything you're looking at is either our own Canvas or custom widgets. Still we do sit on top of GTK+ 2's basic infrastructure and still rely on it for the "big widgets" (file browser, tree/listviews, menus, color dialogs, text entry).
Some are, some have a layer between them called CairoWidget so that they can just draw directly in Cairo. We also tend to use Gtkmm to derive, so that we don't have to do a lot of C boiler-plate code (and you won't find a "full widget implementation" anywhere, because of this).
We have user reports that XWayland causes error when running many plugins (primarily those written use JUCE); we also have reports that using XNest tends to be more successful.
Not familiar with the software, clicked the link, thought the pianoroll screen was a Gantt chart. Thinking "not another project management solution ..." until I realized I was wrong lol.
Hobbyist game dev here. Getting into audio and music effects has been fun but I constantly feel overwhelmed. I chose Ardour as my DAW (digital audio workstation) and have been excitedly working on learning. I also bought the book “ Writing Interactive Music for Video Games: A Composer's Guide” which has been very helpful at understanding high level vocabulary.
It’s a lot of work. I slightly enjoy it but boooooy is getting into audio and music pretty challenging. It’ll be good if I ever need to know what I’m talking about when working with others… in the future where I can dedicate myself full time to game dev… One day one day…
I don’t really have a point here. If anyone has any resources, tips, or recommendations on this subject let me know.
Edit: Congrats on the new 9.0 release!
At the risk of sending you down a giant rabbit hole, the book Designing Sound is all about making programmatic sounds with Pure Data, and open source low-code programming environment available for all platforms. From what I've read, the book is considered a classic in the video game sound world. It's really good. Combine that with the Cipriani book on PD and learning Ardour would give you a very good learning path.
Investigating…
I recently dated someone in her 30s with a DMA, and she she told me how proud she was to know me because I was the first non-musician friend she's ever had. It's a very deep and insular world.
Pablo Casals famously replied when asked why he was still practicing in his 70s that he "felt like we was making progress", so don't let yourself feel inadequate.
DMA in what sub-field?
Stuff like that sends me down rabbit holes and when I finally come up for air, I say, "Gee, now I see how people can build their entire career around this!"
In the Axiom Verge noclip documentary, the dev talks about how everyone is surprised about how he really made the whole game himself (except localization + marketing (and I imagine final testing but...)).
And he was like "people say 'even the music?' The music was the easiest part!!!'
It does make me feel like once you get into the right headspace and figure out how most of the tooling works all of this becomes quite smooth.
A light weight journaling of your learnings as you go along would probably be real beneficial to many (such as myself who has zero knowledge on the subject of DAWs and creating music effects for games). And since you said it’s very challenging maybe writing about it in small bite-sized learnings might make the process easier? Going from “I must learn all this stuff!!” to “let’s see what audio gems we pick up in our adventure today”.
Good point w/ journaling and maybe even preparing stuff to share. Right now it feels like trying to eat a whale whole. …That’s the beauty of doing something in a new (to me) domain though. Even if I don’t share, the practice of formulating how I would explain to someone is beneficial.
Alex Rome has really really amazing easy to follow videos about some patterns in music development: https://www.youtube.com/channel/UCh1MtJ4rx4n4PQGYNYK_UXA
I've been making music now for 8 months and have absolutely fallen in love with it. I'd love to write music for a game, what kind of game are you creating?
Here's my stuff if you're interested: https://aaronholbrookmusic.com
Feel free to reach out!
Perfect…! I’ll check out Alex Rome.
Sounds like you’re ahead of me then! The game I’m working on off & on is a 32v32 moba. I want the gameplay of Heroes of the Storm but with the match size of a battlefield server.
I wish I could dedicate myself full time to the effort (and in fact I’m working with my financial planner to figure out a plan) but this is a side project that is prioritized behind a few things. I wouldn’t feel too comfortable collaborating right now since I would be unpredictable. I’ll keep you in mind for when that changes though!
You might like SuperCollider! It's free and a programming language made for sound design. Just writing code - but quite far from a DAW.
Happy to answer any questions about this release, and/or the future of Ardour.
Congratulations on the new release! I've seen some forum discussions on this in the past, and I'd imagine it's a frequently debated topic. However, I'd like to ask about the technical feasibility of implementing a feature similar to Ableton's 'Warp' within Ardour. I understand that Ardour and Ableton have fundamentally different architectures and that different DAWs can prioritize different workflows. Given the current state of the codebase and the development roadmap, I'm curious how realistic the implementation of BPM-synced time-stretching actually is or if it remains significantly outside the project's scope.
The biggest issue here is that the best library for doing audio warping (ZPlane) is not available to us. We already do realtime audio warping for clip playback, just like Ableton, using RubberBand (and might consider using Staffpad at some point, which we have available for static stretches).
However, following the tempo map is a very different challenge than following user-directed edits between warp markers, and neither RubberBand nor Staffpad really offer a good API for this.
In addition, the GUI side of this poses a lot of questions: do you regenerate waveforms on the fly to be accurate, or just use a GUI-only scaling of an existing waveform, to display things during the editing operation.
We would certainly like to do this, and have a pretty good idea of how to do it. The devil, as usual, is in the details, and there are rather a lot of them.
There's also the detail that having clips be bpm-synced addresses somewhere between 50% and 90% of user needs for audio warping, which reduces the priority for doing the human-edited workflow.
>do you regenerate waveforms on the fly to be accurate, or just use a GUI-only scaling of an existing waveform, to display things during the editing operation
just use GUI scaling, and only IF the prior is too challenging
You often want sample accurate waveform visualization when tuning samples that are time or pitch warped to set start and loop points at zero crossings to avoid clicks without needing fades.
Overwhelmingly, there's no such thing as a zero crossing. Your closest real world case is a point in time (between samples) where the previous sample is positive and next one is negative (or vice versa). However, by truncating the next sample to zero, you create distortion (and if the absolute value of the preceding sample is large, very significant distortion.
Zero crossings were an early myth in digital audio promulgated by people who didn't know enough.
Fades are always the best solution in terms of limiting distortion (though even then, they can fail in pathological situations).
There's definitely such thing as a zero crossing, it's where sign(x[n-1]) != sign(x[n]) (or rather, there's "no such thing as a zero crossing" in the same way there's no such thing as a peak). Picking a suitable `n` as a start/end point for sample editing is a judgement call, because what you're trying to minimize is the difference between two samples since it's conceptually a unit impulse in the sequence.
I don't think people who talk about zero crossings were totally misguided. It's a legitimate technique for picking start/end points of your samples and tracks. Even as a first step before BLEP or fades.
Theoretically, it makes sense (go look at any of the diagrams of what a "zero crossing" is online, and it totally does.
The problem is that sign(x[n-1]) != sign(x[n]) describes a place where two successive samples differ in sign, but no sample is actually has a value of zero. Thus, to perform an edit there, if your goal is to avoid a click by truncating with a non-zero sample value, you need to add/assign a value of zero to a sample. This introduces distortion - you are artifically changing the shape of the waveform, which implies the introduction of all kinds of frequency artifacts.
Zero crossings are not computed by finding a minimum between two consecutive samples - that would almost never involve a sign change. And if they are computed by finding the minimum between two consecutive samples that also involves a sign change, there's a very good chance that you'll be long way from your desired cut point, even if you ignore the distortion issue.
It really was a completely misguided idea. If the situation was:
then it would be great. But this essentially never happens in real audio.> Thus, to perform an edit there, if your goal is to avoid a click by truncating with a non-zero sample value, you need to add/assign a value of zero to a sample.
No, you (the editor, not an algorithm) look at the waveform and see where the amplitude begins to significantly oscillate and place the edit at a reasonable point, like where the signal is near the noise floor and at a point where it crosses zero. There's no zero stuffing.
This kind of thing isn't computed, a human being is looking at the waveform and listening back to choose where to drop the edit point. You don't always get it pop-free but it's much better than an arbitrary point as the sample is rising.
I mean, you could use an algorithm for this. It would be a pair of averaging filters with like a VAD, but with lookahead, picking an arbitrary point some position before activity is detected (peak - noise_floor > threshold)) which could be where avg(x[n-N..n]) ~= noise_floor && sign(x[n]) != (sign(x[n-1]).
> You don't always get it pop-free but it's much better than an arbitrary point as the sample is rising.
I agree with this, but that doesn't invalidate anything I've said. When you or a bit of software decide to make the cut at x[n], you are faced with the near certainty that the x[n] != 0. If you set it (or x[n+1]) to zero, you add distortion; if you don't, the risk of a pop is significant.
By contrast, if you apply a fade, the risk of getting a pop is negligible and you can make the cut anywhere you want without paying attention to 1 sample-per-pixel or finer zoom level and the details of the waveform.
Thanks very much, this sub-thread has been illuminating for me, and has the compelling quality of being obvious-in-retrospect. I now wonder what my MPC is doing, exactly, when I make an action at what appears to be a zero point. Thanks.
It's not as if a constantly changing single-axis non-linear transform is trivial to accomplish in the GUI either :(
Just wanting to say thanks to the whole team for creating such an inspiring and useful creative tool!
I'm most excited to try the perceptual analizer, which was something I found always had disappointing performance in plugins.
Which of the new features would you say posed the most interesting engineering challenge?
Well, I can't answer for @x42 (Robin Gareus) but for me personally the refactoring of the Editor code so that we could have multiple "editors" was both interesting and hugely challenging.
I didn't want to replicate the code we already had for the Editor, and figuring out to refactor this took a lot of time and experimentation and failures. Although there are still some rough spots, in general I'm very happy with how things turned out.
Clip recording was also a bit of a challenge. It uses an entirely different mechanism than timeline recording, and as usual I got the basics working in a couple of days, followed by months of polishing (and likely, quite a few more to go as we get feedback from users).
> analizer
analyzer. I think analizer has a different meaning.
Just wanted to say thanks one note time!
We have been running Ardour 9 for a while now during band rehearsals. Currently 12 channels that we record and monitor in realtime with some effects on top.
Thank you Paul, for all the years you've been doing this. For the patience and keeping subscription for your binaries affordable. For how you managed to keep it opensource, alive AND expanding.
You likely could not buy a single coffee with my lousy subscription contribution over a decade ago - the more I have respect for how it was developed.
I've got 9.0 running self built on Fedora 43; it's working OK, I have had a couple of crashes (which I can't figure out how to report); a seg: #1 0x00007f5085ea1663 in jack_port_type_to_ardour_data_type (jack_type=0x0) at ../libs/backends/jack/jack_portengine.cc:71 #2 0x00007f5085ea346a in ARDOUR::JACKAudioBackend::port_data_type (this=0x1ac84ad0, port=...) at ../libs/backends/jack/jack_portengine.cc:465 #3 0x0000000000e3c719 in PortGroupList::gather
which I think is a lack of cast check in port_data_type? (from IOSelector::setup_ports -> PortMatrix::setup_global_ports )
I also got an assert in; #5 0x00000000011fa927 in StartupFSM::check_session_parameters (this=0x3dcf00a0, must_be_new=true) at ../gtk2_ardour/startup_fsm.cc:740 #6 0x00000000011f80d2 in StartupFSM::dialog_response_handler (this=0x3dcf00a0, response=-3, dialog_id=StartupFSM::NewSessionDialog) at ../gtk2_ardour/startup_fsm.cc:267
I think this was opening an existing ardour project that I'd copied onto this machine and was the first run of ardour on this machine.
Sorry, we can't support self-builds (or distro builds).
If you want to check it out, there are free/demo builds at https://ardour.org/download
Bug tracker is at https://tracker.ardour.org/ (sorry that it requires a separate login, but hey, that's Mantis for you)
ps. if you downvoted this, you're welcome to offer support for the full 80+ external libraries in our build stack. Reach out here or at discourse.ardour.org ...
That's ok, but I think if you spend a minute looking at that backtrace you'll see it's pretty obvious where you need to add a check.
The problem is that not a single person has reported this before, so until it's confirmed as affecting the official builds from ardour.org, it can't be a priority for us.
Hi! I have been happily using Ardour as a hobbyist since version 5. At the same time I also started learning Pure Data. I was wondering how difficult it would be to implement a feature similar to "The Grid" from Bitwig. I’m not sure whether this could be done as a simple plugin, or if it would require much deeper integration with Ardour.
Most likely we would do a closer-than-normal integration of Cardinal ....
https://cardinal.kx.studio/
You can already load Cardinal as a plugin and get the full scope of is power(s) (or VCV Rack if you paid for the "pro" version). You just don't get the GUI "integrated" into Ardour, and its tied to a specific track.
We might do this via I/O plugins (an existing Ardour feature), which would make the inputs & outputs of Cardinal be just like your hardware. Lots of details to that sort of design, however.
There is also PlugData which could theoretically be handled in a similar way.
What we will not try to do is to implement Yet Another Software Modular Environment ourselves. Cardinal/Rack (or even PD) are approximately infinitely better than anything we could or would do.
Plugdata (a rework of Puredata as an LV2 plug-in) fills that role pretty well
Do you test on different kernel preemption models? If so, do you feel PREEMPT_RT really gives an advantage over full preemption with threadirqs?
(Cyclictest gives me between a 3x and 5x worst-case latency improvement depending on the background load, but I'm not nearly musically skilled enough to try a real-world test.)
We don't care much about "full preemption" because the only threads that have time-critical behavior are all scheduled in the SCHED_FIFO and/or SCHED_RR classes. If you had other workloads that could benefit from preemption without using realtime scheduling, then full preemption could be the way to go.
We haven't really tested this sort of thing for quite a few years.
Every set of release notes that's intended to double as a press release needs to involve the judicious inclusion of a blurb that immediately explains what the hell the thing actually is.
Hi! I recently (2 weeks) chose this software to invest time into in order to make music/sfx for video games. Do you personally use this software to create music yourself? Just curious!
Not really. My only released music is a single album at https://pauldavismusic.bandcamp.com/album/suspended-generati... which was made almost entirely with VCV Rack (Ardour was used for some pretty minimal editing). I've also used it for a short podcast series ("Audio Developer Chats") that is currently offline. I do try to talk to musicians and engineers almost every single day about what they're doing, however.
Ardour's great. I've been donating $4/month for enough months that I probably could've bought one of the fancier “professional” DAWs, but why bother when Ardour does it all?
A couple friends and I started a band a couple months ago and we've started to use Ardour + a Behringer UMC1820 for some basic recording work; it's wild how quick we've been able to get up and running with it (to the point where our only limitation right now is scrounging up enough cables to hook up all our instruments to the UMC1820). Create tracks, pick each track's input, arm tracks for recording, hit record, hit play, and make noises. Our lead guitarist is more familiar with Cubase, but I had him try out Ardour and he's already putting together recordings; just had to point him to a couple manual pages and he was off to the races with it.
Curious to see how quick 9.0 will hit Ubuntu Studio (which is what we're using in our practice room). Cool to see Ardour finally get a dedicated piano roll window (presumably ported over from MixBus?); even though it's neat to be able to do MIDI editing directly from the main editor window, having the option to focus on a specific snippet will be handy. And the continued improvements with the new cue-based flow will be cool to play around with (and maybe work into live performances once we've got enough material down solid for shows?).
Glad you're enjoying Ardour and thanks for supporting our work.
Things aren't often "ported over from Mixbus", though there are a few features that do start life there (the new perceptual analyzer is one good example).
The pianoroll stuff was started so that we could do clip editing. It appeared in Mixbus first because ... well, let's just say that there was some disagreement about when it was appropriate for that stuff to go public, and the release of Ardour 9.0 represents the ardour team's judgement on that :)
Ardour is very good and needs more attentions. My respects to the developers, I use it every day, and I am very happy with it and its community. I also like the paying / open source model, and I wouldn’t change it for a proprietary DAW 99% of the musicians use.
Is this similar to Ableton? Wanted to "create" music as a hobby, but don't really wanna pay for Ableton. I tried once https://lmms.io/ but didn't stick. Never heard of Ardour.
Ardour is not as focused on "in the box composition" (i.e. making music entirely on your computer) as Live or Bitwig are. It originated as something closer to ProTools or Logic or Digital Performer in the sense that it was focused on recording people doing stuff (blowing,hitting,singing,speaker,scraping etc. etc).
However, in recent years, we've added a lot of the stuff you need for "in the box composition" and many people do use it that way. There's (always) more to do, but it's fairly capable in this sort of workflow now too and will continue to improve over time.
Ardour has been around for more than 25 years.
Please be aware that almost any fully-capable DAW (everything named here except lmms) has a steep, challenging learning curve. Don't jump in thinking it will be easy.
Similar but not quite. One of the problems that you might face is a lot of tutorials are for Ableton, Logic, Cubase etc. It shouldn't actually matter, but you might find it confusing what you can and cant do if you are following what someone else is doing in another program. It’s like learning C# from a Java course. Once you understand the fundamentals it does not matter what you use within reason.
But I’ve used Ardour a long time ago and I don’t see why you couldn’t release music with it. Another alternative is Reaper.
if you mean you just want to make music and arent too bothered about recording then Cardinal is a free modular eurorack synth you could mess around with
or you use a VST host like Kushview's Element and load up on all the free VST instruments and effects that are out there. you would just need a midi keyboard hooked to it then or use Cardinal to generate note patterns
https://cardinal.kx.studio
https://kushview.net/element
or something like Orca if you want to go off the deep end!
https://github.com/hundredrabbits/Orca
Ardour is top tier software. I've been _so_ excited for the "Cue Recording" feature. Until now I've had to resort to other software for live looping. Can't wait to give it a shot / use Ardour for "everything"!
Please use our forums to keep us in the loop if you have problems.
There's approximately 736 different workflows for this; the ones we've tested work as intended, but regularly we hear from folks who use a different one and something breaks ... we want to fix it.
I'll take this as an opportunity to thank the Ardour developers for making a truly great product. Its really really good.
Off topic but is there a linux DAW which focuses on live loop recording? Something like what the LoopyPro app does on iOS ?
You might wanna give Bitwig a try, it’s one of the best commercial DAWs available on Linux. You can record live loops, similar to Ableton (it was originally built by ex-Ableton developers)
Not exactly a DAW, but check out Giada.
I just setup my first little Linux home studio and Ardour is a large part of that. It's a great piece of software with an admittedly high learning curve for a novice like myself, but it's been incredibly fun learning.
Very nice looking UI! Powered by forked GTK+ 2 [1]. (First release almost 24 years ago [2]).
[1] https://github.com/Ardour/ardour/tree/9.0/libs/tk/ytk
[2] https://mail.gnome.org/archives/gtk-list/2002-March/msg00136...
GTK doesn't play much of a role in our GUI. When you're looking at most of the main tabs in Ardour (editor, mixer, recorder window, cue page) almost everything you're looking at is either our own Canvas or custom widgets. Still we do sit on top of GTK+ 2's basic infrastructure and still rely on it for the "big widgets" (file browser, tree/listviews, menus, color dialogs, text entry).
> custom widgets
Implemented like any custom GTK+ 2 widget?
Some are, some have a layer between them called CairoWidget so that they can just draw directly in Cairo. We also tend to use Gtkmm to derive, so that we don't have to do a lot of C boiler-plate code (and you won't find a "full widget implementation" anywhere, because of this).
Good to know, thanks!
How are you approaching a Wayland port?
We keep meaning to provide a page equivalent to this one. Our position is more or less identical:
https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...
We have user reports that XWayland causes error when running many plugins (primarily those written use JUCE); we also have reports that using XNest tends to be more successful.
It would have to be done someday. We are slowly running out of desktop environments that haven't abandoned X11.
Very cool, I have not given Ardour a try in many years but the UI looks quite nice. Will give it a go
Not familiar with the software, clicked the link, thought the pianoroll screen was a Gantt chart. Thinking "not another project management solution ..." until I realized I was wrong lol.
A piano roll in Ardour?! I feel like the earth just moved.
There's always been a pianoroll in Ardour since we added MIDI for v3.
It's just an inline pianoroll, which is cool for ProTools and award winners like Olafur Arnalds, but apparently not good enough for everyone else.
[dead]
As no small feat, this release is on the HN front page at the same time as Claude Opus 4.6 and GPT-5.3-Codex. Big day, big names, congrats!