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
