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
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).
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 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.
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.
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
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.
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 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.
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.