Last Monday 25 July 2005 22:15, Kevin Cosgrove was like: Thanks Kevin. All keybindings have to be learned. I can't use vi without constant reference to the manual. I dare say the same would be true of emacs. I dislike them both and use nedit for everything, simply because it works much more like a Windows based editor, so I had to relearn less in order to get typing when I first migrated. It's nothing to do with intuitabilty either - old habits die hard. cheers, tim hall http://glastonburymusic.org.uk

Steve Harris wrote: Indeed. I have occasion to use OpenOffice, it's very nice, but it's not this writer's tool of choice. I think I'm just partial to things unadorned, like classical guitars, ;) The O'Reilly book on vi is a very good little volume. It includes a handy pull-out for quick command reference. I've also come to admire the emacs Way, especially with anything Lisp-oriented. Powerful stuff there too. Best, dp

On Tue, 26 Jul, 2005 at 10:36AM +0100, tim hall spake thus: must...resist..trying....to...convert... Gah, sod it. Here goes: Emacs might be awkward at first. Just like walking might be awkward when you're used to crawling. That doesn't justify going to work on your hands and knees. People get past the learning curve and use Emacs because once they do, they find that they can do things more quickly and easily than they can in anything else. Some things are just impossible to do in Windows-like editors without a lot of hard work - replace-regexp is my favourite example, and has saved me hours of work. Add to that the syntax highlighting, indentation awareness, cooperation with make, latex, javac, whatever, region comment/uncomment, etc., etc., and you will begin to see why learning Emacs is worth it. Vi people will say the same kind of things about Vi, but of course, they only like Vi because they haven't got used to Emacs yet. And there is one more thing that I love about Emacs that will probably be seen as a problem by others: I don't know all of it. That's right, I enjoy my ignorance. I learn new things all the time, and my "editing experience" is enriched. Please excuse that lapse into marketing speak. Notice I have stayed away from calling Emacs the One True Editor. This isn't because it's not, but because that kind of talk tends to scare people away. Emacs is the only religion I need. -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power)

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.

Creepier sounding than many drinks after a theremin players convention! ;) I'm curious if anyone can incorporate it into music. http://www.nasa.gov/mission_pages/cassini/multimedia/pia07966.html Cheers, Jon Hoskins ----------------------------------------------------------------------- In a world without walls who needs gates or windows? --unknown __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

October wrote: wow, someone's gotta at least try! i remember listening to that saturn probe going in ... nothing like this, though. shayne

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 27 July 2005 15:10, Mario Lang wrote: They have another link, but it points to an identical file with another name... :-( Maybe drop them an email, they might give it to you.

yes, and we've wondered how they manage to do that and discussed it several times over on #ardour. we have never come up with a solution that felt "right" for a potentially multi-user system. ardour was written primarily with capture, not arrangement of existing samples in mind (mostly because that's how most good music gets made, even today). as it evolves towards the kinds of audio manipulation that are centered on pre-existing samples, this is an example of the kind of issue we need to address. i did not want to put the peak file in the same directory as the audio file to avoid some other user from making the opposite complaint: "ardour leaves these stupid .peak files all over the place". there is no standard for peak file formats, so its not as if other applications could use them. who knows, they might even overwrite them! well then we to fix that. it implies that konqueror doesn't supply the same kind of URL/filelist as nautilus despite me told that it did. like DP4 you mean? which simply doesn't play a region if the file is at the wrong SR, with no warning or clue of what is going on? i don't agree that automatic resampling is a desirable goal anyway. i agree that it should be an option for the user, but again, if you are concerned about audio quality, then applying per-region resampling is aburdly expensive. i don't see it harkening back to the old days - i see it as an indication that people don't have their sample libraries set up to match their studio configuration. switching back and forth between SR's is an indication to me that you don't believe in whatever configuration you have. FLAC we will add ASAP. its a good standard. it would be nice if libsndfile could handle it, for the same reasons that we are waiting on libsndfile for ogg support. yes, LASH is a big hole at the moment. i only wish there were 40 hours in the day, or more.

if you import into Ardour (not link), then thats exactly what happens: we resample the audio as we write a new audio file that matches the session sample rate (and uses ardour "native format" (BWF or WAV)). it does not happen if you use "link" (which is what *some* drag-n-drop operations do; it depends on the drop location) because the purpose of using link is to read from a pre-existing sndfile. obviously, we could theoretically do realtime resampling on such material, but i've already outlined my problems with doing that. --p

I continue to claim that as a generalization, not as a rule, that its correct. Good instruments have qualities that the body can learn and the mind cannot. You can certainly make great music using Csound 5, offline rendering and other tools, its just that *most* good music isn't done that way. i don't know what version you are using, but i remember doing a fix for this sometime near beta29. if libsndfile fails to open it, ardour should fail elegantly. if libsndfile has issues with the format, we may do something ugly and horrible. in 2.0, we may start using menus with accelerators and so forth in the item labels, along with the GTK dynamic reassignment model. this is not present in 1.0, for a variety of reasons. there is still the basic problem of keys doing different things in different windows - ardour's mixer and editor deserve to be able to use some keys in their own ways, and GTK (along with Qt) is not well set up for that if you want to use their standard hot key/accelerator systems. i like sonar's interface too, and you might note that we stole the idea of the bar controller from them.