A website suggestion to help the Ardour Team

Community Ideas for Ardour
#1

A friend of mine sent me here to scope out for him, if Ardour could be a multitracker that might work for him on a small notebook computer.

I was just gonna download it and check it out, but the first thing I ran into were messages, that you’re having trouble with your funding - few customers, still fewer willing to pay. Understandably, that’s frustrating for you, I’m sure this is a lot of work.

.
From the perspective, a newcomer who arrives at this site for the first time, that sounds like maybe the project is already dying. Beyond that, the matter is this:

Nobody in their right mind is going to pay until they know it will work with their hardware. Or, failing that, if it works with some other hardware they can look at, see if its worth the hassle to swap existing hardware for something else they would actually feel ok to buy and use.

.
After failing to download, I came to the forum to check what hardware is supported (Audio I/O being #1 criterion). But there is no list, no faq focusing on that, not even a forum sticky. I would have expected an audio I/O section in the forum, really!

So, my assessment of this Project, without ever having seen the quality of the software has taken 2 sharp drops:

1) devs seem unsure about the future of this project
2) can’t figure out quickly what audio hardware you support.

.
I’m sure there’s all sorts of posts spread about, where people discuss different hardware they’re trying to use and such, but that doesn’t cut it for someone who’s trying to make a decision on a software package. That’s part of the key information before someone even decides if they want to spend a little more time looking up more details. And that comes before they remotely think about ponying up cash for something that might get cleared off the disk an hour after installation.

.
My suggestions:

1) make a supported hardware list (fully supported, partly supported, somebody somehow got it to work etc)
2) make a hobbled time limited trial, where you aren’t asking for cash yet, that’s always available.

If people have to go assemble it from source code themselves, you’ve just sent over 90% of your visitors to the competition.

.
.
Myself, I’m an ardent Cakewalk user. But who knows how annoying Microsoft is going to get in the future, trying to be like Apple.

#2
Ardour works through Jack so you'll be looking at what hardware, on your operating system, will work with Jack

I think there is a valid point made about how you would discover this from the ardour site - e.g. you most likely wouldn’t, at least not directly, especially if you were not too familiar with linux audio, and for people coming to Ardour from another operating system, that is quite often going to be the case.

There is a reference to ALSA / FFADO supported hardware on the front page, but it’s buried at the bottom of a long list of other features and easily missed (assuming a potential user knows what ALSA and FFADO are - these terms are not so ubiquitous as e.g. ASIO for Windows)

#3

I’ve recently had to spend some (considerable) time porting code to Windows and Mac, and in the course of doing so, I’ve been using Reaper a lot, mainly as a test ‘host’ application. I would seriously recommend Reaper as a model of how to do ‘this kind of thing’ - everything from the Website (www.reaper.fm) to the way the application looks and works, I mean it just works

#4

Well…

Click on Support. On that page you will notice the first link is to a FAQ…
http://ardour.org/realfaq

On that page you will see a FAQ exactly about Audio I/O that answers exactly this actually…

Basic Audio I/O problems What audio interfaces should I use with Ardour?

You can use any interface supported on your platform (Linux or OS X).

For PCI /PCIe/etc. cards to install inside a computer, we recommend:

more than 26 channels
RME MADI
more than 12 channels
RME HDSP
2-12 channels
M-Audio Delta 1010
2-4 channels
M-Audio Delta 44, 66 or 2496

For portable devices to use with laptops and other portable computing devices, we recommend:

PCMCIA/CardBus/ExpressCard
All RME Hammerfall IO Boxes (Multiface, Digiface, RPM) work with either the Cardbus or ExpressCard interface, but please check with your Cardbus chipset driver first. There’s also the RME MADIface, a mobile MADI interface for the ExpressCard slot (up to 64 channels).
Firewire devices
Please visit FFADO to see what Firewire devices are currently supported on Linux.
USB devices
You’ll be using a nasty little USB thing with support for just a couple of channels. Check the ALSA soundcard matrix to verify that specific devices are supported. Note that almost all USB1 audio interface are supported and that almost no USB2 audio interfaces are. You can thank the brain dead morons in the audio technology industry for this situation.

Please note that MOTU have consistently been aggressively anti-Linux when asked about the information needed to support their devices. Those MOTU devices that actually work on Linux do so only because of pain-staking reverse engineering, and most do not work. We recommend that you avoid this company’s products, not because of their engineering quality, but because of their stubborn refusal to help us create drivers for their product. This stands in marked contrast to the cooperation offered by RME, M-Audio and many other companies.

Not going to disagree that some things could be improved, but this was fairly easy to find considering the support link is at the top of every page, and the first line answers the question about audio I/O.

In as far as the comments about money, this is a conversation that has been had many times, even on these forums, and there are many possible solutions, but for the moment at least this is the one that is gone with. The code is always available for someone to attempt to compile themselves, but considering you can get a supported download for donating as little as $1… to each their own I suppose.

Keep in mind, this isn’t really to say ‘Go away’, or anything of that nature, just to respond to the comments you had, and isn’t saying they won’t be kept in mind in the future either.

      Seablade
#5

@linuxdsp

The reaper method has been strongly considered, in fact IIRC a similar type of setup was tried for a while, but maybe Paul can refresh my memory on that. The short version is that it wasn’t to successful IIRC for this particular case. It wasn’t identical mind you, but Reaper’s situation and Ardour’s aren’t exactly identical either.

        Seablade
#6

@seablade: It wasn’t really the Reaper business model I was refering to (if that’s what you mean) - more as an example of the way the application is styled and presented. Reaper was trivial to install, it’s fast, intuitive, it has a GUI which I enjoy looking at, it’s light on system resources and it worked, I mean it just worked. (without any tweaking)
(On the same hardware, I can’t get A3 to open a session bigger than one stereo track and the mixer takes so long to draw that it gets ‘greyed out’ because the WM thinks it has stopped responding, I’m also plagued by random fits in which it decides to throw a modal dialogue (error console) about MMC problems, whenever I click the transport controls - I’m not using MMC or any MIDI - and I’m also getting several lockups due to JACK disconnects… and my DSP usage reported by ardour seems to be completely random - with no plugins - even though both CPU cores report being practically idle… all of this troubles me)
This is the pre-compiled A3 Beta5, A2.8.14 is by contrast completely stable on the same machine.

#7

Ahh ok I did misunderstand you.

And yes that is the start of the goal for any software release I think. On the flip side, I recently, surprisingly, heard that A3 debug versions are quite a bit harder on hardware than the optimized, I have not however checked this, but I also have noticed that the pre-compiled betas are heavier on resources by a fair amount than A3. I am only just now really starting to work on it and test it out, and yes I agree it has some ways to go before being considered completely as it should be, but I do think it has taken huge steps in the right direction.

Of course the thing to keep in mind is A3 still isn’t released either:)

          Seablade
#8

Reaper “just works” in large part because it operates within two rather well-defined software environment. Windows is not as well defined as OS X, to be sure, but a hell of a lot better than the mess caused by Linux distributions. The fact that the same executable can run on similar hardware under Linux and generate a DSP load that varies by a factor of up to 5 is something that we can’t control.

Their website is very nice, and I’d love for Ardour’s to have a similar feel. But Reaper has also taken a very different approach to money (they have VC capital at this point), and I know from personal experience of other web projects that their site is at least a part time job for someone. Nobody in the Ardour community has ever stepped up with the time, energy or knowledge to build a site like theirs, so we’re stuck with a Drupal CMS-driven thing that is OK but really not great. Even migrating the site from Dreamhost to Amazon EC2 is beyond the resources Ardour has available at this time.

Here’s the fundamental thing that Cockos have done that makes it different from Ardour: one way or another they’ve convinced A LOT of people to part with $50 in order to have a license to run Reaper. Its not a community-run project (though it is/was very community driven), and its absolutely not open source - the dynamic from day one has been to do what was needed in order to pay people to do work on it.

Reaper also fails to get a lot of professional details right that Ardour has cared about from day one (they are getting much better at this though - I suspect most of my pet examples are now fixed). Many of these small details really don’t matter to most users, and there is a good argument to be made that caring about them derailed Ardour’s development in various ways. However, there are plenty of reports that are entirely the opposite of LinuxDSP’s - Reaper failing to get close to Ardour’s HDR capacity on the same hardware, so I’m not sure its worth getting too caught up in that.

#9

Regarding the original post:

  1. make a supported hardware list (fully supported, partly supported, somebody somehow got it to work etc)
  2. make a hobbled time limited trial, where you aren't asking for cash yet, that's always available.

As Seablade has already pointed out, a list of recommended devices is already at the top of the FAQ which is referenced by http://ardour.org/support which is linked from every single page on this website. I’m not really sure how much more obvious it has to be.

I think you are under the impression that somehow Ardour controls which hardware it can work with. This is actually completely incorrect. Ardour has more or less no interaction with audio hardware at all. If the hardware is properly supported by the OS (whether that OS is Linux or OS X) then Ardour will be able to interact with it via JACK. If the hardware is not properly supported by the OS, then Ardour will not be able to use it fully, or at all. So the issue you are really raising is a much more general one:

What audio interface does Linux support and what is the state of that support for each device?

We have provided links to the ALSA and FFADO websites that answer this question, but it is really impossible for the Ardour project to answer this question in any general way. Our FAQ provides recommendations, our links point you to places where you can definitive answers. You want something more “obvious” and “straightforward”, but we do not control device support on the Linux OS, any more than we control the support for Digidesign native hardware on OS X (which has taken years to be properly supported so that it can be used by ordinary native OS X applications). What is worse is that even when a given piece of hardware is nominally operational on Linux, a particular version of a particular distribution may have broken some or all of the device’s functionality. Again, we can have no control over this. If we instead specified some more limited “truth”, like “Ardour should ONLY be used with the Nonesuch Distribution, version 13.2a only, with one of the following 8 interfaces”, we would be simultaneously not being entirely honest and irritating a lot of people who want to use other distributions.

Regarding the “hobbled demo” approach. I am currently evaluating the best approach to take toward revenue flow. The project is generating less and less revenue as time goes on, not more. If you only just looked at the website, you probably do not realize that its current state is one that it enters in the middle of months when it seems obvious that I will not make enough to pay the bills. For the first half of the month, and in months where revenue flow is “adequate”, there are freely downloadable versions for every platform. I suspect there are better and smarter ways to increase the revenue, but when I initially switched to the current approach of dropping free downloads mid-month, it had a hugely beneficial effect. This has largely faded now, and something different is probably needed.

#10

I think the OP makes a good point about potential users and donors frequently not being able to try Ardour (under OSX at least) without making a donation. Whilst its true that pretty much everyone can easily afford $1 to try out a program, the percentage of those that will donate a small amount to try an unfamilar program must be tiny. I’m sure the majority of users will just go and download REAPER or whatever as soon as they’re faced with the prospect of having to donate or wait a month and most likely never return. Also, I have notice that all the free downloads are gone within the first couple of days normally so that means that most of the time OSX users can’t download and try Ardour for free.

I’d urge Paul to ape REAPERS model a bit by having permanently available demo downloads for OSX and Linux albeit with a nag screen explaining he’s pretty much a one-man band trying to achieve the near-impossible on a shoestring and that users can get rid of the nag screen (with its 10s delay or whatever) and have the saving and restoring of AU plugins (or VST under Linux) enabled by making a donation.

The OP never said if they were running OSX or Linux. Generally I’d say, yes, your hardware is going to work fine with JACK and Ardour if you’re running OSX as most everything has official drivers provided by the manufacturer - its only under Linux where you need to take care and do your homework in selecting your hardware. I just looked at the Ardour FAQ and it already mentions the ALSA and FFADO sites but I’d also recommend we add a link to http://wiki.linuxaudio.org/wiki/current_audio_gear

#11

@Paul: I agree with just about all the points you make - I completely understand (from personal experience) the pressure on resources, and the time and effort it takes to manage all the extra stuff that goes around a project to make it usable and accessible e.g. website, documentation etc. And more than anyone I understand the difficulties around trying to make a product that just works across the many different flavours of linux.

My original point was not that Ardour should become Reaper or that it should change its business model etc, more that in terms of look and feel, reaper is a great example of what draws users in.

Reaper also fails to get a lot of professional details right that Ardour has cared about from day one

Agreed - and ardour has a lot of very cool features, and my frustration stems from the fact that I know how good it can be (and it is fortunate to have some great people involved with it) and I want it to be more accessible to many more users but I feel that unless some of the more basic things are right a lot of potential users are not inspired enough to learn about it and find out what it is capable of.

With the future of content creation increasingly hard to fathom (and perhaps at risk) on the ever more consumer-centric offerings from other OS / hardware vendors (I can’t see how the traditional DAW paradigm could or would work as a native ‘Metro’ - or whatever it is now called - App) therefore linux is better placed than it ever has been to capture the attention of users looking for an alternative and I feel that just a few relatively small usability and presentation changes could really help make that difference.

#12

I wonder how much the poor world economy contributes to foss donations.
I wish some big benefactor(s) step up and create a stable and long term fund for Ardour.

Ardour is a rare Linux application. And music production is not a niche market.
It is as though so much emphasis are being put on Linux itself and server related programs that the one achilles heel of Linux is still too slowly addressed. Getting blockbuster (non-server) applications on Linux.
Yes i know Blender, Libreoffice and such but audio/video production in Linux should get better funding.

How can one campaign among the rich to donate to this project?
Squeakiest wheel gets the grease as they say.
I swear if i had say 100 million in the bank i would donate a $100 000 to Ardour, Gods to honest truth.
Maybe there is a networking group or people specialising in procuring funding. Connected organisation with a huge and relevant contact list.
[/rant]

#13

@Francois

I’m not sure how effective ‘benefactors’ are to something like Linux, last time I checked the involvement of a independently wealthy benefactor has created an amazingly well received Linux OS ( you have 3 guesses) that seems to have made most of the developed world believe that even highly specialized things like Ardour etc. are the ‘right’ of everyone regardless of their means to have delivered free and wrapped up in a pretty bow.

Without a doubt this has been a great and welcomed benefit for the developing world and for low or fixed income people, however the spin-off effect in the developed world has made funding open-source projects somehow seem politically incorrect and this stigma seems very difficult to change. I think the involvement of benefactors in the grand scheme of things has been a wash…some benefit balanced by some detriment.

#14

Yeah, everything is working great for me at the moment. No complaints.

#15

@Ricardus: I think 10.04 LTS was about the best Ubuntu for audio - no reason to change if everything is working - I think the issues I have with A3 are more specific to my hardware, but I can’t say exactly what as I haven’t had time to fully investigate (A2 and Mixbus on the same machine are really stable and run huge numbers of tracks and plugins) - I don’t think it’s an Ubuntu issue. (also, A3 is still beta - and I’ve just remembered, I shouldn’t be mentioning it on the forums…)

#16

I still run 10.04 LTS.

#17

@macinnisrr: I was running A3 (pre-built download) on Ubuntu 10.04 LTS - I know it’s considered out of date, but, it was the last stable Ubuntu without Unity (and the nature of trying to provide a commercial product means testing on older versions too, not just the latest and ‘greatest’). Although I can find out what’s causing the problems I’m seeing and fix them eventually, I raised the point because in the context of making linux more user friendly, wouldn’t it be nice if I didn’t have to :slight_smile:
(A2.8.14 works fine so I suspect this is something deeper than just the usual tweaks)
As for Reaper - it depends on what you want a DAW for. Ardour has some serious professional features and is a very powerful application, but I was using Reaper mainly as an example of all the ‘extra stuff’ that inspires potential users to try it - without which, a significant number may not discover what it can do.

Any DAW that supports skinning is a pretty weird beast.
Well, that's just a decision the developers have made, and it doesn't detract from the functionality - the default 'skin' looks fine to me - of course, you can re-skin Ardour too by changing its theme.
#18

ricardus: I literally laughed out loud on that one.

linuxdsp: I couldn’t disagree more about Reaper. I’ve tried it a few times when I had to work on windows, and to me it just feels like a toy. Any DAW that supports skinning is a pretty weird beast. Also, what distribution are you using Ardour on? On Dream Studio (and indeed Ubuntu and all its kin), all versions of Ardour run great. I literally use it every day. In fact I’ve been using A3beta5 exclusively since it was released, and never had any problems. That being said, you probably wouldn’t use a Reaper beta, so what’s the difference?

paul: I don’t use OSX anymore, so I’m probably not the best person to speak on this issue, but I must say that even when I did, the main reason I used ardour was that I had previously used it on Linux. I can’t honestly say that I would ever have tried it if I had to pay just to give it a go. In fact, I’m not ashamed to admit that when I was a windows only user way back in the day, I would never buy a piece of software until I had tried it, even if that meant getting a pirated version (which is pretty hard to find in the case of Ardour OSX). A timed or crippled trial would probably work great (certainly couldn’t hurt). Also, its obvious to me that (because it uses JACK) Ardour can use any I/O that the OS in question can use, but telling people that even on the splash page would likely be a point of pride, one that not many other DAWs can boast.

tsais: All you need to do to try Ardour for free is download a copy of Dream Studio (http://dream.dickmacinnis.com), burn (or make a USB install), and reboot. You may even find a new OS.

#19

@Paul

If you think improvements to the website would help the project I’d be more than happy to work on this and I’d be willing to spend as long as it takes to get it the way you want it. That’s what I do for a living.

#20

I thought you were a crime dog?