[linux-audio-user] Usability vs Intuitability in Ardour

[Paul Davis]

> this is why i fire up vmware to run samplitude. unlike ardour, i am
> not asked to create a project instantly spewing folders and files
> somewhere that i dont want them. 

i am not at all sure what you mean by this comment. 

on any *nix filesystem, the question of where a user would want a
multitrack audio project that might consume GB's of disk space before
they are done is an important one, partly because the system is not
necessarily single-user. most of the recommendations for building/buying
a DAW for *any* operating system include advice to buy a second non-
system disk (whether or not that is actually correct advice is not
relevant). therefore, the issue of where to put the project/session is a
critical question, and if deferred for too long, becomes very time-
consuming to modify (even a disk-to-disk copy of 80GB takes a while). 

ardour puts all of the files relating to a session into a single
directory/folder, precisely to avoid "spewing folders and files" all
over the place; it asks you where you want this folder to be before you
do anything else.

could you expand on your problems with this design?

> 'peak' files are generated alongside the source file so they arent
> wastefully regenerated on each usage.

ardour generates peak files once, and once only (though it will
automatically regenerate them if the source file is modified or if you
remove the peak file). the files live under:
	
	<session-name>/peaks/*.peak
	<session-name>/sounds/*.wav

they are not in the same directory so that if people want or need to
browse the sounds directory for specific audio files, they do not have
to deal with peak files. in addition, many *nix filesystems do much
better disk block allocation when files are grouped by directory in this
way; we have verified this for ext2 and ext3 for example, where
fragmentation of the audio and peak files is much reduced by splitting
them across directories (they are written "simultaneously", which is
where the disk block allocation issues kick in).

do you have some other issue with the way ardour uses peakfiles?

>  drag in compressed files and instantly use them without waiting for
> them to be uncompressed to wav or fiddling with a cmdline to do this
> beforehand. 

using either nautilus or konqueror, you can drag-n-drop any non-
compressed file into ardour, in a variety of ways. ardour does not
support drag-n-drop of compressed files for 2 reasons:

	a) no appropriate API for reading such files (about to
	    change as soon as libsndfile offers support for ogg)
	b) Ardour is intended to be used for music production in which
	    quality *matters*. Compressed audio is a temporary
	    manifestation of a temporary issue: lack of bandwidth
	    and/or storage space. No serious audio professional 
	    makes music by pasting mp3 samples into their work,
	    and neither should you. Even if only because if someone
	    re-mp3's or ogg-encodes your work, it will sound even
	    more deeply horrible.

> and no need to create new tracks,

so what happens when you've recorded one thing, and want to record
another? you have the option when you create a new session to use
a pre-existing template that will establish tracks + interconnections
for you.

>  or play around in a sphaghetti mess of qjackctl to use stuff that
> cant be used as a 'plugin' aka JAMIn and a bevy of midi-controlled 

i am sorry that you don't like the flexibility that JACK offers. most
people seem to like it a lot once they used to it. i assume that you
also not a fan of reason either, in which "a spaghetti mess" is
literally the primary way to interconnect its modules, or max/msp or
reaktor or pd, all 3 of which also very heavily feature "patching".

one day, you will want to use JAMin without ardour, and at that point,
you might grasp why JACK's modularity/patching model has some real
benefits. and sure, if there was a *single* plugin API that satisfied
everybody's needs and was supported by every single potential host
program fully and correctly, then JACK would be more or less
unnecessary. But no such API exists on any OS platform, and thats part
of the reason why people like JACK, even on OS X.

> the good news is the foundation is solid, but often those with the
> most intuitive ideas on usability are not good programmers, and vice
> versa...

we have listened very very deeply to what has been said about usability
in ardour, and its the primary focus of new work EXCEPT that right now
we are trying to get 1.0 out the door, and switch to GTK2 so that we
have a better platform with which to work on usability issues.