[Ardour-Users] Hm...

[David Kastrup]

Lamar Owen <lowen at pari.edu> writes:

> On Monday, August 30, 2010 10:19:36 am David Kastrup wrote:
>> I wish I had made a desktop recording of the last three hours or so.  I
>> am a new user to ardour2.
>
> Ardour is at least as complicated a program as emacs,

If that's your impression, it means that the Emacs developers have done
a better job at making Emacs palatable than the Ardour developers.

Because the combined complexity of the supported tasks in Emacs is
rather staggering.

> and can take some time to learn properly for a user that is completely
> new to it.  I mean, how many users new to emacs get confused by all
> the keyboard bindings and modes of that program (mode being dependent
> upon what modules and addons you have loaded, and what LISP stuff
> might be running)?

Few.  There are no different modes when editing one file, and the menus
spell out the basic functionality and keybindings.  The customary keys
pretty much do all the customary things, the GUI elements are not
mode-dependent (what kind of elements are there may well be).

>> Task: take a recorded WAV file, crop a piece away from the beginning,
>> pick a point of time where one starts fading out, pick a point of
>> time where the fade out is complete (alternatively, just pick the
>> point of time where the fadeout starts and specify a fadeout length).
>
>> Save the result from the chosen start position to the end of the
>> fadeout.
>
> That shouldn't take more than five minutes,

Yes.  And the text editing equivalent in Emacs will not take more than
five minutes even if you never heard of Emacs before.

> depending upon the size of the file and how fast your computer is.
> You need to drag the start marker

What start marker?

> to the desired crop point, drag the fadeout handle

What fadeout handle?

> at the end of the track to the desired fadeout begin point, and drag
> the end marker to the actual end of the fadeout.

What end marker?

> Export the results to the desired format, and you're done.

No doubt.

> But you do need to learn how to use the tool you've decided to use (or
> use a different, more appropriate tool).  The fadein/fadeout handles
> are clearly marked on the track,

Huh?  Why should there be fadein/fadeout handles when I have not made
any fading?

> and you can drag things to your heart's content.  You just need to be
> in the right edit mode, and know what you're looking at.

Problem is that the editing modes are called very unintuitively, have
unintuitive items and non-explanatory tooltips.  The consequences of
changing the editing modes in the shown GUI elements are neither obvious
nor connected with any of the online helps.  The help menu in Ardour
offers to connect the user to an interactive talk session.  Now how
often will a beginner enjoy being called an idiot by a real person,
assuming that the tone on that talk sessions is not significantly
different from that on this mailing list?

>> It is, in general, impossible to click on any graphical element with
>> the intent to change/move/whatever it.  You first, if at all, have to
>> change some internal ardour modes around (with obscurely named mode
>> switcher buttons or menu entries elsewhere) to facilitate the desired
>> operation.
>
> Ardour is more like vi in this respect than like emacs.

That's a valid design decision as long as we are talking about keyboard
shortcuts.  For GUI elements offering a menu, it makes little sense not
to give the full options.  If one wants to keep the menus reasonably
short, one can keep them like they are, but add one entry called
"non-foo-mode operations" with submenus "fee-mode operations", "fie-mode
operations", "fum-mode operations".

GUIs are good at offering discoverability, and this should not lightly
be thrown away.

>> I had to restart jack+ardour even in order to manipulate a 44.1kHz file
>> when jack happened to run at 48kHz sampling frequency.
>
> Then start JACK at 44.1.

After quitting Ardour, manually deleting the project that invariable
gets created and filled in in spite of me telling Ardour _not_ to save
when quitting.  Restart Ardour afterwards.

Builds character.  That's probably the reason for naming "character
terminals" too, come to think of it.

> But do realize that Ardour is not a soundfile editor; it is a DAW, and
> is much much more complex than a soundfile editor would be.

Which makes it all the more desirable for it to refrain from whacking
the user in the face when this is not actually necessary.  There will be
still enough substance left for toughening the user.

> Due to its "many file project" design, yes, Ardour creates lots of
> files before you save anything; this is somewhat unexpected, true
> enough, but it is the way it works.

It does not just create files, but it also fixes project parameters
(like the sample rate) in stone, even if one quits without saving.

> Programs like Audacity do the same thing, they just do it in a
> temporary area and only move it to the project target area on a save,
> deleting the temp files on close without save. Ardour assumes that if
> you import a file you intend to save it, and it puts it where the
> project lives.  That is different from others, but not wrong.

If Ardour offers me to quit without saving changes, it _is_ wrong if it
does not quit without saving changes.  Whether or not it needs to
indulge in any disk operations in order to rewind to the last save point
is not relevant with regard the overall result being wrong.

Nobody claimed that "quit without saving changes" needs to be perfectly
equivalent to

    killall -9 ardour

> Ardour assumes a user that knows what he or she is doing, and doesn't
> provide much of a safety net for many user mistakes; this is ok (at
> least in my opinion) given Ardour's target user base (the
> ProTools-using market, for the most part).

We are not talking about "safety nets" for user mistakes.  It simply is
not a good design goal to maximize damage for user mistakes.  We are
talking about the situation where Ardour notices something being wrong.
The options it gives the user should, if possible, be better than
telling him to commit ritual suicide.

> But that has been something I've learned the hard way, as I have been
> burned by the lack of a mistake safety net a few times.  But it was my
> fault for making the mistake, not Ardour's fault for assuming I knew
> what I wanted to do.

In the case that I brought up here, there is nothing gained by forcing
the user to create a new project and manually delete the files of the
one started off with a wrong setting.

Additional menu choices are cheap, as opposed to keybindings.

-- 
David Kastrup