Release Plans for Ardour 3.0

Blog
#1

A decision has finally been made regarding the release of Ardour 3.0. First, some general stuff.

The open source world typically offers two models for integrating development and release of a piece of software. One is the so-called “rolling release” model, which features frequent new releases which typically do not contain substantial changes to the functionality of the program, although if the program is still being developed these changes must appear from time to time. The other one is more similar to what happens with proprietary software, and features less frequent new releases with each new release containing substantial new functionality and/or bug fixes. There are extreme versions of each of these approaches, and less extreme versions which blend different mixtures of the two.

Audio software users are notorious for their use of out of date versions of their favorite software, generally defended on the grounds that “I know it works (and what is broken)”. Although this depressing as a software developer, its a fact of life that we have to deal with - people are reluctant to move on from something they think they know and understand to something that may break their existing workflows or do things in ways that they do not understand or appreciate.

When a project uses the “major release only” model, it becomes important that development work as a new release gets close should not break existing functionality. Nobody wants to fix a bug and in the process cause 3 new ones. This is why Ardour has frequently gone in to “feature freeze” mode as a new release draws near - its a way to increase the likelihood that things continue to improve (or at least, remain as they are) in anticipation of a release.

The problem with this approach for developers is that it can cause relatively long periods of stagnation in which novel, cool work is not supposed to be taking place. It is true that with modern software development techniques, this can be avoided to some extent by using “branches” for the development of new features. Even so, if the feature freeze continues for too long, and the intent is to just fix bugs, development can slow down to a trickle. This is particularly true of a project like Ardour which really does not have the human resources available for development that a proprietary project might have. It is my assessment that Ardour 3 has reached this point - development has stagnated because all new work is “on hold” pending the release of 3.0.

So, with all this in mind, there is a conundrum: in order to keep development active and new (useful) features flowing through the development platform, not to mention fixes for bugs that require deep architectural changes, it is desirable to use a rolling release model. But in order to give our users some sense of stability and to increase the likelihood that when they upgrade they will not discover some new issues, periodic major releases are better.

This problem has not been solved. But in lieu of solving it, I have decided that Ardour 3.0 will be released in the following way:

  • There are two outstanding "bugs" that will be fixed:
    1. Automation curves end up with incorrect shapes under common conditions
    2. Import of Ardour 2.X sessions is not sufficiently functional
  • Once these two are adequately addressed, Ardour 3.0 will be released for Linux.
  • An OS X beta will be made available. An official release will not occur on OS X for at least a month after the Linux release. The only reason for this is the lack of testing on OS X. I simply do not have the confidence at this time that we do not have basic issues still to address on that platform. Once we have adequate feedback on 3.0 on OS X, it will be released for that platform too.
  • Once Ardour 3.0 has been released, work will begin immediately on features slated for 3.1 (and beyond) which notably will include Robin Gareus' video timeline.
  • After the release of 3.1, Ardour 3 will use a release approach closer to "rolling release" than "major releases", potentially bringing out new versions twice a month (though that remains a case-by-case decision)

Ardour 3.0 has been in better shape for audio than Ardour 2.X for some time, although some people use a workflow that seems less stable in Ardour 3.0. Ardour 3.0’s handling of MIDI is far from the condition I was hoping it would be at release, but nothing is being gained by delaying release any further.

#2

Really looking forward to using 3.0 on my Linux DAW.

Great Job so far !!!

About the release: I think that the Debian way of having a stable and a testing release serves both, the developer who wants to implement cool features and the user who really only wants a working system. Maybe alternating versions (odd and even).

Keep ist going.

#3

Thanks a lot for such a good software! I’m using svn version and I can say that it’s totally more stable than first betas’ and also much more functional. Waiting for release :slight_smile:

#4

“markedly different in Mixbus than in Ardour2”

Right, this is some of what I mean. I have been using the Beta 5 in AVLinux6 and have found most of the new stuff, including the link for creating the “smart tool” in Ardour, I was just curious if how it was “smoothly” implemented in Mixbus2.2 would transfer over to A3.

Keep up the great work folks, I for one REALLY appreciate it!!!

#5

there is no “crippling” of AU support in any version, and certainly not in 3.0 betas. Support is not incomplete, and its more extensive in 3.0 (since we support instruments) than in 2.X. There is very little testing on OS X because there are very few people on OS X willing to try out stuff that often doesn’t work and then get involved in debugging. Its that simple.

#6

Great news - thanks for the update Paul!

I had been wondering what the final big issues to be fixed before 3.0 arrives were - now I know.

Its a shame that A3 OSX has had so little testing. I wonder if the incomplete, intentionally crippled AU support is partly to blame for this? At least I was told AU support wasn’t fully functional in the betas last time I asked las about it and then there was no way to uncripple it either - none that I’d been told about at least.

We know 3.0 won’t be perfect but its release will be a big event for Linux audio and one I eagerly await so its nice to know the wait is almost over!

#7

@Dazgard:

The video timeline for Ardour has been out there for almost 3 years. It’s development is pretty orthogonal to ardour dev.

It will probably spark feature requests such as audio-alignment according to EDL.

I quite agree: stability is a must.
But adding features does not necessarily jeopardize stability: When new features are confined to a specific area (e.g. metering or aligning audio on import) potential problems or bugs can be ironed out quickly. MIDI on the other hand introduced major changes to both front- and back-end and is wide field by itself…

#8

Awesome! I’m excited about the next release to start rolling. Ardour is the best, the foundational tool of all my audio work.

#9

@josander: can you describe the issues that JUCE has with RT kernels? this seems impossible, so i’d like to know more …

#10

@paul: I can only provide you with my own user experience but a link later here might enlighten you. Both Loomer’s stuff and Pianoteq started freezing on my system when they started using the 2.0 (or maybe even the 1.53) series of the library. Pianoteq 4 did not work (3 series did) and Loomer Aspect did not work under the standard RT kernel for Ubuntu 10.04. I could click on a meny or two, but the programs and sometimes the OS freezed when a dialog box was opened. This happened very quickly on Pianoteq, becau it wanted to show a Welcome box at the start.

The Pianoteq guys camed up with a workaround (I tested some binaries they sent me) and the Loomer folks decided to let it go becaus not that many 10.04-people was using Loomer stuff. Here is a link where Loomer and JUCE folks are in the discussion:

http://www.rawmaterialsoftware.com/viewtopic.php?f=5&t=8507&start=15

EDIT: Added link

#11

Sorry folks, I probably had a bad or tired moment when writing my post. It looks like I’m complaining about Ardour and that things break when Ardour comes with upgrades. I meant programs in general. In my experience, Ardour is getting more and more stable.

@LeatusPenguin: I do use the compiled binaries now as I’m using a system based upon Ubuntu 12.04.

@linuxdsp: I haven’t tested all of them, but the plugins I use regularly, such as Black EQ, the VC2B compressor and the SR-2A reverb (IMO the most versatile reverb ever in spite of it’s simplicity, you can tweak it for anything!).

@macinnisrr: 10.04 based distros are not an option for me anymore. JUCE based programs like Pianoteq and Loomer Aspect doesn’t work with that RT-kernels anymore. It is probably a kernel bug and no one seem to be able to do a decent workaround for that bug. Dream Studio is one distro I always monitor and I will consider it when I upgrade my HW next year.

Some of the reasons I “upgraded” to 12.04 was because I needed Pianoteq and Loomer to work good, but the my Nvidia card does not work as it should with the RT kernel (both the proprietary and Xorg drivers), so I use the low latency kernel, which occasionally leads to timing problems; and so far, this have happened a few times during recording and mixing, and a few times when in example Rosegarden and Mixbus are synced together so I can record audio from Linuxsampler. I guess that a new machine will solve the problem. My oh my, the life as a pragmatic Linux fanatic is not always easy! :slight_smile:

#12

@paul: I’ll take versions with bugs in return for increased MIDI contoller pad support (panning, more generic controllers, etc.) . I like to be able to control Ardour with out having to leave the piano or while standing at the mic with a guitar hanging on my neck.

#13

@josander: This is probably not the best place to try and debug what is happening with your LV2 plugin GUIs, but are you saying the VC2B, Black-EQ and SR-2A are not working? The latest versions from the linuxDSP site work fine here, however the SR-2A reverb was superseded by the SR-2B a long while back.

#14

@linuxdsp: They are working very nicely on my system and I’m using them all the time. And sorry , the A is my mistake, I use SR-2B . :slight_smile:

Sorry if my bad English confuses people here. I will try to improve it.

#15

@BenLoftis:

The more similar are the GUI’s and features of A3 and Mixbus the more easily any user will be able to work with any of these DAWs given a case where it is needed, and also as you say, Mixbus includes a lot of experience based features, so a least i would welcome them on Ardour.

@Paul:

I think it is important to keep the “sense that we’re moving forward”, because both developers and users need it and are happier when any release is out, it has influenced at some degree the donations… seems to me at least, so i think it is a very good call, every user should know that there are always a few bugs to get rid of but not only the users are part of the proccess, the new features tend to overcome to those few bugs, actually your last words say it very well: “nothing is being gained by delaying release any further.”

I prefer (for example) a January 2013 A3 with Midi bugs than a March 2014 bugless A3…

#16

There are several features, such as the Smart Tool, Playhead-follows-range-selection, crossfades, and layer modes that were markedly different in Mixbus than in Ardour2.

Those PT-like features have been implemented in A3 but in a subtly different way. I am going to endeavor to make them more Mixbus-like, because I think Mixbus has had more real-world usage than A3 and we have refined those tools to a more consistent feel than what is currently in A3.

If anyone has any strong feelings about this, please tell me now!

-Ben

#17

@linuxdsp: part of the point of this announcement is to say that there really won’t be any more testing of anything before 3.0 is released. Obviously if people want to do so, and they report issues, that will be welcome. But the development process has stalled out, and it needs to restart.

#18

Hi all,

I don’t want to be the negative one here, but do you all think adding more features is a good idea, when the one already implemented aren’t stable at all ?
It’s like building a castle on broken foundations.
How can we be sure that the video addition functionalities are not going to be as the MIDI one ?
Would not that mean more complications to stablize the application later ?

I do agree that audio in A3 is stable, but wasn’t A3 be all about MIDI in the first place ?

Adding features is cool, but as stated in this news, stability is very important for this kind of sofware

I just wanted to share my point of view, no harm no fuss…

#19

A3 was started when Google’s Summer of Code agreed to sponsor work on adding MIDI to Ardour. But while David Robillard was focused on MIDI, other developers did a lot of work on the audio side of things.

A3 is already MUCH more stable for common workflows than A2. There are fundamental bugs in A2 that most people avoid through a combination of luck and workflow choices. Almost all of these (certainly all the ones we know about) have been fixed in A3.

The work planned for post-3.0 will not complicate fixing existing bugs in A3 - in many cases, it will help it. There are some things that cause issues in A3 that we currently have to throw up our hands and say “we’ll fix that after 3.0 is out”.

As it stands, development is going to grind to a complete halt if we cannot move past the release of 3.0. So the choice not really “keep working on bugs only” and “release 3.0 and then start adding more stuff”. Its “release 3.0 and enable development to continue at a reasonable pace” or “development stagnates and A3 is never released”. That is how it appears to me, anyway.

#20

@rpatros: http://ardour.org/support has videos.