What is Ardour for?

I’m not clear what the use-case priorities that drive Ardour are. I looked at the roadmap, and there is really no indication of what (specifically) drives the design.

Is Ardour primarily directed at say, amateur/hobbyist musicians looking for a low-cost alternative to commercial DAWs? Professional Music Production? Post-production?

Obviously there is a very limited development pool, so I surmise there would have to be a lot of attention paid to scope-limiting, or “product focus”. What are those limits, and what’s the focus, if you don’t mind my asking? Where is Ardour now and where is it going? Why?

"At present, there is no roadmap for future development, but there probably should be. "
A very complex software project with thousands of worldwide users and dozens of development contributors…and no roadmap for future development?
Additional comment on that would be extremely interesting, Thanks.

Where could we find roadmaps for the “commercial DAWs” you mention? Thank You.

Ardour targets the recording and creation of music and audio in which performance matters more than modern pop production techniques. Users are expected to be motivated toward excellence through actual work, rather than sheen through shortcuts. They are also expected to feel comfortable about knowing moderate amounts of audio engineering rather than simply pushing buttons, and to believe that this is a skill that requires practice and experience rather than just a better software tool.

We will publish a roadmap once we can copy the one put out by either Digidesign, Apple or Steinberg. Right now, the focus is on bringing Ardour3 closer to alpha-test status, fixing issues with the OS X build(s) and when possible without disproportionate costs, fixing significant bugs.

You can get a pretty good idea of the “roadmap” by watching the code commits as they happen. The stuff going into A3 right now is several months from prime-time, which is about as far as you could expect to look ahead anyway. You’d see the same thing in commercial development: there are lots of blue-sky ideas; but at some point, someone will put their nose to the grindstone and actually starts doing things. those are the things that are really on the “roadmap”. Anthing else is just speculation.

Ardour3 has a lot of “deep” code changes that improve the speed and stability of the whole system. It also adds better support for console-like routing, panning, remote controllers, and (most popularly) MIDI. So those features are clearly on the roadmap.

If you’re a film guy, some of the most recent (and most interesting) changes are by carlh; he has added buttons to combine “object” and “range” modes in a way that is very similar to the PT “smart tool”. This will also carry over into automation editing.

Paul, thanks for taking the time to respond.

The reason I ask these questions is because I think they have a lot of relevance to developers who might consider contributing to Ardour, and to individuals who are considering supporting the project by donation. I count myself among both groups. Cooperation between Ardour and Harrison indicates an openness to business relationships as well; similar parties could also benefit from such information (presumably Harrison would have asked you where Ardour is going before moving ahead with Mixbus).

Mentioning these possibilities in no way pre-supposes that I think they
are either interesting to you, or some necessary part of Ardour. I’m
simply trying to get a sense of how open you are, and whether the direction of
Ardour is something I would like to invest my time and money in. Without a
roadmap, without a clear statement of objectives, that could only be
approximated by inference. Or I could just ask.

“Ardour targets the recording and creation of music and audio…” This
is a very broad statement of purpose. I was asking for specifics. Of
course it’s your choice as to whether or not you’d like to answer, and mine to
decide whether I’m willing to contribute to Ardour.

“performance matters more than modern pop production techniques…Users
are expected to be motivated toward excellence through actual work,
rather than sheen through shortcuts. They are also expected to feel
comfortable about knowing moderate amounts of audio engineering rather
than simply pushing buttons, and to believe that this is a skill that
requires practice and experience rather than just a better software tool.”

Excellence through actual hard work, not shortcuts - Got it, thanks.
Users should not feel comfortable simply pushing buttons - Ok.
We should believe that audio engineering skill requires practice - so true. It
took about a decade of practice for me. But I’m slow.

Anyway, I’m confused as to what you meant by including those statements here.
It sounds like a pre-emptive response to an accusation neither made nor
implied. Not sure what I said that made you think I’m new to Ardour or music
production, but if people have misunderstood what it is Ardour offers (and
does not offer), perhaps explicit description of the design motives, context,
and direction would be of some good use after all.

“We will publish a roadmap once we can copy the one put out by either
Digidesign, Apple or Steinberg.”

Paul, are you mocking my questions?

To Vtech: I don’t understand what relevance the activities of closed
proprietary systems and their development model has to do with Ardour, the
open source audio workstation. Are you implying that the bar (meaning assorted
policies) for open source development should be pegged to the policies of
proprietary vendors? (Sorry, I don’t know if it’s both of you being snide, or
just the guy asking for donations)

Thanks again.

The way I see things is somehow related to this: there are basically two sets of people who need audio technology tools (though a single person may be a member of both groups). There are people who make music as a way to make a living, for whom every second saved during the process of making some fundamentally unoriginal music (e.g. as part of a low budget movie soundtrack, a TV show, a typical commercial) enhances their ability to earn money. These people need tools that can help them crank the production workflow to the maximum, especially anything that can churn out stock components of whatever they are doing. Take a look at something like RMX Stylus - a phenomenally powerful rhythm/groove generator that can be used to lay down 1/2-3/4 of each 30 second piece of your standard ad/TV incidental music with very little effort. Or TC Electronic’s backing harmony vocal generator - instant 2/3/4 part harmonies to back you up, with pedal-driven sustained holds. Awesome, but … somehow missing the point of 4 part harmonies in so many ways. People who work like this need these tools, and there are companies working hard to make sure that they get them. Ardour is not that tool. It might evolve into a tool for this kind of workflow, but if it does it will be mostly a side effect rather than a goal.

Then there are people who are working on original music, music as a means of self-expression or meaningful collaboration. In this sphere, the ability to trivially generate boilerplate components of their music is much less important than simply having a reliable, accurate and easy to use tool for recording and editing whatever they do. What matters here is some combination of musical performance, audio engineering skill, and editing/mastering vision. Ardour intends to be the tool for people involved in such activities.

There’s no mocking of your questions going on. You asked about roadmaps, and mentioned a comparison with proprietary DAWs. I believe that myself and vtech were pointing out that such roadmaps do not exist for those products, and its not clear why you’d expect them to exist for Ardour either. Whether there is a good reason to expect it or not, one doesn’t exist, and there are no plans to spend time on one. Ardour has always been driven by breadth-first development - its more important to me (at least) to know that the program design has not omitted critical things that could lead to a complete reimplementation later than to get each successive piece of functionality totally right.

I hope that this answers some of your questions.

Oh, another note. What I’ve described is what drives my work on ardour. That doesn’t mean that it drives the other developers who work on Ardour, including Harrison. One of the wonders of an open source project is its ability to act as a place where these different motivations can come together, although occasionally managing the clashes between them can be a challenge.

You forgot on group of people at least;)

Those people that work as engineers for a living and need to record or edit down other people’s work in a smooth workflow. I fall stright into this group, along with doing some design work.

   Seablade

That’s true. I did leave out the “only-engineer” side, although in my mind, this fits into my second category in the sense that if the “creative” and/or “performance” work is largely being done by someone else, then your need for a plugin that generates 12 tracks of rythm, and a box for backing vocals is likely to be reduced. Maybe I should come up with some other duality :slight_smile:

Its interesting because it brings implicitly the question of what could be Ardour at the end. In 3 or 5 years will Ardour be a finished “product” or will it continue to evolve ? The industry has evolved from various specialised branches to a somehow large focus. For instance there were at first pure MIDI editors (like Cubase or Logic), and pure audio editors like Samplitude, Protools, and the both have merged into a common tree. Some sort of integrated multi-usage musical DAW. Ardour belongs to the audio editor category that have seen on the late MIDI features coming. I think Ardour will retain some of its original flavor to be on the audio ingeneer side. Its nice because currently there is no real alternative under Linux and its important to have at least a tool that can make serious job done.

I sometimes think about Blender wich is another successfull Libre project, them too have a wide scope, ranging from generating single photorealistic picture, or whole animation to interactive OpenGL gaming. And now you can even do creative postproduction with their compositing nodes system. There are probably some parallels between the 2 worlds to draw that could serve the general discussion. But its not an easy task and may be a little of topic.

But for sure, it should not be easy to set a defintive roadmap for such a project given the fact that it adresses the need of various categories of users. Let alone the purely technical programming issues (like multithreaded DSP).

Paul, your words regarding a roadmap: “There probably should be one…”.

I’m sorry you think there’s nothing going on artistically in low-budget film. I have to say you’re remarkably wrong about that. And no talented folk making adventurous music for any games, cable shows, tv, commercials? A limited perspective, but to each his own, I say!

And you’re against the notion of a lightweight workflow, tainting the idea by associating it with big bad industry composers who get paid.

I think I get where you’re coming from, that explains a lot about Ardour.

Thanks so much!

@filmsound

Paul’s opinion is just that and he’s allowed to have it. My interpretation of what he is saying is not that there is no talent, but that the focus is on quick turnaround to make a profit rather than music for the sake of some expression… He also said that someone could be in both fields and I dare say that is probably the case for most highly paid producers.

Maybe I’m a contradiction myself… I make loop based music using a number of contemporary tools, loop based sampler/sequencer(s) VA synths e.t.c… and record it via traditional multi track methods… Ardour suits this perfectly… I’m not highly paid…

@filmsound: I do not understand how you could possibly interpret my comments as “there’s nothing going on artistically in low-budget film”, let alone “no talented folk making adventurous music for any games, cable shows, tv, commercials”. I have many friends (and a stepson) who do both, and they are deeply talented. As Allank noted, and as I noted in my comments, my proposed “duality” was between workflow styles, or perhaps one might even say “current need”. When my friends do movie/TV/ad pieces, what matters is speed and ability to give the customer precisely what they want (which is often a fairly stylistically cliched chunk of sound). The faster they can deliver what is required, the sooner they get paid and can move on to the next paying task. The tools for doing this kind of work are often going to be somewhat different to those occasions when even the very same person is working on a piece that they have to put a lot of time, effort and emotion into, particularly in terms of composition and performance.

I’ll try to put it another way: the times that I hear people expressing frustration about what their audio software can’t do are mostly when they have a very clear idea of what they need to do, and they need to do it quickly. Frequently, the complaints sound to me as though they are rooted in the observation that they wish they had a tool that “could just X”, where X is some fairly rote task that they have to perform over and over as musicians/engineers. When the obstacles faced are mostly composition (including composition-by-edit) and/or performance, the limitations of current audio software (including Ardour) seem to be much less important.

As for this: And you’re against the notion of a lightweight workflow, tainting the idea by associating it with big bad industry composers who get paid. … I never said this, and I don’t understand what frame of mind you are in by imagining that I feel this way. Big bad industry composers are awesome, and I’m happy that they get paid. Most of them don’t even fit the description I gave - Hans Zimmer and Danny Elfman and John Williams and their colleagues are typically much more immersed in compositional/performance issues than problems like “how to crank out 30 seconds of parisian street music with a slightly hip-hop feel” (this is a real example from one of my friends’ paid jobs). They also tend to work with huge and expensive sample libraries or with real orchestras - in the former case, the limitations created by the sample library producers mean that its hard to do that on Linux, and in the latter case, its hardly their choice when it comes to recording technology.

I find it sad that your interpretation of what I wrote is so totally off-base.

@filmsound

As someone that is both actively involved(I think most would say very actively) in the development process of Ardour by providing testing, feedback, occasional coding, and other issues, and makes his living from sound, and specifically has worked on EXTREMELY low budget animations as a paid sound designer(And enjoys working artistically), I can tell you your reading off Paul’s response is so far off base it almost seems like you are intentionally trying to twist his words.

I am not sure how you got what you did from Paul’s response, but I strongly suggest you reread it.

   Seablade

ahem… Could it be that you 3 (filmsound, Paul, seablade) have a little misunderstanding?
I think the intention of filmsounds question was something like:
“hey, I think it would help Ardour to have a roadmap, and as it’s indicated tht ‘there probably should be one’ on the development page it would be reasonable to ask”
but he phrased it a bit like (overemphasizing now)
“hey what the heck why don’t you have roadmap, go get one”

So I think that’s where a bit irritated Paul put the answer in not 100% friendly but neutral and ironic tone, and the discussion set in.

So don’t weigh up every word, remember, you’re all on the same side :slight_smile:

Benjamin

Benjamin-

It is of course possible I misunderstood filmsound’s post, but it is hard to misunderstand statements like this…

“I’m sorry you think there’s nothing going on artistically in low-budget film.”

and this…

"And you’re against the notion of a lightweight workflow, tainting the idea by associating it with big bad industry composers who get paid. "

Those are the two statements that form the basis of my response, in particular the first one, as I take exception to that notion having worked with Paul and Ardour both in my work in exactly that field, and I feel very confident in saying it is not true. Paul even explains exactly why he said that in an earlier post, not in response to the ones I just quoted but before that. In fact contradicting the second one is this explanation…

Take a look at something like RMX Stylus - a phenomenally powerful rhythm/groove generator that can be used to lay down 1/2-3/4 of each 30 second piece of your standard ad/TV incidental music with very little effort. Or TC Electronic's backing harmony vocal generator - instant 2/3/4 part harmonies to back you up, with pedal-driven sustained holds. Awesome, but .... somehow missing the point of 4 part harmonies in so many ways. People who work like this need these tools, and there are companies working hard to make sure that they get them. Ardour is not that tool. It might evolve into a tool for this kind of workflow, but if it does it will be mostly a side effect rather than a goal.

He openly admits they are cool tools, and great for quick compositions, but are not the type of things involved in the artistic creation that Ardour was written and is aimed for. I happen to agree with him completely on the topic of automatic harmony generation. It is a great tool when you need to get something out fast, but completely misses one of the beauties of vocal harmony IMO.

In as far as the first quoted statement, this was likely in response to this part by Paul…

There are people who make music as a way to make a living, for whom every second saved during the process of making some fundamentally unoriginal music (e.g. as part of a low budget movie soundtrack, a TV show, a typical commercial) enhances their ability to earn money.

Where the only way I can think of to take that as how it was apparently taken by filmsound as evidence in the first quote above, is to misread it that all low budget movies, tv shows, etc. are unoriginal. Which is not what was said or typed at all. Those were given as examples that could contain an unoriginal piece because people in those types of situations are typically in a time crunch as they are not being paid much and they can move on to the next project quicker and get paid to eat so they are looking to churn something out quick in many cases(Not all).

I haven’t commented at all on the roadmap/not to roadmap side of things to be honest. I will say one of my goals for Mantis when I can get back into there(I think I am going to set an internal deadline of starting this by the release of A3) is to start utilizing it’s roadmap feature to start providing feedback on requested features, as well as autogenerate bugfix reports etc. However that can’t happen until I/we(There is more than just me in there cleaning up nowadays thankfully) finish clearing and cleaning the bugtracker. I also will not in any way guarantee that it would be an ‘official’ roadmap, just what I see as a maintainer of the bugtracker, and conversations with people that do more development than I do.

   Seablade

On re-reading what I wrote (thanks for the quote Seablade), I will admit that it could easily be misread as a very negative comment on the soundtrack work for a “low budget movie soundtrack, a TV show, a typical commercial”. This certainly was not what I intended. My point there was merely that often in those cases, the music that is being produced is specified by a paying client who says “I want it to sound like XXXX”. This is the sense in which I mean “fundamentally unoriginal”, although of course most music that people make starts out in some way as a kind of homage to other, existing music. That doesn’t mean that there isn’t a skill requirement - far from it. One of my friends who does this sort of stuff has to be able to flip between musical styles on a dime, so to speak, and its very demanding, tricky work. But at the same time, its also nothing like when he works on music “for himself”. In both cases, there is skill, but in one its being harnessed to (rapidly/profitably) produce something according to someone else’s desires, and in the other its being harnessed to some kind of self-expression. Of course, he might actually use RMX Stylus on both, or neither :slight_smile:

Wow. Amazing was to screw up a great conversation topic :slight_smile:

Paul (and other devs): I understand filmsound’s desire to see a roadmap - it really helps the user understand what the project is gonna be like in the near future. I also understand why in most cases it’d be annoying to have a roadmap: You write down what you want to focus on, and then in a few months you decide that there are other more important things to do first, or want to take a whole new direction. In fact, the only FOSS that I’ve seen that has really good roadmaps is Inkscape, because it’s got the SVG spec to work towards, and games, which are implemented piecemeal (game engine, then graphics, then sound, then story, etc…)

But the whole question could be framed thus: Which direction(s) do you (the whole team, and each developer individually) see Ardour heading in the next sixth months? Two years? Will it ever be “finished”? (I hope not!). What missing features do you think are most important? What do you use it for, and how does that affect your visions for Ardour’s development?

Reading this thread, I was thinking, it kind of sounds like carpentry: the only real way to learn is with a hand saw, chisel and nails, and working with hardwood. Buy most builders these days start off with nailguns, circular saws, and electric planes, and work with softwood. It’s definitely quicker and cheaper, but you end up with a low quality product with no soul, and you don’t really learn much. And it’s definitely not as fun.

There used to be a roadmap on the site. It specified changes for version 2, 3 and 4 I think and was published at the time of Ardour 1.0 release.

I’m personally glad it’s gone. It gave me an unrealistic impression of when certain functions may be available and I held back for a while as I was waiting for the next great version… now I am happy with the relative stability of my workflow…

@naught101… excellent analogy… I love it…