dak at gnu.org
Tue Aug 31 01:44:42 PDT 2010
John Emmas <johne53 at tiscali.co.uk> writes:
> David - to add to what Paul said, I've used a wide range of DAWs (and
> even designed a couple of them) but whilst I sympathise with your
> problem, you need to be realistic. No two DAWs on the market today
> either work the same way or use exactly the same terminology. And the
> reason is a simple one.... nonlinear editing is a very young
> technology. It's not at all like word processing where the basic
> terminology (words, lines, sentences, paragraphs, linefeeds, fonts,
> cutting & pasting etc) has been around for centuries, gets taught in
> schools and is (mostly) well understood.
Cut to Emacs: its terminology is not in synch with the industry. You
have killing and yanking, frames and windows and other idiosyncrasies
inherited from times where the industry language and keybindings and
expectations were not as unified as you represent them.
A beginner will get along fine with the GUI of Emacs nevertheless, since
you can point at everything without needing to know its name. That's
the main point of a GUI: you just point at things. Its a _major_ PITA
doing telephone support for my mother (bordering on 75 years) who uses a
Linux system, since her problem reports tend to be something like "I am
doing what I always did, and that thing I used for doing $WHATEVER has
disappeared". She does not have the words.
> 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
You need the terminology for the manual, and for coherent mnemonic
keybindings (there is a problem for Emacs terminology in the manual to
move from kill/yank to cut/paste while retaining keybindings focused
around C-k and C-y). But for the GUI, you need predictable and natural
reactions to "gestures", making them a worse candidate for
mode-dependancy than keybindings are.
> There isn't even a common consensus about what nonlinear editors
> should do.
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. I don't mind how other applications behave. I am not
interested in Ardour behaving like other DAWs or audio editors. If you
aim to be best, you have to be different from the rest. But being
different from the rest does not make you the best. It can also make
you the worst.
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.
> The requirements of a film editor are a whole world apart from the
> requirements of a musician. Every system takes a different approach
> so naturally, this leaves all DAWs with a steep learning curve. It's
> not like text editing where using one editor pretty much prepares you
> for all the others.
Nothing prepares you for vi. But you can navigate shallow waters quite
successfully using Emacs. Because the simple things are simple, and
natural. It has taken decades to get there, and the journey is not
over. And if you want to deviate from the simple things, the
interactive help and the context-sensitive cross-referenced integrated
manual reader is available for everything. Or rather, for the exact
version of Emacs you happen to be working with.
> A day might come when all that changes but it hasn't arrived yet.
I see no point in trying to work against that day.
More information about the Ardour-Users