[Ardour-Users] Hm...

[David Kastrup]

Lamar Owen <lowen at pari.edu> writes:

> On Monday, August 30, 2010 02:59:23 pm David Kastrup wrote:
>> Lamar Owen <lowen at pari.edu> writes:
>> > Ardour is at least as complicated a program as emacs,
>> 
>> If that's your impression, [snip]
>> Because the combined complexity of the supported tasks in Emacs is
>> rather staggering.
>
> As is what can be done in Ardour.  Right-click is your friend, and so
> is the cursor mode.

Emacs includes a directory editor (actually several including image
browsers), interfaces with version control systems, can transparently
edit files on different machines or as a different user, supports
working on a number of different projects at the same time, has its
manual hyperlinked closely to pretty much everything you can do on the
system, and of course with several entry points from the "Help" menu,
transparently works with any common character encoding (currently,
right-to-left languages are being implemented), includes a rather
capable news- and mailreader (which I using right now), a calculator
capable of arbitrary precision arithmetic and symbolic manipulation, a
lot of IDE support.  You can easily program complex applications (like
the WYSIWYG preview-latex
<URL:http://www.gnu.org/software/auctex/preview-latex.html>) in Elisp,
its own integrated script language.  It allows transparent editing of
compressed and tar (and other archive) files and accessing network ports
and devices and interfacing with processes, all without reverting to
compiled languages.  It has extensive means for customization, and
saving your customizations.  And it is self-documenting: exhaustive
documentation for every function and user interface element is just a
click away.

>> > depending upon the size of the file and how fast your computer is.
>> > You need to drag the start marker
>> What start marker?
>
> See http://en.flossmanuals.net/Ardour/ExportSession (it's yellow,
> labeled start, and is on the Location Markers ruler.)

Once you export.  That implies that the export is not tantamount to a
representation of the completed work.

The natural workflow is to first create your work, then export it, not
create it as a consequence of the export.

I'll readily admit that it is nice to create snapshots (with fadeouts)
of extracts from a complete work as an option.  But paring down some
input to the actually used parts should be able similarly easy without
exporting it first.

You give me a reasonably workable way of solving my current toy problem.
Thanks for that, it will help me.  But it does not scale well to non-toy
problems, and it is not particularly discoverable if you don't know the
solution yet, because you will not tend to try exporting until you have
the feeling you have reached your target.

>> What fadeout handle?
>
> Please see the section headed "Creating Fades in Regions" at
> http://en.flossmanuals.net/Ardour/WorkingWithRegions (it's square,
> filled in, and located in the upper right hand corner of every region;
> the fade in is in the upper left hand corner)

When I drag that, it fades from the start of the recording/region,
judging from the display.  I found no obvious way to limit the fade to
just a limited amount of time.  I am sure I will eventually, but the
"obvious" GUI elements give no clue.

>> > 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?
>
> See http://en.flossmanuals.net/Ardour/ExportSession (it's yellow,
> labeled end, and is on the Location Markers ruler.)

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).

> Please see http://en.flossmanuals.net/Ardour/EditModes for a very
> lucid explanation of the edit and cursor modes.  The edit mode labels
> I might agree about; the cursor mode labels, on the other hand, I find
> very intuitive, and second nature by now.

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?

How do you ensure integrity between documentation and installed version
if the documentation is offline and not synchronized to the installed
version?

>> GUIs are good at offering discoverability, and this should not
>> lightly be thrown away.
>
> Ardour is, at least in my experience, the most intuitive professional
> level DAW out there.

Just because others are worse does not mean one should not strive to be
as good as possible.

> But, at the same time, look at your initial post's rather extreme
> negativity, and, if you were the developer or had been a user of the
> program for some time, what would your reaction have been?

I've been software author as well.  You get annoyed at the whiners, and
at explaining to them the technical limitations and rationale causing
their problem, and why it is not your fault.  After a few dozen
iterations, it gets tiresome, and you work some magic that makes the
reports go away, even though they were full of unrealistic and naive
expectations.  A few days later, you get something along the line "ah,
that's better now, but wouldn't it be nice if".

Annoying as hell.  But after a few years of finally caving in, you have
to admit that part of what makes your application so great and popular
is giving in to all those stupid, annoying and unknowledgeable people
rather than explaining to them why they are stupid, annoying and
unknowledgeable.

>> If Ardour offers me to quit without saving changes, it _is_ wrong if
>> it does not quit without saving changes.
>
> That I would agree with; especially since some changes cannot be
> undone.  I've noticed that, too, but, honestly, it is not an annoyance
> to me, I just know to expect it.  It's certainly something I wouldn't
> want Paul or another developer to waste time on when more important
> things are to be done; if a developer wants to scratch that itch,
> well, I'm sure Paul would accept (or at least look at) a patch.

That's dandy.  "You are an idiot if you expected otherwise, since DAWs
are complex things" isn't.

> Having a 'package' session rather than the current large folder
> structure might be a nice thing; but, then again, that's what ZIP
> files were designed for.  And it's not hard to delete a whole
> directory tree in virtually any Linux dist; just treat the whole tree
> as if it were one file (much like .app directory trees are treated on
> Mac OS X).

Huh?  "rm" does not delete non-empty directories without further
options.  Sure, if you are using Emacs as your directory manager...

> Please take time to take a look at the FLOSS manual (
> http://en.flossmanuals.net/ardour/ ) because Ardour does do things
> differently; understand that its way of doing things does actually
> work for the majority of its users (including me), and that it has
> been in development for ten years (which means that major
> architectural changes, especially stability-robbing ones, aren't
> likely.  That being said, Ardour 3 is a fairly major change, and I
> look forward to trying it out one day....hopefully sooner rather than
> later, just haven't had time to compile it and run it much yet.....)

Sanitizing the GUI does not typically involve changes in the
architecture.

> This isn't intended to call you an idiot;

An "idiot" is an old Greek term meaning "acting as a private person"
rather than in an official function.

So if I get some developers to find "if I were an idiot, I'd know ways
to improve Ardour", that's a good start.

Considering usability, if you feel unable to be an idiot yourself, it
may be a good idea to have access to a few ones.  And I decided to give
early feedback, as long as I manage to be almost completely idiotic.

-- 
David Kastrup