[Ardour-Users] Hm...

[Paul Davis]

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

sigh, getting sucked into yet another endless discussion about design
is about the least productive thing i can do. so be it.

> I have two digital cameras.  One (Sony I think) has a user interface

> Basic elements of graphical user interface design are quite less
> connected to "the workflow" than keyboard operations.  You want your
> keysequences for typical workflows to be short, mnemonic and convenient.

these 3 things can be in conflict. in fact, we have quite a
significant input from users who specifically do NOT want mnemonic
bindings for typical workflows, they want convenient (i.e. one hand on
the mouse, one hand on the keyboard; thus for a right handed mouser,
the common keys are all under the left hand and not mnemonic at all).
this is work style preferred by people who do this sort of thing for a
living; its very awkward and hard to learn by people who dip into this
kind of tool occasionally. which is why we have multiple keybinding
sets and dynamic key bindings.

> A GUI, in contrast, works more often than not on objects identified by
> pointing.  In particular given the graphic representation of Ardour,
> that is a natural way to do things.

unfortunately, this is not actually the way that people do this sort
of thing for a living work either. when you have hundreds of things on
the screen, some of them very small, pointing at them in order to
operate on them is inefficient and tedious. for some people, its so
irritating that they even write an entirely new DAW to avoid this
method of working (its called traverso, worth taking a look at for
some interesting, if flawed, UI models). this type of distinction is
most clear when watching people at work on MIDI composition, which is
not an option in the version of Ardour that is currently released. for
the people who actually do this regularly, pointer-driven operation is
incredibly frustrating and incredibly slow. for this kind of work, the
pointer is a fallback position for new users, much like the menus and
so forth in contemporary emacs.

>> everyone. Emacs being the perfect demonstration of this, wherein
>> despite its elegance, supreme power and overall conceptual beauty, it
>> still meets hostility in the face of users of vi and several other
>> editors.
>
> Most of it acquired historically.  Quite a few vi users, in particular
> the more influential ones, were in contact with Emacs at a time where
> hitting backspace would tend to land you in its help menus, C-h being a
> really bad user interface design decision in the world of text ttys and
> system diversity.  Nowadays, if you leave an unsuspecting computing
> newbie with Emacs on a GUI and nothing else and tell him to do a simple
> editing task, he'll be finished in 15 minutes.

that wasn't my experience when introducing my kids to emacs, nor my wife.

>Doing the same with vi
> is not practical.

certainly not. but gedit is.

> Ardour does not come with a cheat sheet.

i'm afraid that it does, and i've already pointed you at it. its on
the page labelled "Support" that has a link at the top of every single
web page at ardour.org.

> It is fine if you see that not as a personal priority, but you should
> break the habit of selling it as an advantage, because it means that you
> actively discourage others with different priorities from improving the
> situation.

wait. the fact that up until this point ardour has no
context-sensitive help means that i am actively discouraging others
from improving it? there are a gazillion programs of all stripes
without a useful help menu, and without context sensitive help.

> In the context of a project tracking system, you are labeling tasks as
> "Invalid" that should better be labeled "Unassigned".  That's not making
> the best use of a diverse community with diverse talents.

you haven't anything with our project tracking system. what you did
was to show up on an email list, complain that you couldn't get
anything done and then proceed with some sweeping gestures about the
design of a program that exists in a class of software that you
apparently have no prior experience with.

>> In every example you cite, I could explain to you the workflows/use
>> scenarios that justify why Ardour behaves the way it does right now.
>> They are not the way *you* want it to work, that's true. But the
>> behaviour is there to meet several other different styles of working
>> that, over time, seem to be the most likely ones that the programs
>> users will either have prior experience with (e.g. ProTools users) or
>> expectations of.
>
> You are always assuming that any improvement has to be connected with a
> loss of functionality.

i'm not assuming anything. i'm basing my observations on 10 years of
conflicts between the desires and needs of people who use tools like
this for a living with the desires and needs of people who are just
starting out or just dropping into this kind of tool.

>> I will address one small example that you bought up: "Quit with
>> saving"
>
> "without", please.

that was just a typo.

>> does not mean "Quit and undo any changes to your system that this
>> program has made since it was started".
>
> "since the last save", please.  What does it mean then?  "Quit and leave
> the project in an undefined state."?  So that the only sensible option
> is to throw it away?

no. it means "the project will be left in the state that it was in its
last saved state". which may have been an explicit save by you, or it
might have been an automatically saved state such as the ones that
occur after every track addition/removal or capture pass. the state is
not undefined.

> Again: I have never stated that "Quit without saving" should be
> equivalent to "killall -9 ardour".  If you do the latter with Emacs,
> you'll leave your files in the last _manually_ saved state, but there
> likely will be an autosave file you can revert to with a state not too
> far from the point where Emacs died.

and the same is true in ardour, except that at present, you can't
autorevert to it from within the program, since it also has an
"autosave" mechanism (this is not hthe same

> It is not a matter of a temporary session of its own, but of organizing
> the session data appropriately.  In the terms of version control
> systems, saving means committing the data, but that does not mean that
> one has to keep the uncommitted data in memory instead of on disk.  It
> also does not mean that one has to keep a complete session copy around.
> As an example, git tends to have a working copy (corresponding to a
> complete session state), an index (built from the same objects that are
> checked into the repository, and thus not taking up significant disk
> space without large changes), and the repository, where all checked in
> versions can share the same data.

that is pretty much exactly how an ardour session is organized. there
is only one "index" (the session file) which references objects on
disk which are by and large immutable.  the "complete" copy of the
session is the session file plus the objects. a review of 20 years of
DAW development will reveal a history of various approaches to keeping
the "immutable" objects (recorded or imported) audio files in the same
or different locations as the session file. my reading of the general
the general preference (from archived magazine reviews, forums etc.
etc) has been to keep them in the same location. you can snapshot the
session at any time, which simply creates a different version of the
session file, indexing the same objects but possibly with a different
arrangement along the timeline, etc, etc, etc.

> It may not be a priority for you personally, but I think that you don't
> do the project a service by not permitting other people to contribute
> with other priorities.

i'm struggling to find where i have "not permitted" other people to contribute.

>> There is something to be said for this approach, and several arguments
>> against it to. It works fine for single-file editors, but has some
>> notable drawbacks for DAWs.
>
> The principal notable drawback is "it is work".  As long as you don't
> confuse "it is work" with "it is work you personally have to do and
> you'd rather be doing something else", you'll spend less time, effort
> and frustration selling something as an advantage that isn't.

to repeat a question asked by other people: have you ever used any
other DAW before starting to use Ardour?