[Ardour-Users] Hm...

[David Kastrup]

Thomas Vecchione <seablaede at gmail.com> writes:

> To again address specific points because for some reason I feel the
> need to, not sure why because at this point it sure seems like the
> answer to almost every 'question' you have presented as a complaint is
> to RTFM...

Of course it would be RTFM because I was addressing user interface
issues.  I was never in doubt that Ardour was capable to do the job.  I
was complaining about sub-par discoverability of how to do this.

It might be worth mentioning that Ardour does not actually come with a
manual, nor with any references to it (let alone a version corresponding
to the installed version) in its Help menu.  That is another usability
issue.

> On Tue, Aug 31, 2010 at 5:49 AM, David Kastrup <dak at gnu.org> wrote:
>> Again, implying the knowledge that "export" involves not just exporting,
>> but also the part of the editing I wanted to do.  Cutting away parts of
>> the region completely (rather than fading) is something I discovered how
>> to do, but it is more mode-dependent than desirable (when being able to
>> visibly mark a time section with the mouse, it is not helpful that
>> "Delete" will only do something discernible with it in a particular mode
>> and be ignored otherwise: if Ardour finds nothing more useful to do with
>> that keypress, it might well choose to do the obviously intended thing
>> rather than nothing).
>
> You have obviously never worked in a professional workflow, which is
> where Ardour is intended for.  You specifically will WANT modes that
> do not do certain things.  Once I have timing down, I never want it to
> move, thus the purpose of LOCK mode.

Nothing wrong with a toggle for locking things.  Try to change them, and
you get a tooltip "xxx is locked" and nothing happens.  But that is not
what I was talking about.

> If I am clicking on a region to modify gain levels, I don't want that
> region to move when I click and drag.

Different handles help.  Also changing modes with a local mouse menu
(3rd button) rather than toolbar icons, since the latter is on a
different part of the screen and moving from and back takes time.
You'll likely say that people should rather use keyboard shortcuts, but
if I have the mouse in hand anyway, that means extra work.  The purpose
of a mouse interface is not to demonstrate how bad a mouse interface can
be.

>> Why are there no hyperlinks to the lucid explanation on the buttons,
>> or the toolbar they are situated on?  Where is the point in funneling
>> that off to the web where it might be unavailable due to
>> connectivity, and not corresponding with the currently running
>> version of Ardour?
>
> You know how few people want to depend on a web browser on a system?

Same here, but if the only documentation you _have_ available is on the
web, that's bad enough.  Hiding it away completely from within Ardour
and then telling people "RTFM" is just disingenuous.

> Heck just the inclusion of a hyperlink has stirred up huge amounts of
> dialog on this list(Or Ardour-Dev) about professional users and how
> stripped down they want their system.  The inclusion of Help>Manual to
> point to the manual was far from uncontroversial in that regards.  And
> in all honesty, the manual on the web DOES correspond to any version
> of Ardour that would link to it currently(Ardour 3 is a moot point
> since that has not been released yet and no manual has been released).

So either there is no progress in Ardour2 development, or the manual is
so incomplete and/or outdated that it would not track this progress?

>> How do you ensure integrity between documentation and installed
>> version if the documentation is offline and not synchronized to the
>> installed version?
>
> Good question, are you offering to write the documentation?

I won't write anything I don't understand.  I am fine with the situation
being suboptimal.  What I am not fine with is pretending that everything
is fine and everybody not seeing it that way is a moron.

By pretending everything is fine as it is, one discourages any progress.

> I can tell you that out of people on this list I probably have the
>most direct experience of trying to organize documentation to be
>written for Ardour, and it is hardly simple.

I believe that immediately.  But "hardly simple" is not the same as "not
worth it" and that is not the same as "unnecessary".

>In fact the technical reference manual is over 100 pages just covering
>the functionality of Ardour, and there is still much to be written.
>Until you are offering to write this documentation and help keep it up
>to date for every version of Ardour simultaneously, there isn't much to
>be said.

Ardour does not come with a man page.  And its help menu does not point
to any documentation (at least in my version).  That is over 100 pages
already written that are not discoverable.

You'll say "do a web search".  I happen to be the maintainer of AUCTeX,
an Emacs editing mode about 20 years old.  It comes with extensive
online documentation that is meticulously maintained.  One recurrent
nuisance is people _not_ reading any of that documentation but instead
using recipes they dug up on the net from "helpful people" who stopped
maintaining their websites 15 years ago, or from snapshots of the
original documentation similarly old.

That's just aggravating, and you can't stamp out all that outdated
stuff.  And since people linked to a lot in recent decades (and left
their links live at well), it crops up at embarrassingly high places in
web searches.

So I try doing the authors of software a favor by using the
documentation coming with their software, or pointed to by their
software.

And the version of Ardour I am using here (current Ubuntu Lucid) draws a
blank in that respect.

So the first advice should be to FTFM (Find the Fine Manual), before you
can even start to RTFM.

And that's unnecessarily shooting yourself and your users in the foot.

-- 
David Kastrup