[Ardour-Users] Hm...

[Paul Davis]

On Tue, Aug 31, 2010 at 4:44 AM, David Kastrup <dak at gnu.org> wrote:

 [ ... story about words and grandma ... ]

>  She does not have the words.

But in your example, you don't have the workflow. You've got a mental
model of how to accomplish an end-goal (which I think is a part of an
existing piece of audio, with fade in and fade out applied, stored on
disk in its own single audio file, regardless of how many channels it
has), but you appear to have a limited understanding of the way that
the tools are intended to be used. You have a VERY clear model of how
you think it should be accomplished, which is fine. We just have to
deal with the mismatch between your expectations and the way that
similar software (by which I mean other DAWs and audio file editors)
have evolved.
Some of the mismatch reminds me a bit of trying to get users new to
text file editors to understand that no, they are not actually
changing the file on disk as they type characters or delete text. The
moment you get this particular concept, so much else flows from it,
but without it, so many things are hard to understand at many
different levels.

You would find your task no easier, I believe, if you used Garageband
or Logic, two Apple products rightly lauded for their "it just works"
designs. And this is not because their design has failed, but because
neither program was actually intended to do what you actually want to
do. This is why there are literally dozens of audio file editing
programs available on OS X, all of which get used as adjuncts or
alternatives to DAWs like Logic, Digital Performer and so forth.

You seem particularly resistant to the notion that you simply picked
the wrong tool for the job. I don't use emacs when I actually need
sed. I don't use firefox when i actually need wget. And I don't use
Ardour when I actually need Bias Peak or Audacity. Well, OK, that's
not true, because I never need Bias Peak or Audacity :)

>> DAWs on the other hand have grown up very recently and have had to
>> invent their terminology as they went along.  'Clips' in one system
>> are called 'regions' in another system or 'events' in yet another
>> system.  There's no consensus yet about what things should be called
>> or how the UI elements should interact with the user.
>
> Well, it is easy: take a look at a studio built in hardware.  If I want
> to do anything with some gadget, I touch it and plug it where I want to
> have it.

No, this isn't true. The primary gadget in most studios is still the
mixing console, which for the most part you don't get to rearrange or
put components where you want them. You'll no doubt be aware that
there are quite a variety of console layouts, each of which shares the
basic concept of the channel strip but not much more beyond that. No
doubt you'll also be aware that someone with oodles of experience on
an SSL console will feel very awkward on a Neve/AMS or a Studer or a
Harrison console precisely because of the slightly different
terminology and layout, neither of which they can control. Similar
observations would apply to analog or digital recording devices too,
most of which wouldn't be accessed directly but controlled via
mechanisms built into the console.

We don't have to, nor do we want to emulate hardware limitations or
cite them as an excuse. But the reality is that despite some common
themes, there are some very different ideas about how to build both
the hardware *and* the software for this kind of stuff. Should it be
that way? It would probably be better if some common terminology had
emerged, the way it did for text editing. It might even be a good idea
if everyone used the same keybindings for the most closely related
functions. But the terminology didn't arise, and the semantics of even
the most closely related functions is not always the same.

> Again: take a look at Apple gadgetry.  They are not popular because the
> bother about "common consensus" but because they bother about what feels
> natural.

That's true. But even Apple's deserved accolades for design brilliance
knows its limites: there are legions of DAW users who detest the
design decisions of Apple with Logic (and to a lesser extent even with
Garageband) (just as there are many who can't stand the design of
ProTools or Sonar or ...)

> The problem I have right now is not with the functionality of Ardour,
> but with how to access and discover it reasonably using the GUI.

faced with the choice between working on discoverability and extending
functionality, i've preferred the latter (with an awareness of the
cost of this). nothing has ever stopped anyone else from providing
more focus on discoverability, but so far, it hasn't been high on
anybody else's agenda either. do you plan to change that or do you
believe that your advocacy will be enough?

Again, I ask the question: have you ever used any DAW before trying Ardour?