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

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