Re: [linux-audio-dev] User Interface
ljp wrote: To me, music is more important than any library ideologies. I wouldn't give a rats ass if software was made with QBASIC, as long as it compiles fairly easily (not alot of excessive library inclusion that I have to install every libtom-libdick-and-libharry libs just to compile it- because there no binaries available), functions well, and serves the purpose that I use it for. I'm willing to check out glame. I'll let ya know what I think about it. ljp While I can see your point of view, I think you forgot an even more important factor: ...and I'll be able to use the stuff I wrote 2 years from now. I'm from a classical background, perhaps this isn't important in more commercially driven music. But I'd spend extra effort to make sure the program I was using was maintainable and portable rather than go for the quick and easy solution. So QBasic is out: being non-free, the language spec might change, so I couldn't recompile it on my next computer. (I realise that was just an hyperbole 8-) For the reason of data obsolescence alone, I'd say the design issues are actually at least as important as user interface ones. But then, I'm still using LaTeX 8-) Nick/
Re: [linux-audio-dev] User Interface
At 22:04 7/25/2001 -0400, Paul Davis wrote: Paul Winkler writes: I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. [ ... ] i've worked experimentally and professionally in soft editing and multitrack environments for many years across several platforms. it's both my income and my studio. in this way i have alot to say about glame largely from a comparitive perspective. however criticisms so far seem to largely surround inconsistencies and counter-intuitive windowing configurations in interface design. i'll make some time tonight and get some writing to you here tomorrow. keep hearing many pro-audio ppl lamenting the fact there is not more extensive and usable editor / multitrack for linux. in some ways we can't really complain? - what glame can do already is testimony to many months of commitment + labour just for the satifaction of contributing to a good thing. criticisms of glame therefore shouldn't be absolutist and totalised write-offs of the app based on - eg: libs?? that's political veganism as applied to software design - all in all ensuring a pointlessly mypoic and distracted approach to the goals of developing a good tool. de| _ / a - b, b -c, a - d, d - c ...and so on... \ _
Re: [linux-audio-dev] User Interface
On Wed, 25 Jul 2001, Paul Davis wrote: Paul Winkler writes: I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. [ ... ] Can't compile it without GNOME. I don't like that. I guess that makes me a luddite. Oh well. You can. Use --disable-gui and you'll get what you deserve. i *am* a luddite, and i don't like GNOME-dependent audio software either. Its certainly better to depend on wide spread GNOME than to depend on 1000 unstable, nonpackaged, hard-to-compile, seperately distributed libs. Can you say adour? Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
Re: [linux-audio-dev] User Interface
On Wed, 25 Jul 2001, Paul Davis wrote: Paul Winkler writes: I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. [ ... ] Can't compile it without GNOME. I don't like that. I guess that makes me a luddite. Oh well. i *am* a luddite, and i don't like GNOME-dependent audio software either. Harhar, welcome to kindergarden folks :-) So we're back at the stage where we discuss the best widget set for a whole year? Cheers, Mag -- In India, cold weather is merely a conventional phrase and has come into use through the necessity of having some way to distinguish between weather which will melt a brass door-knob and weather which will only make it mushy. -- Mark Twain
Re: [linux-audio-dev] LAAGA app client question
On Wed, 25 Jul 2001 13:13:05 -0400
[EMAIL PROTECTED] wrote:
Paul, I am trying to use FLTK instead of GTK, but I don't get it to work...
It crashed inside X11 functions. I have seen this before, and it always
was related to multithreading and FLTK not being threadsafe, but I don't
understand how that could be a problem, since I run all fltk stuff in the
main thread.
main()
{
... setup fltk, e.g Fl_Window w(200,200); w.show();
laaga_client_t = laaga_open (myname);
... setup laaga ...
laaga_activate (client);
Fl::run ();
laaga_close (client);
}
Any suggestions?
send me the client source, and i'll try it out and try to understand
whats going on.
It is a very simple example, it's your ae_client.c with a slider to control
the gain.
I try this on Debian potato, XFree86 3.3.6
Maarten
#include stdio.h
#include errno.h
#include unistd.h
extern C
{
#include laaga/laaga.h
}
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Slider.H
laaga_port_t *my_input_port;
laaga_port_t *my_output_port;
float gain = 1.;
int
process (nframes_t nframes, void *arg)
{
sample_t *out = (sample_t *) laaga_port_get_buffer (my_output_port, nframes);
sample_t *in = (sample_t *) laaga_port_get_buffer (my_input_port, nframes);
memcpy (out, in, sizeof (sample_t) * nframes);
for (unsigned int i = 0; inframes; i++)
{
out[i] *= gain;
}
return 0;
}
int
bufsize (nframes_t nframes, void *arg)
{
printf (the maximum buffer size is now %lu\n, nframes);
return 0;
}
int
srate (nframes_t nframes, void *arg)
{
printf (the sample rate is now %lu/sec\n, nframes);
return 0;
}
void callback(Fl_Slider* s)
{
gain = s-value();
}
int
main (int argc, char *argv[])
{
Fl_Window w(0,0,100,120);
Fl_Slider s(10,10,20,100);
w.show();
s.callback((Fl_Callback*) callback);
laaga_client_t *client;
if ((client = laaga_client_new (fltktest)) == 0) {
fprintf (stderr, laaga server not running?\n);
return 1;
}
laaga_set_process_callback (client, process, 0);
laaga_set_buffer_size_callback (client, bufsize, 0);
laaga_set_sample_rate_callback (client, srate, 0);
printf (engine sample rate: %lu\n, laaga_get_sample_rate (client));
my_input_port = laaga_port_register (client, myinput, LAAGA_DEFAULT_AUDIO_TYPE, LaagaPortIsInput, 0);
my_output_port = laaga_port_register (client, myoutput, LAAGA_DEFAULT_AUDIO_TYPE, LaagaPortIsOutput, 0);
if (laaga_activate (client)) {
fprintf (stderr, cannot activate client);
}
printf (client activated\n);
if (laaga_port_connect (client, ALSA I/O:Input 1, my_input_port-shared-name)) {
fprintf (stderr, cannot connect input ports\n);
}
if (laaga_port_connect (client, my_output_port-shared-name, ALSA I/O:Output 1)) {
fprintf (stderr, cannot connect output ports\n);
}
Fl::run();
printf (done sleeping, now closing...\n);
laaga_client_close (client);
exit (0);
}
Re: [linux-audio-dev] User Interface
On Wed, 25 Jul 2001, Andy Lo A Foe wrote: I installed glame from Debian unstable (0.4.2) and, having used just Sound Forge just the other day; how about a SF like interface? Simple, and to the point, with nice easy toolbars 'n stuff?! I had to read the manual to even open a WAV file in GLAME, not good :) You want to try 0.5.2 which has toolbars (but you still need to read the manual to figure out how to open a WAV file :)). (probably the last person who should complain about user interface design, *cough* alsaplayer *cough*) :) UI is always hard and time consuming. Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
[linux-audio-dev] what's wrong with glame
This is a fairly lengthy rant on the latest glame. Some of you might find it boring. It's really directed at the authors. What I say here needs to be taken in context. My requirements for an editor are fairly heavy as I make both commercial special effects and noise/electroacoustic music. It's rare that I work under DAT level audio - 48khz. But like a normal studio it's not uncommon for me to have 50 or 60 audio files open at the same time. Similarly, with my electroacoustics, I rarely work under 4 channels. So in this way i'm not your ideal subject. However I do produce alot of work for various multimedia productions, including games, which i think includes your target user. I say this because while glame isn't advanced in other areas, you have placed a strong emphasis on signal processing. Two different systems are running glame in my studio, one is a debian box and the other runs suse [both latest kernels (now) thanks to a bad analogy from paul davis] All required libs are installed. I noticed that both don't have a play head that follows the audio - instead it remains static. In the install notes you said this worked - I may have done something wrong. Also it should be said that I've only been using Glame for a week or so, forgive me for the things I've overlooked [short keys / menu's etc]... I'll begin: The idea of a 'project' is a nice approach - but it tends to assume that one is about to embark on something of a large scale. In other environments this is also called the session - which is an option only if you want to save global setting as applied specifically to your work, or an arrangement, as in cool edit pro [windows]. Often however i don't want to make a project, so much as quickly edit a wave. Most desktop studios are engaged in editing samples every few minutes during a normal day. This is where glame really struggles to be useful. What tends to happen in most studios is users become loyal to an editor through familiarity. As a result one editor is chosen as the native editor for all situations, so even when you're in another app, you can click [something like 'editor'] and your waveform immediately appears. Also it's necessary to be able to click on a sound-file and immediately bring it up in waveform view ready to go. In these two ways, 'setting up a project' blocks access to the urgent role of the editor in any audio. Glame's functionality needs to be considered within this hierachy of needs: Most studios, home and pro, require these in an editor /multitracker /dsp studio: Open sample [resample / attentuate / trim Record sample [line in or another output from app] Edit sample / signal process /clean [many of these open at once] Multitrack session [for composition, syncing and mix down] Custom project / session / filternetwork By orienting work around the 'project' you're stopping glame from becoming a popular [frequently used] editor. Once I made a project, i had to 'import audio'!! As though audio were not the native media of the app. All good apps assume that 'open file' leads to a wave. Cool edit pro [which is becoming so popular that many major studios [including the ABC in my country] are ditching pro-tools] simply has 'open' when in 'waveform view' - since in that window, you're always going to be opening soundfiles...import in so many desktop studios represents a special function, that's why when i first used glame, i reached for the 'add stereo wave' item. Even once i've imported the audio i'm still barred; held back before getting on with the job of editing...now i have to select the text-that-represents-my-file and choose to 'edit it', as though there were other things i might want to do with it instead. So i right click on the name of the file [?] and then choose 'edit', which brings up the waveform view. And the waveform view is nothing to smile about - black and white is a bad choice of rendering. High contrast schemes like this make a 10 hour session in the editor a strain, though the wearing of sunglasses indoors is particular to this field. At this stage I realise that I loaded the wrong file[s], to get rid of it from the project list i have to [delete] [as opposed to the inuitive, 'close'] and then 'empty the trash' [what trash? and why should i [?] - implying that i have the option to revoke my decision once it's in the trash]. Back in the edit mode with the right file I look first for my peak values, trying to get a sense of how i should attentuate the file. Also because i have to, say, make a file exactly 10.253 seconds in length i look for the time [this probably sounds ridiculaous but it happens often when making sound for film or games]. also accuracy is a kind of confidence. I find that there aren't even samples, rms, or 'beats' as alternative timing schemes - many other media packages require these time scalings for sync up - in this way glame further rarifies it's position as a stand-alone-tool. Most importantly however, there is no means of
Re: [linux-audio-dev] User Interface
thank glameness for the filter-network. a surprise to find something of this flexibility attached to an editor under linux. btw i don't expect glame to be a multitrack studio, but will give mixing down [recent post] a shot. de| _ / a - b, b -c, a - d, d - c ...and so on...\ _
Re: [linux-audio-dev] User Interface
ljp writes, in response to two criticisms of GNOME dependency: To me, music is more important than any library ideologies. I wouldn't give a rats ass if software was made with QBASIC, as long as it compiles fairly easily and then continues: (not alot of excessive library inclusion that I have to install every libtom-libdick-and-libharry libs just to compile it- because there no binaries available), which IMHO is precisely the problem with depending on GNOME ... --p
Re: [linux-audio-dev] what's wrong with glame
On Thu, 26 Jul 2001, delire wrote: This is a fairly lengthy rant on the latest glame. Some of you might find it boring. It's really directed at the authors. What I say here needs to be taken in context. My requirements for an editor are fairly heavy as I make both commercial special effects and noise/electroacoustic music. It's rare that I work under DAT level audio - 48khz. But like a normal studio it's not uncommon for me to have 50 or 60 audio files open at the same time. Similarly, with my electroacoustics, I rarely work under 4 channels. So in this way i'm not your ideal subject. However I do produce alot of work for various multimedia productions, including games, which i think includes your target user. I say this because while glame isn't advanced in other areas, you have placed a strong emphasis on signal processing. Ok, you actually _seem_ to be our ideal subject - somehow :) For the following I will assume you tried GLAME 0.5.2 and mark things that are _not_ available with 0.4.2 with a [~0.4.2]. Two different systems are running glame in my studio, one is a debian box and the other runs suse [both latest kernels (now) thanks to a bad analogy from paul davis] All required libs are installed. I noticed that both don't have a play head that follows the audio - instead it remains static. In the install notes you said this worked - I may have done something wrong. Also For esd output we didnt bother to add support for it (blame us - will fix this in a minute), for other methods it should work [~0.4.2] it should be said that I've only been using Glame for a week or so, forgive me for the things I've overlooked [short keys / menu's etc]... I'll begin: The idea of a 'project' is a nice approach - but it tends to assume that one is about to embark on something of a large scale. In other environments this is also called the session - which is an option only if you want to save global setting as applied specifically to your work, or an arrangement, as in cool edit pro [windows]. Ok, our whole concept of the tree-view with projects is that you have exactly one seession which handles multiple projects (aka subtrees). Maybe not really obvious / useful. Often however i don't want to make a project, so much as quickly edit a wave. Most desktop studios are engaged in editing samples every few minutes during a normal day. This is where glame really struggles to be useful. Is this because of the many steps you need to do before you are presented with the wave editor? If so, adding shortcuts for this is easy. Or are there more fundamental problems? What tends to happen in most studios is users become loyal to an editor through familiarity. As a result one editor is chosen as the native editor for all situations, so even when you're in another app, you can click [something like 'editor'] and your waveform immediately appears. Also it's necessary to be able to click on a sound-file and immediately bring it up in waveform view ready to go. In these two ways, 'setting up a project' blocks access to the urgent role of the editor in any audio. Ok. Noted. I suppose, we'll add a Project/Edit file... main menu entry which just inserts the imported wave as a new project and opens up the wave editor with it. Glame's functionality needs to be considered within this hierachy of needs: Most studios, home and pro, require these in an editor /multitracker /dsp studio: Open sample [resample / attentuate / trim Record sample [line in or another output from app] Edit sample / signal process /clean [many of these open at once] Multitrack session [for composition, syncing and mix down] Custom project / session / filternetwork By orienting work around the 'project' you're stopping glame from becoming a popular [frequently used] editor. Once I made a project, i had to 'import audio'!! As though audio were not the native media of the app. All good apps assume that 'open file' leads to a wave. Cool edit pro [which is becoming so popular that many major studios [including the ABC in my country] are ditching pro-tools] simply has 'open' when in 'waveform view' - since in that window, you're always going to be opening soundfiles...import in so many desktop studios represents a special function, that's why when i first used glame, i reached for the 'add stereo wave' item. Even once i've imported the audio i'm still barred; held back before getting on with the job of editing...now i have to select the text-that-represents-my-file and choose to 'edit it', as though there were other things i might want to do with it instead. So i right click on the name of the file [?] and then choose 'edit', which brings up the waveform view. And the waveform view is nothing to smile about - black and white is a bad choice of rendering. High contrast schemes like this make a 10 hour session in the editor a strain, though the wearing of sunglasses indoors is particular
Re: [linux-audio-dev] User Interface
On Thu, 26 Jul 2001, Paul Davis wrote: You can. Use --disable-gui and you'll get what you deserve. Heh. :) Thats not really an answer ... :) i *am* a luddite, and i don't like GNOME-dependent audio software either. Its certainly better to depend on wide spread GNOME than to depend on 1000 unstable, nonpackaged, hard-to-compile, seperately distributed libs. Can you say adour? Well, obviously, we disagree about that. Sure :) [lots of libs deleted] If you have any suggestion on how to reduce the library set, or improve on the functionality offered by each part, or package Ardour for easier compilation, or whatever, I'd love to hear about it. And I'm not being sarcastic. Include your custom libs into the ardour CVS / tarball. Or at least provide a means to do a single ./configure make. I don't dislike GNOME because its big. I dislike it because it doesn't Err, perhaps people dont understand which part of GNOME GLAME is using - GLAME solely uses libgnomeui libgnome and libgnomesupport, it doesnt depend on using GNOME as desktop. seem to me to offer anything to the kind of programs we are writing. Can you point to the functionality that GNOME provides for glame? libgnomeui provides the canvas widget which is very nice, and stuff for common message/error dialogs. Also automated menu and toolbar management. libgnome (or gnomesupport, dont know) provides a way to store application config stuff, also I think the gnome help functionality is hooked there. Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
Re: [linux-audio-dev] User Interface
If you have any suggestion on how to reduce the library set, or improve on the functionality offered by each part, or package Ardour for easier compilation, or whatever, I'd love to hear about it. And I'm not being sarcastic. Include your custom libs into the ardour CVS / tarball. Or at least provide a means to do a single ./configure make. Well, that's very hard to do, because the complete step is really: ./configure make make install because you can't build each library until the ones it depends upon are built *and* installed. the only way around that is to build+link against the uninstalled versions, which is potentially buggy after a later install step is done. however, the basic problem is that ardour is not the only application that uses these libraries, and so they really are *not* part of ardour. when other applications package libraries into their source trees, they tend to used only by the application itself. i can't think of a single application that comes with a library in its source tree that is also used by another application. [ i know someone is going to come up with an example now ] the ardour-dev list has been over this many times, and in fact for a while, the libraries were part of the source tree. this turned out to be even more of a pain than having them outside, so i changed back again. libgnomeui provides the canvas widget which is very nice, and stuff agreed. its a delightful piece of work. thats why i use the backport, GtkCanvas, which avoids all GNOME connectivity :) I like it even more for that reason ... for common message/error dialogs. Also automated menu and toolbar management. Yeah, I've been highly critical of the GNOME people for putting these things in GNOME and not GTK+ where they belong. Its partly politics (they wanted to provide more reasons for people to use GNOME) and partly development issues (GTK+ was under a feature freeze). libgnome (or gnomesupport, dont know) provides a way to store application config stuff, also I think the gnome help functionality is hooked there. Once again, I am mostly critical of the GNOME people for building each of these very useful things into a set of libraries whose dependencies cannot be shrunk down from the complete suite of GNOME libraries. This is part of the creaping featurism that until recently Linux was relatively free of; these days, it seems you can't use a help library without requiring XML parsers, CORBA support, libinet, gzip compression, image drawing libraries and the rest. The problem, of course, is that just like with my libraries, there *is* a reason for all this inter-connectedness: functionality. And this is a very difficult tradeoff. On the one hand, having a library that works with text but also with XML-defined network-remote compressed CORBA image objects is a very nice thing. But on the other hand, it creates lots of headaches when the size of all the libraries needed to build the web of dependencies is so large that upgrading is not a simple matter. If the libraries within GNOME were all stable and unchanging, or at least changing at the same rate as those from XFree86 or even GTK+, it wouldn't be a problem. But as it is, trying to do development of an application against a library base that changes quite often is very difficult. And I should know :) --p
Re: [linux-audio-dev] User Interface
On Thu, 26 Jul 2001, Paul Davis wrote: If you have any suggestion on how to reduce the library set, or improve on the functionality offered by each part, or package Ardour for easier compilation, or whatever, I'd love to hear about it. And I'm not being sarcastic. Include your custom libs into the ardour CVS / tarball. Or at least provide a means to do a single ./configure make. Well, that's very hard to do, because the complete step is really: ./configure make make install because you can't build each library until the ones it depends upon are built *and* installed. the only way around that is to build+link against the uninstalled versions, which is potentially buggy after a later install step is done. however, the basic problem is that ardour is not the only application that uses these libraries, and so they really are *not* part of ardour. when other applications package libraries into their source trees, they tend to used only by the application itself. i can't think of a single application that comes with a library in its source tree that is also used by another application. [ i know someone is going to come up with an example now ] the ardour-dev list has been over this many times, and in fact for a while, the libraries were part of the source tree. this turned out to be even more of a pain than having them outside, so i changed back again. Ok, it was just ranting about you blaming GLAME to use the GNOME libs... libgnomeui provides the canvas widget which is very nice, and stuff agreed. its a delightful piece of work. thats why i use the backport, GtkCanvas, which avoids all GNOME connectivity :) I like it even more for that reason ... But - GtkCanvas is nowhere installed, yeah, we could include it in our tree, but... its EASIER to depend on gnome for that. for common message/error dialogs. Also automated menu and toolbar management. Yeah, I've been highly critical of the GNOME people for putting these things in GNOME and not GTK+ where they belong. Of course. But its not really a GNOME vs GTK+ but the lack of a standard GTK+extra lib. Its partly politics (they wanted to provide more reasons for people to use GNOME) and partly development issues (GTK+ was under a feature freeze). I dont think so. libgnome (or gnomesupport, dont know) provides a way to store application config stuff, also I think the gnome help functionality is hooked there. Once again, I am mostly critical of the GNOME people for building each of these very useful things into a set of libraries whose dependencies cannot be shrunk down from the complete suite of GNOME libraries. This is part of the creaping featurism that until recently Linux was relatively free of; these days, it seems you can't use a help library without requiring XML parsers, CORBA support, libinet, gzip compression, image drawing libraries and the rest. Mostly annoying gnome-dev libs depend on installed esd development... But today requiring GNOME (we're happy with 1.0 up to a CVS snapshot, compatibility is not an issue) is not a problem at all as all distributions ship with gnome libs, so basically before compiling GLAME do an apt-get install gnome-dev or rpm -i gnomed (or whatever the names are). This is easier than going through your 6 homegrewn libs. The problem, of course, is that just like with my libraries, there *is* a reason for all this inter-connectedness: functionality. And this is a very difficult tradeoff. On the one hand, having a library that works with text but also with XML-defined network-remote compressed CORBA image objects is a very nice thing. But on the other hand, it creates lots of headaches when the size of all the libraries needed to build the web of dependencies is so large that upgrading is not a simple matter. If the libraries within GNOME were all stable and unchanging, or at least changing at the same rate as those from XFree86 or even GTK+, it wouldn't be a problem. But as it is, trying to do development of an application against a library base that changes quite often is very difficult. Yes, so you dont develop against a moving target, but against the stable version (we're not building against gtk2.0 f.i.) - or you at least dont _depend_ on such libs, but only support them, if available (like we do with certain alsa versions or liblameenc to mention two). Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
Re: [linux-audio-dev] User Interface
On Thu, 26 Jul 2001, Paul Davis wrote: ljp writes, in response to two criticisms of GNOME dependency: To me, music is more important than any library ideologies. I wouldn't give a rats ass if software was made with QBASIC, as long as it compiles fairly easily and then continues: (not alot of excessive library inclusion that I have to install every libtom-libdick-and-libharry libs just to compile it- because there no binaries available), which IMHO is precisely the problem with depending on GNOME ... Err - for which part of GNOME or its dependencies are no binaries available??? Paul, what are you smoking??? The above is precisely the problem with adour which certainly doesnt depend on GNOME but libraries for which no binaries are available... Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
Re: [linux-audio-dev] User Interface
Its partly politics (they wanted to provide more reasons for people to use GNOME) and partly development issues (GTK+ was under a feature freeze). I dont think so. This is not speculation on my part. I've been told so by people who work on both GTK+ and GNOME for RH. apt-get install gnome-dev or rpm -i gnomed Do you know how long this would take on my connection? About 35 times as long as cvs -z3 update -dP make clean make all make install. Thats another reason I like CVS :) XFree86 or even GTK+, it wouldn't be a problem. But as it is, trying to do development of an application against a library base that changes quite often is very difficult. Yes, so you dont develop against a moving target, but against the stable version (we're not building against gtk2.0 f.i.) - or you at least dont _depend_ on such libs, but only support them, if available (like we do with certain alsa versions or liblameenc to mention two). Well, even with GNOME, I've run into problems with applications in at least two areas: imlib seems to change fairly regularly, and just as regularly breaks applications that were doing funky things, and libxml has also been subject to many bug fixes that periodically break XML-using code. Thats why I prefer to tell people to get libimlib-blah-blah and get libxml-foo-foo than install GNOME because there's no way to know if they'll end up with the libxml that doesn't properly list all child property nodes under some circumstances or ... --p
Re: [linux-audio-dev] User Interface
I don't dislike GNOME because its big. I dislike it because it doesn't Err, perhaps people dont understand which part of GNOME GLAME is using - GLAME solely uses libgnomeui libgnome and libgnomesupport, it doesnt depend on using GNOME as desktop. I think that's a common confusion -- a lot of people seem to confuse running a Gnome application with having to run a Gnome desktop, and it just ain't the same at all. The Gnome libs are under 100 MB, so it's really not that big a deal. seem to me to offer anything to the kind of programs we are writing. Can you point to the functionality that GNOME provides for glame? libgnomeui provides the canvas widget which is very nice, and stuff for common message/error dialogs. Also automated menu and toolbar management. libgnome (or gnomesupport, dont know) provides a way to store application config stuff, also I think the gnome help functionality is hooked there. Lots of very nice, easy to use stuff there. -- Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605 Department of Computer Science FAX -- (505) 646-1002 New Mexico State University http://www.cs.nmsu.edu/~pfeiffer SWNMRSEF: http://www.nmsu.edu/~scifair
Re: [linux-audio-dev] User Interface
Err - for which part of GNOME or its dependencies are no binaries available??? Paul, what are you smoking??? The above is precisely the problem with adour which certainly doesnt depend on GNOME but libraries for which no binaries are available... the words were: (not alot of excessive library inclusion that I have to install every libtom-libdick-and-libharry libs just to compile it- because there no binaries available), which i read as saying i have to install a bunch of libraries because i have to compile an application and i have to compile the application because the author does not make binaries available. this is true of ANY application that is not distributed as a statically-linked binary. --p
Re: [linux-audio-dev] User Interface
On Thu, 26 Jul 2001, Paul Davis wrote: Err - for which part of GNOME or its dependencies are no binaries available??? Paul, what are you smoking??? The above is precisely the problem with adour which certainly doesnt depend on GNOME but libraries for which no binaries are available... the words were: (not alot of excessive library inclusion that I have to install every libtom-libdick-and-libharry libs just to compile it- because there no binaries available), which i read as saying i have to install a bunch of libraries because i have to compile an application and i have to compile the application because the author does not make binaries available. this is true of ANY application that is not distributed as a statically-linked binary. Dynamically linked usually suffices. GLAME 0.4.2 is available as binary debian package in the unstable distribution, its also included in the mandrake distribution. I dont know about other distribution, nor if someone makes GLAME 0.5.2 binary packages available. Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
Re: [linux-audio-dev] User Interface
7/26/2001 19:59:58, Paul Davis [EMAIL PROTECTED] wrote: ljp writes, in response to two criticisms of GNOME dependency: To me, music is more important than any library ideologies. I wouldn't give a rats ass if software was made with QBASIC, as long as it compiles fairly easily and then continues: (not alot of excessive library inclusion that I have to install every libtom-libdick-and-libharry libs just to compile it- because there no binaries available), which IMHO is precisely the problem with depending on GNOME ... True, but I suppose ardour is any better? I want to try ardour, but gave up trying to compile it? WHY? Because the libraries you use are 1) obscure and hard to locate 2) there's at least one library that you have (had?) ONLY cvs access to, making it for developers only. 3) I'd rather use something that allows me to record music rather than compiling/installing several, several unstable libraries to get it to even compile, much less link correctly. I simply gave up on it. Besides, I can go download Cubase and be recording in about 5 minutes. No compiling needed. No searching for obscure unstable libraries to compile, which in turn often require installing OTHER libraries. Granted gnome is like that also. but ardour is worse in that aspect. It's like a pot calling the kettle black. I'm not disparging all the work you do. As a developer myself, I know that you put alot of time into the code, and I respect you for that. In fact, I'd love to try ardour out. I bought an rme card because of linux drivers. But it's the library thang. One thing that would help, is on the ardour web page (I haven't checked out the web page lately- sorry) , have links to all the libraries needed. Much better than finding out during ./configure and having to do a google search for them, one by one when it fails to configure. I hate that. Gnome is like that also. or even better, links to any binaries that the dist's. might have available. ljp
Re: [linux-audio-dev] User Interface
If your connection is limited, use a CD set - GLAME doesnt require up to date versions of any lib it depends on. GLAME might not, but other applications that use part of the GNOME lib set do. So if I install GNOME from a CD, and then find that another GNOME app wants a later version, I'm stuck and I invariably need to download the entire thing. I spent almost an entire night once (mostly because of rpm's deficiecies, its true) tracking down all the changes that rippled out from a simple upgrade to one of the GNOME libs. Imlib is broken. Dont use it. I don't, but I have apps on my system that do. And when they cease to work with the imlib I have or the one I just updated to ... Well - you get bugreports, you fix your code. Its bad to require libxml-1.8.7-3 and nothing else - just fix your code to work with any known libxml. The problem is, I don't use libxml, I use libxml++. The bugs in libxml propagate into libxml, but in different forms depending on the bug and the versions of libxml/libxml++. In addition, libxml++'s developer has done a BAD thing and changed API's without changing major version numbers. This, needless to say, makes everything even worse. My options: I could do the Windows thing: every app comes with its own set of DLL's (though they are versioned, so we stand more chance of avoiding DLL-hell, but its not guaranteed), which are installed along with the app. Or I can work with what's out there, as best as possible. The world of libraries that we are using is far from perfect, and all kinds of stupid problems are going to arise from time to time. The GNOME folks are doing a good job considering the size of their endeavour, but its precisely that size (and scope) of it that keeps me away from using any part of it unless i can do so as a standalone library (libxml is one example of such a thing). --p
Re: [linux-audio-dev] User Interface
(not alot of excessive library inclusion that I have to install every libtom-libdick-and-libharry libs just to compile it- because there no binaries available), which i read as saying i have to install a bunch of libraries because i have to compile an application and i have to compile the application because the author does not make binaries available. this is true of ANY application that is not distributed as a statically-linked binary. Dynamically linked usually suffices. You still have to *install* the libraries used by the application. Thats all I meant, and it was what I read the complaint as being all about. Installing libraries is always necessary without static linking. The fact that many people have some version of the GNOME libs hanging around doesn't change that requirement, it just happens to be pre-fulfilled. --p
[linux-audio-dev] LAAGA name
would it be too dreadfully obnoxious and steinberg sniping to rename LAAGA as FreeWire ?
Re: [linux-audio-dev] User Interface
True, but I suppose ardour is any better? No, Ardour is not better. However, the set of libraries on which it depends is smaller than GNOME. I want to try ardour, but gave up tr ying to compile it? WHY? Because the libraries you use are 1) obscure and hard to locate 2) there's at least one library that you have (had?) ONLY cvs access to, making it for developers only. It *is* for developers only at this point. I've never tried to make any other claim. 3) I'd rather use something that all ows me to record music rather than compiling/installing several, several unstable libraries to get it to even compile, much less link correctly. I simply gave up on it. Besides, I can go download Cubase and be recording in about 5 minutes. No compiling needed. No searching for obscure unstable libraries to compile, which in turn often require installing OTHER libraries. Excellent. Then use Cubase. Its a very good program. If it ran on Linux and came with source code, I would never have started working on Ardour but would have spent my time improving Cubase. I'm not disparging all the work you do. As a developer myself, I know that you put alot of time into the code, and I respect you for that. In fact, I'd love to try ardour out. I bought an rme card because of linux drivers. But it's the librar y thang. As pointed out earlier, there are a total of about 22 libraries that ardour needs that you *might* not find on any regular X-equipped linux system. Of these, 13 are stable 3rd party libraries, most of them part of the GTK+/Gtk-- constellation, and all available as binaries. So if you have Gtk-- properly installed, you've just got 4 additional stable libraries to install (art_lgpl, gtk-canvas, guile, gdbm). Then there is libsndfile, which Erik hasn't been working on much recently, and so even though its not finished it could be considered stable. Then there are 5 of my own libraries that are moderately unstable, plus alsa-lib (hah!) plus libardour itself. Why don't I make my libraries available as RPMs or debian packages? Because I have better things to do with my development time than rebuilding, reuploading, re-doing a web page every time I fix a bug in a library. Thats why Ardour is currently a developer only system, and its why I use CVS, because I assume that developers will be happy using CVS because of the ease and low cost of updating it provides. That said, there have been very, very few changes in 4 of the 5 of my libraries in the last 6 months, which may be a sign that its time to make them available as RPMs and debian packages. libardour won't be available as an RPM or whatever for quite some time, since it is often revised several times a day. One thing that would help, is on the ardour web page (I haven't checked out th e web page lately- sorry) , have links to all the libraries needed. Much bette the requirements page already did this, and i just updated it to include a couple of new links and to revise the old ones. http://ardour.sourceforge.net/requirements.html or even better, links to any binaries that the dist's. might have available. its proven *extremely* problematic to use binaries of C++ libraries. C++ is much more susceptible than C to compile-time conditions. in addition, the dists have become increasingly incompatible due to compiler/library issues, and furthermore, they include code changes that are not in the original source ball, making it more difficult for me to track bug reports accurately. --p
Re: [linux-audio-dev] what's wrong with glame
So if we pop up the waveeditor right away you would be happy? ohhh yes ; ) and as for all that's below - look great so far - richards comments earlier seemed clear-headed also. you guys already know this stuff! i'll pick through it all and get back to you tommorrow. de| And the waveform view is nothing to smile about - black and white is a bad choice of rendering. High contrast schemes like this make a 10 hour session in the editor a strain, though the wearing of sunglasses indoors is particular to this field. Agreed :) At this stage I realise that I loaded the wrong file[s], to get rid of it from the project list i have to [delete] [as opposed to the inuitive, 'close'] and then 'empty the trash' [what trash? and why should i [?] - implying that i have the option to revoke my decision once it's in the trash]. Thats actually a new feature because I delete some samples I made accidentially before I saved them. But this could be made configurable in the preferences menu. Or a popup Really delete file? But that last option IMHO suxx. I find that there aren't even samples, rms, or 'beats' as alternative timing schemes - many other media packages require these time scalings for sync up - in this way glame further rarifies it's position as a stand-alone-tool. Ok that goes hand in hand with the still bad wavewidget which lacks support for all that stuff. There needs to be an option for resampling file in conjunction with shifitng bit-rates. eg: 48khz / 24bit 22.05khz / 8bit. preferably with dithering and noise-shaping in order to maintain the integrity of the signal. this would enable the multimedia community to use glame for web and cdrom without fscking around in other apps. Actually you can resample with rather good quality. But you have to setup a network for that purpose. Just stream the audio into FFT-FFT_RESAMPLE- IFFT. IMHO the quality is better than sox with polyphase resampling which produces glitches. Saving with other resolution than 16bit would go into exporting features. [looks like a recycle symbol] that I assumed probably meant 'loop' - that strangely means 'view all'. I couldn't and still can't find how to loop on a selection in glame... You can't :( I can't do it in either install of glame. For this reason i can't really use it at all. Similarly all editors have a key-bind for play and stop!!! Why doesn't glame?? hmm, ok, you'll find the default keybindings in default-accels. On the other hand it should be easy to add keybindings for that stuff. Are you on glame-users yet? enough i have to then hit a second play button in a strange play control that pops up!!! That i found really frustrating. Yupp :) It is. representation of commonly expected envelope based amplitude fade, with presets for bell, curved and the requisite attack/decay. Ok, if you can explain to me in detail how that fader should look like I happily extend it. useless. The worst case here is 'volume adjust', which uses [instead of 'dB', or 'percent'!!] 'factor' whatever that is. Here information is use with confidence. True, what do you like better, dB or percent or both? Factor is just the multiplication factor. So 1.5 = 50% increase. Ok thanks, you're the first to actually give some decent feedback. Without that we just don't know what's missing, what people want. And I haven't used all those windows software on a regular basis.
Re: [linux-audio-dev] what's wrong with glame
- Original Message - From: Paul Davis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 26 July 2001 11:29 Subject: Re: [linux-audio-dev] what's wrong with glame I'm not the obvious person to define GLAME, but: The idea of a 'project' is a nice approach - but it tends to assume that one is about to embark on something of a large scale. In other environments this is also called the session - which is an option only if you want to save global setting as applied specifically to your work, or an arrangement, as in cool edit pro [windows]. Often however i don't want to make a project, so much as quickly edit a wave. Most desktop studios are engaged in editing samples every few minutes during a normal day. This is where glame really struggles to be useful. This is where almost all multitrack-capable systems tend to fall over. Its very common to see people use ProTools *and* a wave editor like soundforge or Cool Edit Pro. The multitrack systems are just that: tools for recording, playing, arranging multitrack recordings. If you want a wave editor then you either have to: 1) use a dedicated wave editor 2) find the wave editor *within* the multitrack system Thats not to say that (2) shouldn't be easy, and that editor shouldn't be good. But its very likely that you would still continue using a dedicated external editor even if the one inside the MT system was pretty usable. sometime this is the case, but as i may have indicated, this is dispreferred in the ends of efficiency. the all in one studio, though more ambitious, is a lovely thing to drive. however you are right, one becomes habitually addicted to a good editor, and will often be used independently of the multitrack studio as a result. You're also missing out on a crucial distinction between editing music, which is mostly a matter of *arranging* existing audio, and editing wavefiles, which is concerned with the itty-bitty details of samples and so forth. A tool (possibly within-a-tool) that is well suited for the first of these is likely to be not well suited to the second, and vice versa. I think you know this, but its a distinction that hasn't even been obvious to date in any Linux audio software (except perhaps in MusE and Jazz, neither of which have good audio editors). not at all, both of which were being actively considered in my notes. i think the arranging of music [in the sense of orchestration] is better left to the Logic / Cubase / Pro-Tools strain of apps - eg MIDI + sequencer, with a notation layer for portable arrangement. glame however has the possibility to be a powerful editor if only it had an better GUI and *some* support for the fundamental need of bumping down tracks. if not, it is stuck as a rarified filter-chainer with entry level editor. glame however has the capacity to satisfy both the pre and post production requirements of projects in MusE and Jazz [for instance]. de| _ / a - b, b -c, a - d, d - c ...and so on...\ _
Re: [linux-audio-dev] what's wrong with glame
(bearing in mind I haven't installed, much less used, GLAME, or anything, yet...) Alexander Ehlert wrote: Yeah, hmm, that's just naming. We could add something called open in the menu which creates a group with the wavfile in it. But, importing it makes sense because we convert everything to float internally to allow for high quality dsp. So you have to import and export it. But that's not really an issue compared to open/close, it's just getting used to it. Ok, I have to admit that the file importing(opening) gui is rather bad. But I wasn't motivated yet to change that. I think this is a semantic misunderstanding. All the ~multi-track~ programs I have had experience of (Cubase, Cool Edit Pro, and most recently, cakewalk SONAR) use the semantic 'Import', for a simple reason - in a multi-track project, you have N tracks, and any soundfile must be 'imported' to one of these (You may indeed need to select a track before 'Import' becomes active). Cool Edit Pro has a nice feature in that if you right-click in a track, the File menu appears with Import, and the file is inserted at the cursor point. In a plain stereo wave-editor, there is by definition only one track, so 'Import' is unnecessary, and 'Open' is more idiomatic. At least in Windows and the Mac, the File-Open command is always understood to relate to the main file associated with the project (the file you might double-click on from Windows Explorer); this would for most users be a Session, Project, name-it-what-you-will. Double-clicking on a soundfile name would be expected to play it using the default player. However, at least under Windows, you can change a file association so that selecting a soundfile opens it in your preferred application (assuming it can accept the file in that way). This merely requires a 'multi-document' capability where the command-line passed to the program can contain the name of either a Project or a SoundFile (or a MIDI file, or...), and either can be opened. SONAR cannot do this (for the above reason - where would it go?), but Cool Edit Pro can, possibly uniquely, because it implements two parallel modes - multi-track project, and single-track editor mode. Interpreting 'Import' as format conversion is, IMO, a typical programmer's tinted spin on how the user thinks, or, rather, doesn't want to have to think. After all, you don't 'Import' a Word document into a word processor because it happens to be converted to Unicode,say, internally. The user, generally, couldn't care less about internal representation. They will only want to know that the highest audio quality is maintained internally (however that's done - 32bit ints? doubles? quads?), and they will sometimes want to 'Save As' a different format, or explicitly do a Format Conversion as some programs require you to do - which even I find a complete pain in the A. Designing User Interfaces is a real challenge, not merely from an implementation point of view (all those debates about libraries!), but literally from a design, i.e. HCI, point of view. Certain procedures become de-facto standard, and a developer takes a great risk in changing this; on the other hand if the change very clearly leads to an increase in intuitiveness and efficiency for the user, they will generally accept it after a moment to re-orient. Nevertheless, there is a simple HCI measure of efficiency for the user, which is to find the number of discrete steps the user must perform to achive any specific operation, and, wherever possible, ensure that the most frequently performed tasks (which may be the most argued-over parameter, of course) require the least number of steps. A sub-menu requires at least four, possibly five steps: Menu--scroll-to-Item--(Click-item--)scroll down submenu--click sub-item. Of course a keyboard shortcut can be used, but you have to know what it is first, and preferably not requring three or four keypresses; so this can conflict with the goal of a shallow learning curve (emacs being the prime culprit/hero here, as was, in days of yore, WordStar). Given the WIMP paradigm, it follows that a design that allows both projects, and soundfiles, to be opened with one mouse-click (!), is the Holy Grail. Good Luck! Richard Dobson -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] User Interface
My reason is that there are so many editors to chose from I can only really be bothered with contributing to 3 of them seriously. Everyone is trying to do almost exactly the same thing so I have looked around and chosen three (arbitrarily) that I like the most. I have given up fighting the fact that I will have to write the same thing over and over again while I'm contributing to Linux audio. So at this stage I have to budget my energy. I just can't see much point in reading and understanding the code for 10 or 20 competing editors when IMO all those resources should be invested in one or two competing editors (maybe three). We just don't have the numbers of people contributing to justify such fractured development. Have the Glamers bothered to install ardour yet? What about sweep? Or audacity? I just spent the past two days getting all the editors I could find and testing them out. All I wanted was to cut some fluff off a medium sized stereo file. The only one I could use is Audacity because it was the only one I could fully install that would actually save a large file (even then it was from cvs). Now I would like to put some Ladspa effects on the file but find if I do it in Audacity then I have to write the code myself. I'm struck by the futility of doing this for yet another sound editor because if i could use glame, sweep, ardour, ecasound, other editor that has LADSPA support, then I wouldn't have to spend my energy on implementing the same code again. I also note that by the time I finish writing said code I'll probably be able to use one of the other apps to do what I want anyway. At the moment we have so many competing ways of doing the same thing but hardly any of it is entirely useful. If we just combined all the ideas into the same editor then we would get a lot more progress. I'm sure we are capable of making it so that the gui can be extended in any way. To put it bluntly. LAD make a mockery of the idea of lazy hackers. Everyone is trying to do the same thing over and over and over and. -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] patch for ll and 2.4.7
Can someone provide details for how to make the patch for the low latency kernel please? you don't *make* a patch unless you're a kernel hacker. you can get Andrew Morton's patch(es) from somewhere under: http://www.uow.edu.au/~andrewm/linux/ you apply it like any other kernel patch: cd /usr/src patch -p0 thispatch then rebuild your kernel. Maybe I should have asked if anyone is going to make the LL patch for 2.4.7? -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] what's wrong with glame
All the ~multi-track~ programs I have had experience of (Cubase, Cool Edit Pro, and most recently, cakewalk SONAR) use the semantic 'Import', for a simple reason - in a multi-track project, you have N tracks, and any soundfile must be 'imported' to one of these (You may indeed need to select a track before 'Import' becomes active). Cool Edit Pro has a nice feature in that if you right-click in a track, the File menu appears with Import, and the file is inserted at the cursor point. Yes, ardour uses right click on track-Menu-Insert-Audio File. this pops up a database of audio files. you click on the one you want, and its inserted at the insertion cursor location for that track. current support is for mono audio files only (since tracks are mono). You could use the same Menu to insert the Selection, Cut Buffer, Region or a few other items. Interpreting 'Import' as format conversion is, IMO, a typical programmer's tinted spin on how the user thinks, or, rather, doesn't want to have to think. After all, you don't 'Import' a Word document into a word processor because it happens to be converted to Unicode,say, internally. yes, thats why I prefer the word insert to import. Of course a keyboard shortcut can be used, but you have to know what it is first, and preferably not requring three or four keypresses; so this can conflict with the goal of a shallow learning curve (emacs being the who said a shallow learning curve was a goal? --p
Re: [linux-audio-dev] User Interface
To put it bluntly. LAD make a mockery of the idea of lazy hackers. Everyone is trying to do the same thing over and over and over and. yeah, just like soundforge and cool edit pro and cakewalk and logic and cubase and samplitude and session and protools and bias peak and digital performer and ... the same thing over and over and over ... Patience. The cream rises to the top. Its just takes time. Also, we're not all trying to do the same thing over and over and over. --p
Re: [linux-audio-dev] User Interface
7/26/2001 23:30:38, Paul Davis [EMAIL PROTECTED] wrote: Why don't I make my libraries available as RPMs or debian packages? Because I have better things to do with my development time than rebuilding, reuploading, re-doing a web page every time I fix a bug in a library. Thats why Ardour is currently a developer only system, and its why I use CVS, because I assume that developers will be happy using CVS because of the ease and low cost of updating it provides. Ya, I hear you there. I totally understand. I still want to try ardour, but I have better things to do than hunt down/install all the libs required. Like keep my OWN applications up to date. the requirements page already did this, and i just updated it to include a couple of new links and to revise the old ones. http://ardour.sourceforge.net/requirements.html or even better, links to any binaries that the dist's. might have available. its proven *extremely* problematic to use binaries of C++ libraries. C++ is much more susceptible than C to compile-time conditions. in addition, the dists have become increasingly incompatible due to compiler/library issues, and furthermore, they include code changes that are not in the original source ball, making it more difficult for me to track bug reports accurately. Tell me about it. It seems if a developer DOES want to provide binaries, you have to have several of the different dist's on your own system. Even different versions of the dists, and compile a binary for each of the distributions.That's one thing I don't like about many of them- they install libraries in different places other than the maintainers tar balls. I have gotten to the point where if/when I install a dist, I forget about installing anything X, or dev from them, and just install from tarballs. I guess thats a unix tradition, having several different incompatible distributions available. I was hoping linux could overcome this, but it isn't happening. ljp
Re: [linux-audio-dev] LAAGA name
On Thu, Jul 26, 2001 at 11:38:12AM -0400, Paul Davis wrote: would it be too dreadfully obnoxious and steinberg sniping to rename LAAGA as FreeWire ? Wll FreeWire sounds much more like a thing for freely wireing together free audio apps in a free way. freewire.org has gone, laaga.org hasn't. There are allready lots of things called FreeWire (bands, isps etc.), Laaga appears to be a Hindu word, but appart from that there the only hits on google are linux audio related. FreeWire may piss off Steinberg, while this may be and end in itsself, look what happend to Killustrator. I'm not too hot on trademark laws, but they definatly frown on that sort of thing. FreeWire sounds vaguely like drugs reference, LAAGA sounds like a Beer reference ;) Pretty 50/50 imho. - Steve
Re: [linux-audio-dev] what's wrong with glame
Actually you can resample with rather good quality. But you have to setup a network for that purpose. Just stream the audio into FFT-FFT_RESAMPLE- IFFT. IMHO the quality is better than sox with polyphase resampling which produces glitches. What exactly is the algorithm? Does it do a good job? How have you tested it? I'm in progress of implementing a resampler, and would like to know if any existing really work. Julius O. Smith has resampler but it may work for 16-bit audio only. SonicFlow has a resampler too, but I don't know details of it. -*- As what comes to various wave editors: it could be better to start turning Glame's wave editor, Sweep and Audacity(?) to a SoundForge clone because SoundForge has a quite good user interface. I understand you have your own ideas of how the editor should look like but as written here, they cannot be used if they are different from standards. When all three are looking like SoundForge, they could be fused together much better. But it really is not necessary. Anyway, when we have a standard looking editor, it is easier to improve it further. It doesn't make sense to improve an editor which is practically unusable. Yes, SoundForge is not perfect either: I have a very hard time to perform such a simple operation than to extract selections of audio from larger files. It is next to impossible (but, of course, it is possible from engineer's perpective; not enough for artist!). However, I have a right tool for the task. ;-) I have a list of problems in SoundForge and would like to share it with you when we have a standard looking editor. Best regards, Juhana
Re: [linux-audio-dev] LAAGA name
On Thu, Jul 26, 2001 at 02:54:49PM -0400, Paul Davis wrote: FreeWire sounds vaguely like drugs reference, LAAGA sounds like a Beer reference ;) Only to wideboys and Cortina Mk.III drivers who holiday on the costa del sol, mate :) You mean its possible to drive a Cortina and not be a wideboy? I think they throw you out of the union for that. All forign beer is just poncy lager anyway ;) Pretty 50/50 imho. Yeah, I'm not terribly hot on it. Somehow though, ReWire, CoreAudio and others just sound, uh, more appealing. But then maybe thats the native english speaker in me dominating too much. The hindu glue connection is very appealing. It is a shame that the name doesn't imply audio-ness or wiring-ness or ..., I've been thinking of alternatives, but they all sound cheesey, stupid, or are even more obscure than Laaga. - Steve
Re: [linux-audio-dev] what's wrong with glame
Richard Dobson said: and, wherever possible, ensure that the most frequently performed tasks (which may be the most argued-over parameter, of course) require the least number of steps. A sub-menu requires at least four, possibly five steps: How difficult would it be to add a statistical analysis function to the program which tracks the most used menu items and organises them into a seperate menu specifically for the most used items? -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
RRe: [linux-audio-dev] LAAGA name
I thought it worked quite well. LADs n their LAAGA. Sounds right manly dunnit! -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] LAAGA name
Ok, throwing out ideas in the air: PatchCable Awire Lwire AudioWire DigiWire DigiPatch Not Another Wire (NAW) :) (Hook your DAW with NAW) AudioConnect LiveConnect I can make more :) Rick On Thu, 26 Jul 2001, Paul Davis wrote: FreeWire sounds vaguely like drugs reference, LAAGA sounds like a Beer reference ;) Only to wideboys and Cortina Mk.III drivers who holiday on the costa del sol, mate :) Pretty 50/50 imho. Yeah, I'm not terribly hot on it. Somehow though, ReWire, CoreAudio and others just sound, uh, more appealing. But then maybe thats the native english speaker in me dominating too much. The hindu glue connection is very appealing. --p ++---+ | T a l i t y | +--+ | ++ ++-+| | | Richard Burnett |+-+| | | Senior Design Engineer +---+ ++ | | [EMAIL PROTECTED] | | | | | | | | Phone: 919.380.3014 | | | Fax: 919.380.3903 | | | ++
Re: [linux-audio-dev] User Interface
Paul Davis said: To put it bluntly. LAD make a mockery of the idea of lazy hackers. Everyone is trying to do the same thing over and over and over and. yeah, just like soundforge and cool edit pro and cakewalk and logic and cubase and samplitude and session and protools and bias peak and digital performer and ... the same thing over and over and over ... Patience. The cream rises to the top. Its just takes time. Also, we're not all trying to do the same thing over and over and over. Yeh but this isn't doze or mac world. The only reason there is such a proliferation of stuff on those other platforms is because they sell it. We don't so why do we have so much competition? AFAIK we are the ones who aren't in it for the money. Not that money is evil or anything or even if it is evil that it is bad or anything. Linux is a community and the people designing the sound editors are not really cooperating on that level at the mo. It feels like that is passing though. I say this because otherwise I would see the names on ladspa on a lot more mailing lists to do with Linux editors but that isn't happening very much, yet. If you're not a part of the solution you're a part of the problem. Tell me I'm preaching to the converted ;-] -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] User Interface
its proven *extremely* problematic to use binaries of C++ libraries. C++ is much more susceptible than C to compile-time conditions. in addition, the dists have become increasingly incompatible due to compiler/library issues, and furthermore, they ... You can link a static version of the C++ lib to your app to get rid of this C++ specific lib prob... _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Re: [linux-audio-dev] what's wrong with glame
Paul Davis wrote: who said a shallow learning curve was a goal? In a word - users! A shallow learning curve exists where, primarily, a user can open an application specified to perform a specific set of tasks (e.g a soundfile editor, a word processor), and does not have to read the manual, in order to start using it. The program is self-documenting - the function names are expressive, toolbar buttons, if used, identify their functions clearly (hence, ToolTips, status-bar explanations). You should not, in most cases, have to use something in order to find out what it does. Where de facto conventions exist for some operations (such as mouse drag to select a region), they are implemented, even if the developer has thought up some wizard-prang new fancy way of dong this that he undestands but the user has no clue about). When a user complained that an audio program I had written didn't allow 'Play' to be controlled with the space bar (all programs do that!), I learned this lesson myself. Error messages are presented in plain English, and do no merely say Error or You can't do that, but offer a reasonable suggestion of what you could do. The program itself guides the user into its more obscure areas. Now I am well aware that Linux/unix inherits and gleefully preserves a aura of obscurantism, with requests (often none too polite!) to RTFM at every turn, but often the FM is incomprehensible unless you already know what it means, and often the FM doesn't exist anyway. Where documentation does exist, it often says things like to un-mitigate the interface manifold bi-furcation, de-synchronize the positronic lambdoma. Fistly, it assumes you know how to do the latter, and secondly, it assumes you know ~why~ you would want to do the former in the first place. I could go on; you get the idea. Failing the shallow learning curve is not a problem confined to Linux, of course, but Linux does rather seem to specialize in it. Someone (I genuinely forget who) recently posted a mesasge to this list saying I don't care about users, except contributing users, where the clear meaning was that by this was meant erudite users who were probably also programmers. I rest my case... Richard Dobson -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] LAAGA name
On Thu, 26 Jul 2001, Paul Davis wrote: Only to wideboys and Cortina Mk.III drivers who holiday on the costa del sol, mate :) I have no idea what the above means. Yeah, I'm not terribly hot on it. Somehow though, ReWire, CoreAudio FreeWire is cute. I bet it would get annoying fast. Also makes it sound like you're playing catch up with ReWire. Or reimplementing it. CoreAudio sounds like a PR tech word. and others just sound, uh, more appealing. But then maybe thats the native english speaker in me dominating too much. The hindu glue connection is very appealing. Let's Also Architect Glue Applications I bet you could come up with a more pronouncible acronym. Taybin
Re: [linux-audio-dev] LAAGA name
hi i want to unsubscribe from the mailing list pls help me -- thanigai mani [EMAIL PROTECTED] - email 1-415-430-2180 x1043 - voicemail/fax Steve Harris [EMAIL PROTECTED] wrote: On Thu, Jul 26, 2001 at 11:38:12AM -0400, Paul Davis wrote: would it be too dreadfully obnoxious and steinberg sniping to rename LAAGA as FreeWire ? Wll FreeWire sounds much more like a thing for freely wireing together free audio apps in a free way. freewire.org has gone, laaga.org hasn't. There are allready lots of things called FreeWire (bands, isps etc.), Laaga appears to be a Hindu word, but appart from that there the only hits on google are linux audio related. FreeWire may piss off Steinberg, while this may be and end in itsself, look what happend to Killustrator. I'm not too hot on trademark laws, but they definatly frown on that sort of thing. FreeWire sounds vaguely like drugs reference, LAAGA sounds like a Beer reference ;) Pretty 50/50 imho. - Steve __ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com
RE: [linux-audio-dev] what's wrong with glame
yes! instead of rigid menus or menus with last N open files etc. there should be a menu re-arranging functionality that changes parts of the menu so that the most often used functions are easy to access. For one-prupose application that's already done, sort of, by designing the menu according the common usage but for more complex apps that can be used in many ways (e.g. start/root menu in window manager) it would be really nice to have the menu changed according to your usage of the menu (since there is no good default). it should be able to remember how many times you use the menu items and have some sort of frgetting mechanism. I was thinking about implementing something like that for fvwm (in debian (almost) all X apps and lot of text mode apps have menu entries in pre-defined category so I was thinking about putting the most often used ones into top level menu... there an interesting user interface used for one of the midi apps, forgot the name, where you can rearrange all the menus, pin the menus or individual buttons to workarea etc... it might be interesting to have something like that in gnome or kde (qt, gtk) or other toolkits... erik -- Time flies like an arrow but fruit flies like a banana... -Original Message- From: Patrick Shirkey [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 26, 2001 12:54 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] what's wrong with glame Richard Dobson said: and, wherever possible, ensure that the most frequently performed tasks (which may be the most argued-over parameter, of course) require the least number of steps. A sub-menu requires at least four, possibly five steps: How difficult would it be to add a statistical analysis function to the program which tracks the most used menu items and organises them into a seperate menu specifically for the most used items? -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] LAAGA name
I think everybody would expect FreeWire to be fully portable to other OSes than linux then. Is it the case? (I'm talking about the API, not the actual implementation...). indeed it is. --p
Re: [linux-audio-dev] User Interface
Yeh but this isn't doze or mac world. The only reason there is such a proliferation of stuff on those other platforms is because they sell it. We don't so why do we have so much competition? AFAIK we are the ones who aren't in it for the money. Not that money is evil or anything or even if it is evil that it is bad or anything. Linux is a community and the people designing the sound editors are not really cooperating on that level at the mo. It feels like that is passing though. As you have seen, even just today, we don't all agree on the right way to do things. Thats true of internals and user interfaces. And because this a free community, we're not wasting (much) time trying to force or convince each other that i'm right, you're wrong. Instead, we each get on with our own approaches to things, and you guys who are not developers get to enjoy and/or despise the results. I mean, sure, I'd love it if Richard, Alex and the other GLAME guys realized how vastly superior Ardour was to GLAME in every way, and immediately gave up their development efforts so they could help me out. Not to mention Werner recognizing the absolute incoherent stupidity of having used Qt, and deciding to merge all of MusE into Ardour via Gtk--. On the other hand, me, stop what I'm doing ? Are you kidding ? :) --p ps. i trust my tongue-firmly-in-cheek tone comes across adequately to non-native-english speakers on the list.
Re: [linux-audio-dev] LAAGA name
Sounds good, certainly more marketable than LAAGA (which reminds me lago which in italian means lake) :-) cheers, Benno. On Thursday 26 July 2001 17:38, you wrote: would it be too dreadfully obnoxious and steinberg sniping to rename LAAGA as FreeWire ?
Re: [linux-audio-dev] User Interface
ljp wrote: At 22:04 7/25/2001 -0400, Paul Davis wrote: Paul Winkler writes: I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. [ ... ] Can't compile it without GNOME. I don't like that. I guess that makes me a luddite. Oh well. i *am* a luddite, and i don't like GNOME-dependent audio software either. To me, music is more important than any library ideologies. I wouldn't give a rats ass if software was made with QBASIC, as long as it compiles fairly easily (snip) But there's a practical side to my objection. Sorry if it didn't come across. If there's an app I'm mildly curious about that, upon downloading, I can't even get through configure because I don't have 100MB of other stuff it wants, I toss it. I don't have time to install a huge desktop environment just to give one app a test drive. If I had GNOME installed, that would be no problem; but I'm on a laptop here and space is tight, and I really don't want to have to make room for it. When I get more drive space this won't be a big issue for me. Where's the ideological problem there? We were *asked* for our complaints with GLAME, *as users* ... that's mine. Why is anyone taking offense? -- ...paul winkler custom calendars printing: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com
Re: [linux-audio-dev] User Interface
Joe Pfeiffer wrote: I think that's a common confusion -- a lot of people seem to confuse running a Gnome application with having to run a Gnome desktop, and it just ain't the same at all. The Gnome libs are under 100 MB, so it's really not that big a deal. Not on current desktop systems ... but on last year's laptop, 100MB can still be a bit of a big deal. I want to make clear that I don't want to give any developers a hard time for using libraries or any tool that makes their lives easier and more productive. More power to you! I was just trying to present my point of view as a user, that currently 100 MB of libs *is* objectionable to me. I expect that in the future this will no longer be the case. So I apologize to the GLAME crew and anyone else I may have inadvertently offended, and I will drop this matter. -- ...paul winkler custom calendars printing: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com
Re: [linux-audio-dev] LAAGA name
FreeWire *is* a nice name ... but it would imply to me, like others of the ilk, that its API follows that of the system alluded to... which it doesn't intend to. Hmm... but I don't drink laaga either ... A lot of the obvious names have already been used by commercial apps... but I'd gravitate towards something that, at least, hinted what it *did*. sort of AudioLink, SoundLink ... or the XPatch posted earlier... ciao, Iain.
Re: [linux-audio-dev] LAAGA name
POSA Paul's Own Sound Architecture now *that* made me laugh ...
Re: [linux-audio-dev] documentation
On Thu, 26 Jul 2001, Richard Dobson wrote: Now I am well aware that Linux/unix inherits and gleefully preserves a aura of obscurantism, with requests (often none too polite!) to RTFM at every turn, but often the FM is incomprehensible unless you already know what it means, and often the FM doesn't exist anyway. Where documentation does exist, it often says things like to un-mitigate the interface manifold bi-furcation, de-synchronize the positronic lambdoma. Fistly, it assumes you know how to do the latter, and secondly, it assumes you know ~why~ you would want to do the former in the first place. Please, could you provide some real examples? Could you provide examples of Linux audio documentation that you found to be unclear? (Please include URLs and passages that were confusing.) You mentioned missing documentation. What needs to be documented? Is there any incomplete documentation that you would like to see completed? Also, could you provide examples of documentation for an audio application that you found helpful? (Any program/any platform, just include a URL where the docs may be freely downloaded.) Did you find *any* good Linux documentation at all? If so, could you include its URL also. BTW: Did you report the problems you had with any documentation to its respective author? The author may not know there is a problem until someone reports it. === Kevin Conder
Re: RRe: [linux-audio-dev] LAAGA name
I agree with others that FreeWire sounds too much like we're copying Rewire. Trying to think of other names... ergh, it's hard. MediaGlue? -- ...paul winkler custom calendars printing: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com
RE: [linux-audio-dev] what's wrong with glame
On Thu, 26 Jul 2001, STEFFL, ERIK *Internet* (SBCSI) wrote: yes! instead of rigid menus or menus with last N open files etc. there should be a menu re-arranging functionality that changes parts of the menu so that the most often used functions are easy to access. For one-prupose I believe that studies have been done with dynamic menus. They found that it was confusing to have the menus rearrange. Humans get used to looking for the same thing in one place, and if the place changes and we have to look for it, it is an annoying slowdown. Taybin
Re: [linux-audio-dev] what's wrong with glame
Inveterate Windows-avoiders may not know this, but Win2k does this for the applications on the Start menu. This can carry a potentially huge number of applications (I've seen examples where the full top-level menu filled two columns); Windows gradually learns what the most-used programs are, and presents a condensed menu with just those visible (there is of course an arrow item to open up the full menu). It's a, um, start - submenus are still submenus, and ~eventually~ the adept user discovers there are ways of rearranging everything. But unless it occurs to you that it might be reconfigurable (and there is no reason it should unless someone, or the program tells you!), you will never think to hunt the facility down. The modern customisable toolbar is another attempt to provide this functionality, but it still represents a chicken and egg situation to the user. So, yes, there is a real ~design~ job to be pursued here - a dynamically reconfigurable menu, that learns from the user, but that still presents a predictable enough structure so that things don't suddenly move to unexpected places. We are perhaps moving towards the era of the intelligent Agent, wher the program answers Howto questions from the user, and reconfigures itself according to the tasks the user most want to perform. Microsoft added a 'Answer Wizard' feature to Word (under the Help menu) where you type in a sentence such as How do I format into two columns?, and it will parse the question and, with luck, take to to a suitable help message. Richard Dobson STEFFL, ERIK *Internet* (SBCSI) wrote: yes! instead of rigid menus or menus with last N open files etc. there should be a menu re-arranging functionality that changes parts of the menu so that the most often used functions are easy to access. For one-prupose application that's already done, sort of, by designing the menu according the common usage but for more complex apps that can be used in many ways (e.g. start/root menu in window manager) it would be really nice to have the menu changed according to your usage of the menu (since there is no good default). it should be able to remember how many times you use the menu items and have some sort of frgetting mechanism. I was thinking about implementing something like that for fvwm (in debian (almost) all X apps and lot of text mode apps have menu entries in pre-defined category so I was thinking about putting the most often used ones into top level menu... there an interesting user interface used for one of the midi apps, forgot the name, where you can rearrange all the menus, pin the menus or individual buttons to workarea etc... it might be interesting to have something like that in gnome or kde (qt, gtk) or other toolkits... erik -- -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] what's wrong with glame
who said a shallow learning curve was a goal? In a word - users! I don't think this is realistic for professional media tools. If it were, there wouldn't be complete course tracks in commercial art school for learning how to use commercial software packages -- Maya, Photoshop, etc. These folks are getting trained to spend 40-60 hours a week in front of monitors, with the goal of being maximally productive. A semester spent learning how to use the tool is a good tradeoff. And in fact, I just noticed that SFSU (San Francisco State University, which specializes in media education here in the Bay Area), teaches courses like this for Pro Tools now too. If I had a spare $1600 lying around, I'd take it to see if it was really worth a Grammy :-). - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] documentation
Fair questions! I wasn't speaking merely about audio applications. I have very few on my Linux machine, at present, as it is a new installation, so I need to get the latest versions of all sorts of things, before making detailed up-to-date comments. I have one example where I would really like to have an answer: having installed Mandrake 7.2 (replacing an old but pleasant Redhat 6), I have the problem that in the terminal (under KDE), different file types are now colour-coded. As it happens, I totally hate this, and want everything to be just black text on a white background, like it used to be. One colour is a horrible bright green that is all but illegible. NOWHERE can I find how to change this. There is a set of 'styles' I can select, including black on white, but this still gives me the colours! GRRR! If the answer is, hack into some obscure config file in some obscure directory, and write or change some obscure command-string, then that will prove my point. Basically, if the utility itself doesn't allow me ~easily~ to change the colours, or point me to a system tool that does, that proves my point. It seems to assume that I will always want colour-coding of some sort. jMax, under Linux, still has no proper documentation, especially for new users; it relies on them already being familiar with the MAX/MSP way of doing things. This is being worked on, but there is quite a way to go yet. Silence (M Gogins algorithmic composition) is in great need of user documentation; what is provided is very much reference-style, for expert users. Without that, you can get as far as launching it, and not have the faintest idea what to do next. Oh, and a configure script that told you what libraries are missing, and where to get them from, in the error message, would be helpful. I tried installing GLAME, but it failed to find Guile, even though the application is on the machine. It is only through lurking on this list that I understand (I assume) that I need to download the ~development~ libraries for it. It's too late at night for more answers, I'll try again late morning... Richard Dobson Kevin Conder wrote: On Thu, 26 Jul 2001, Richard Dobson wrote: Now I am well aware that Linux/unix inherits and gleefully preserves a aura of obscurantism, with requests (often none too polite!) to RTFM at every turn, but often the FM is incomprehensible unless you already know what it means, and often the FM doesn't exist anyway. Where documentation does exist, it often says things like to un-mitigate the interface manifold bi-furcation, de-synchronize the positronic lambdoma. Fistly, it assumes you know how to do the latter, and secondly, it assumes you know ~why~ you would want to do the former in the first place. Please, could you provide some real examples? Could you provide examples of Linux audio documentation that you found to be unclear? (Please include URLs and passages that were confusing.) You mentioned missing documentation. What needs to be documented? Is there any incomplete documentation that you would like to see completed? Also, could you provide examples of documentation for an audio application that you found helpful? (Any program/any platform, just include a URL where the docs may be freely downloaded.) Did you find *any* good Linux documentation at all? If so, could you include its URL also. BTW: Did you report the problems you had with any documentation to its respective author? The author may not know there is a problem until someone reports it. === Kevin Conder -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] LAAGA name
POSA Paul's Own Sound Architecture now *that* made me laugh ... true, but i wonder if taybin has any idea of quite why, since i think i do (given your understanding of the cortina mk.III situation) ...
RE: [linux-audio-dev] what's wrong with glame
The next best alternative is code that statistacally keeps track of how often commands etc are used, then its sent back so people can see what the most frequent operations are and how they distribute between different users. Just an idea, Rick On Thu, 26 Jul 2001, Taybin Rutkin wrote: On Thu, 26 Jul 2001, STEFFL, ERIK *Internet* (SBCSI) wrote: yes! instead of rigid menus or menus with last N open files etc. there should be a menu re-arranging functionality that changes parts of the menu so that the most often used functions are easy to access. For one-prupose I believe that studies have been done with dynamic menus. They found that it was confusing to have the menus rearrange. Humans get used to looking for the same thing in one place, and if the place changes and we have to look for it, it is an annoying slowdown. Taybin ++---+ | T a l i t y | +--+ | ++ ++-+| | | Richard Burnett |+-+| | | Senior Design Engineer +---+ ++ | | [EMAIL PROTECTED] | | | | | | | | Phone: 919.380.3014 | | | Fax: 919.380.3903 | | | ++
Re: [linux-audio-dev] LAAGA name
But it should be recursive, to get that old school unix in-joke flavor. I still quite like the suggestion of API (the Audio Processing Interface), so that we have the API API :) --p
Re: [linux-audio-dev] what's wrong with glame
- Original Message - From: Richard Dobson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 27 July 2001 2:42 Subject: Re: [linux-audio-dev] what's wrong with glame (bearing in mind I haven't installed, much less used, GLAME, or anything, yet...) Alexander Ehlert wrote: Yeah, hmm, that's just naming. We could add something called open in the menu which creates a group with the wavfile in it. But, importing it makes sense because we convert everything to float internally to allow for high quality dsp. So you have to import and export it. But that's not really an issue compared to open/close, it's just getting used to it. Ok, I have to admit that the file importing(opening) gui is rather bad. But I wasn't motivated yet to change that. I think this is a semantic misunderstanding. All the ~multi-track~ programs I have had experience of (Cubase, Cool Edit Pro, and most recently, cakewalk SONAR) use the semantic 'Import', for a simple reason - in a multi-track project, you have N tracks, and any soundfile must be 'imported' to one of these (You may indeed need to select a track before 'Import' becomes active). Cool Edit Pro has a nice feature in that if you right-click in a track, the File menu appears with Import, and the file is inserted at the cursor point. In a plain stereo wave-editor, there is by definition only one track, so 'Import' is unnecessary, and 'Open' is more idiomatic. 'import' is perfect for the multracker, because it means 'adding to the existing session'. however in the the editor it is less appropriate- which is why in all the above applications 'open' to reach audio data for editing. Glame may not need to use 'import' because it is [atm] primarily an editor. Open is also used in the Multitrack window of CEPro to open a 'session' file, the same applies elsewhere. but you're right, it is semantic - though semantic differences also mark intuititve differences - i see this alot when teaching new tools to students. At least in Windows and the Mac, the File-Open command is always understood to relate to the main file associated with the project (the file you might double-click on from Windows Explorer); this would for most users be a Session, Project, name-it-what-you-will. Double-clicking on a soundfile name would be expected to play it using the default player. However, at least under Windows, you can change a file association so that selecting a soundfile opens it in your preferred application (assuming it can accept the file in that way). This merely requires a 'multi-document' capability where the command-line passed to the program can contain the name of either a Project or a SoundFile (or a MIDI file, or...), and either can be opened. SONAR cannot do this (for the above reason - where would it go?), but Cool Edit Pro can, possibly uniquely, because it implements two parallel modes - multi-track project, and single-track editor mode. Interpreting 'Import' as format conversion is, IMO, a typical programmer's tinted spin on how the user thinks, or, rather, doesn't want to have to think. After all, you don't 'Import' a Word document into a word processor because it happens to be converted to Unicode,say, internally. The user, generally, couldn't care less about internal representation. They will only want to know that the highest audio quality is maintained internally (however that's done - 32bit ints? doubles? quads?), and they will sometimes want to 'Save As' a different format, or explicitly do a Format Conversion as some programs require you to do - which even I find a complete pain in the A. Designing User Interfaces is a real challenge, not merely from an implementation point of view (all those debates about libraries!), but literally from a design, i.e. HCI, point of view. Certain procedures become de-facto standard, and a developer takes a great risk in changing this; on the other hand if the change very clearly leads to an increase in intuitiveness and efficiency for the user, they will generally accept it after a moment to re-orient. Nevertheless, there is a simple HCI measure of efficiency for the user, which is to find the number of discrete steps the user must perform to achive any specific operation, and, wherever possible, ensure that the most frequently performed tasks (which may be the most argued-over parameter, of course) require the least number of steps. A sub-menu requires at least four, possibly five steps: Menu--scroll-to-Item--(Click-item--)scroll down submenu--click sub-item. however i would happily substitute a sub menu for a long top-level menu most of the time if my cut /copy /paste /mixdown /apply last filter etc where all there. Of course a keyboard shortcut can be used, but you have to know what it is first, and preferably not requring three or four keypresses; so this can conflict with the goal of a shallow learning curve it takes a pretty
Re: [linux-audio-dev] documentation
I have one example where I would really like to have an answer: having installed Mandrake 7.2 (replacing an old but pleasant Redhat 6), I have the problem that in the terminal (under KDE), different file types are now colour-coded. As it happens, I totally hate this, and want everything to be just black text on a white background, like it used to be. One colour is a horrible bright green that is all but illegible. NOWHERE can I find how to change this. There is a set of 'styles' I can select, including black on white, but this still gives me the colours! GRRR! I had the same issue with the terminal colors under Mandrake 7.2 and after a bit of sleuthing around in /etc, I found a file called DIR_COLORS. Edit that file to change your colors. Dustin Barlow _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
