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