Hi all,
Firstly, thanks so very much for such a warm welcome. I know some of
you said I was a brave chap to grit my teeth and join up, but I think
its important not only for my own understanding to discuss the
different issues, but to also dig in and get to know people who know a
lot more about the subject. Thanks for such constructive discussion
and a very warm welcome. :)
With over 35 emails already to this thread, I don't have time to
respond to everyone's post individually, but there do seem to be some
recurring themes that I will respond to:
-> Cubase is not actually that easy to use, and some of you found it
quite difficult.
Something that some people have been referring to is whether existing
knowledge can make other systems more difficult to use. I am not going
to deny that people approach 'ease of use' in different ways.
Personally, Cubase works very easily for me, and Ardour seems pretty
complex. I think the key question is about usability from the first
minute the application is loaded. Sure, I can go away and read copious
amounts of documentation about either Cubase or Ardour, but if an
application is intuitive, it means less reading and more recording.
In some application domains, there seems to be a view that research
and pre-reading is required. This has typically been applied to
graphics as well as audio. As much I think that you need to research
the topic to do anything vaguely complex in your recording, the target
for usability should be to limit the required research to a minimum.
When I started out, I used to use Magix on Windows for my recording. I
was astounded to discover that I could not figure out how to simply
cut a wave into parts - simple editing. This operation is intuitive in
Cooledit, Audacity and even video editing tools such as Premiere. To
me, this is a real flaw in usability. When I switched to Cubase, the
entire interface was far more intuitive. I still need to look things
up, but the 'looking up' process is far less than with other
applications. I think Linux applications just need some usability love
to make this happen.
-> The integration issue is solved or at least reduced if you use
DeMuDi, Planet CCRMA, AGNULA etc.
This is an interesting point. One side of me thinks, "awesome, this
solves the problem", but another side of me feels a little weird about
requiring an entire customised OS to run audio software. Now,
personally, I use my studio box just for audio, but I know some other
posters on the list said that it should not be a requirement to use a
computer just for audio stuff. I do agree here.
To me, the integration issue seems largely a distribution problem.
Issues such as making sound servers, LADSPA, Ardour and Jack talk
together still seem difficult to solve. As I said before, the
canonical test is to simply install Ardour and Jack and get it to
work. Making this work and then using LADSPA and other bits still
requires some knowledge of the infrastructure.
What has been interesting in this discussion has been that onlookers
outside of this list seem very critical of Linux and audio. This
article was linked on GNOME footnotes, LinuxToday, OSNews and
elsewhere, and the comments posted and mails I have had have been
supportive of the view that it is difficult to get started to an equal
level of capability on competing systems such as Cubase and
GarageBand. This seems like a real problem to me, and although I
accept that audio production is always going to be a complex science,
there seems to be a slight undercurrent of RTFM from some sides of the
audio production in Linux community.
-> New users and pro users are a different breed
I do agree that the needs for a new user and pro user are different,
but the only real difference is that the pro user goes into a far
deeper level of detail. As such, I don't see how usability necessarily
has to be different. If you look at a different type of application
such as a word processor, the tool can be as useful for my dad writing
a letter as it can for a writer who writes a book. The key point is
that the application scales to the differing requirements of the user.
This can certainly apply to audio production.
It seems to me that applications such as Ardour simply need some
usability discussion, testing and implementation. Even cursory glances
at Ardour reveal a range of usability flaws - even simple issues such
as dialog design, right up to structural issues. These problems could
be fixed with some very straightforward design changes, and I am more
than happy to consult with the Ardour team about some of these
changes. Some of you mentioned that the great thing about Open Source
is that changes *can* be made. Hell, I completely agree. I have been
an Open Source contributor and developer since 1998, and I work as a
full time consultant helping people learn and use Open Source in a
variety of different areas. I know that the community is central to
how we can move forward. The purpose of my article was not to slag off
audio in Linux, but to open up interesting discussion such as is
occurring here that will help to better refine how this great
technology is interacted with.
This moves me onto another point, and I would love to hear your
thoughts on this. I have heard a few loose comments around different
parts of the net that Ardour is not quite the same as other Open
Source projects. I have heard that development occurs between a fairly
limited set of developers, and only a few developers drive the
direction of development. I also read somewhere that the testing team
is restricted to a specific group of people and that the author may
even charge for accessing the development version in the future. Is
any of this true? How have you found the development of Ardour to be?
I have not really looked into it, so these points I have heard may be
rubbish, but I would love to hear your thoughts.
Thanks so much for the great feedback everyone. :)
Jono