Re: [linux-audio-dev] User Interface
Alexander Ehlert wrote: Hi, I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. The waveeditor part is really stable now, we can edit files as large as permitted by the harddisk. We have even documentation, when you click on help. OK, the filternetwork editor is prone to crash. So I would be just curious what people dislike most with glame. Is it the user interface, not enough buttons, too many popup menus? Not enough effects? i was introduced to GLAME on linuxtag by its authors, alexander, daniel and richard. i had never checked it out before (who needs another sound editor !) but it has since become part of my standard toolkit. check it out, its a fine piece of software. Glame people suck, always bitching around in this list ,) ? i can say glame people are not half as bad when you meet them personally :-D -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/
Re: [linux-audio-dev] User Interface
In message [EMAIL PROTECTED]you write: 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. no offense intended paul, but you should be the last person on this planet to complain about library dependencies :) its not library dependencies in general that i don't like. its dependencies on unnecessary libraries. richard has pointed out which GNOME libs are used, and they seem quite reasonable. its the GNOME projects fault for making libgnomeui (really just extensions to GTK+) depend on so many other parts of GNOME, and I have heard that in the next GNOME release, this will be fixed. i'm happy to have apps with a million library dependencies if they are useful, but audio apps that require CORBA, imlib, gdk-pixbuf, wierd compression libraries, and a bunch of other stuff - thats my dislike, thats all. --p
Re: [linux-audio-dev] User Interface
The ardour-dev list would really be the right place for this, but
since its been raised here ...
Not on the list because I've never gotten the thing close to
running...
Such conversations dominate the list, most of the time.
First, you need to generate the autoconf scripts and Makefiles, since
these are not stored in CVS:
cd $AD/quasimodo/libs
sh autogen.sh
--
Did this. The problem is that it only creates the configure file for
the root quasimodo/libs directory, not any of the configure files in
any of the subdirectories. This particular configure file checks for
all the other Quasimodo libs first, as well, so the whole procedure
is a little out of order, to say the least.
autogen.sh does this:
#!/bin/sh
dirs=.
here=`pwd`
acdir=`aclocal --print-ac-dir`
for subdir in pbd midi++ audioengine guileconfig gtkmmext ardour quasimodo languages
soundfile
do
if [ -d $subdir ] ; then
if [ ! -f $acdir/${subdir}.m4 ] ; then
acargs=$acargs -I $here/$subdir
fi
dirs=$dirs $subdir
fi
done
if [ $# -gt 0 ] ; then
dirs=.
fi
for d in $dirs
do
cd $d
echo Building autoconf files for $d ...
aclocal $ACLOCAL_FLAGS $acargs autoheader automake --add-missing --foreign
autoconf
cd $here
done
exit 0
can you explain to me how that fails to build configure files for
the subdirectories? it specifically iterates over the subdirectories
and does the necessary stuff for each one. the only instance in which
it would fail is if you already had, for example $acdir/midi++.m4
installed - in those cases, it infers that you already libmidi++ built
and installed and doesn't bother to build the autoconf files for it.
that said, your questions have prompted me to notice an error in
autogen.sh that i will fix ASAP. it doesn't run libtoolize in any of
the subdirs, and that could be a genuine problem. i'm not sure why
neither i nor anyone else has noted this - probably because once the
files were generated from the per-subdirectory autogen.sh scripts, it
was never a problem.
Of course, ideally the user would be able to simply type
sh ./autogen.sh
configure;make;make install
and have the libraries compile and install. Most other programs seem
to work fine this way.
Ardour *the application* does work this way.
But if you can find me an example of a set of *libraries* that are
packaged together and have interdependencies and can be installed like
this, I'd love to see how they do it. I don't know of one, and nobody
in the many discussions about this on ardour-dev has come up with
one. The standard procedure is (1) fetch the most antecedent library
(2) configure make make install (3) repeat for each dependent
library, in the correct order.
Because we're still in the quasimodo/libs
directory, the code for the quasimodo app shouldn't get in the way.
Currently, the user has to poke through the subdirectories (the
ones from the frustratingly broken script) to find the libraries,
Would you prefer that I list the 5 CVS commands to get just the
libraries you need, rather than the single one that gets the entire
set? Previously, people complained why can't I get the libs with one
command?, so I changed the README. You seem to disagree with the
claim there that this single step will make your life easier.
do the configuring, compiling, and installing individually, then
back out and run configure in the main lib directory.
There would be no configure in the main directory at that point.
Anyway, the README says:
--
At this point, you could build the libraries one at a time by hand
(though obviously, you'll run into problems if the required
precursor libraries are not installed yet). But this script will
take care of all that:
#!/bin/sh
for i in pbd midi++ guileconfig gtkmmext audioengine ardour
do
(cd $i
rm -f config.cache
./configure --disable-static --enable-for-ardour --enable-for-gui
make
make install) || exit 1
done
--
Are you telling me that you were not able to infer from that how you
would go about building each necessary library by hand?
Sorry. autogen.sh is broken for me too. In all the lib
subdirectories, I get an error similar to:
You should add the contents of `/usr/share/aclocal/libtool.m4' to
`aclocal.m4'.
This message from autoconf is a mistake on their part. I must add a
note to this effect to the README. It is not a real error at all.
Though it may be related to the missing libtoolize that I mentioned
above.
aclocal:
Re: [linux-audio-dev] User Interface
On Sat, 28 Jul 2001, Paul Davis wrote: The ardour-dev list would really be the right place for this, but since its been raised here ... Not on the list because I've never gotten the thing close to running... [ ... Adam's problems trying to build ardour ] 1. sourceforge CVS page never says which module (ardour) to download Seems obvious, but without it ever being mentioned on the page... I'll fix that. Since there is only 1 module, I tend to assume that those conversant with CVS will identify it and download it. But the docs should be corrected. Granted, this is a minor point, and I never had a problem with it. However, even a user being conversant with CVS doesn't automatically mean that the developer has chosen sensible names for the modules, or that there aren't extra modules floating around (and with the extra libs this program needs, it isn't an unreasonable assumption). 2. Had to download quasimodo from CVS to get libs, directions buried in README I wouldn't mind the extra download time at all if these were duplicated in the ardour CVS. Something that you might not fully grasp is that these libraries, with the exception of libardour, are *not* part of Ardour. They are used by Ardour, and also by 4 public and 2 private applications of my own, as well as one other application by another LAD reader. I had to decide where the CVS repository for them should be and at that time, Ardour did not exist. At one time, Nicola B. hosted them in Italy, but I then moved them Sourceforge. Since moving CVS trees on Sourceforge is a complete PITA, after Ardour started and became my main focus, I left them where they were, and added libardour there as well to be consistent. The only thing you get from ardour CVS is the application (well, applications, since ksi-ardour is there too). I realize that the libraries are used for other projects. That is, after all, the advantage of making them libraries. However, in my opinion, a little redundancy isn't always a bad thing, especially since this program is currently your main focus. I've never worked with Sourceforge, though, so I don't know how much of a PITA moving/copying stuff is. It's just a thought about how ardour might be made easier to compile. 3. script in Quasimodo README for lib compilation needed This is just ugly, IMHO. If you need the script to make the libs, why not put it in the source tree? Making the libs manually wouldn't be too difficult, except that there are some irrelevant directories (for ardour, anyway) in the source tree. If you only downloaded what you were (not) told to download, there would be no irrelevant directories :) Actually, I did just get the quasimodo/libs module as per the README. CVS still copies the whole quasimodo tree, though, so what I called irrelevant directories are in fact empty, but you still need to pick through them to find the library sources. The script in the README does help. The script is not there because I don't use it, and because it becomes completely irrelevant once you've built them :) More seriously, I was never certain that the script was the right approach. Since nobody has suggested a better solution to the how do I build a tree of interdependent libraries in a single step question, I guess I should now go ahead and make the script into a real one. This seems to me to be the easiest way to do this. 4. script in README for lib compilation very broken - no preexisting configure files in the lib directories, and the script doesn't create them. The README says: -- Compiling from CVS -- ... First, you need to generate the autoconf scripts and Makefiles, since these are not stored in CVS: cd $AD/quasimodo/libs sh autogen.sh -- Did this. The problem is that it only creates the configure file for the root quasimodo/libs directory, not any of the configure files in any of the subdirectories. This particular configure file checks for all the other Quasimodo libs first, as well, so the whole procedure is a little out of order, to say the least. Besides, my whole point here is that the script doesn't work, mostly since it looks for the non-existent configure files. In addition to the stuff in the README about autogen.sh and the aclocal directory link (haven't had to mess with for anything else I've ever compiled), which I did read and follow, the README says to run the script to get the libs to compile. So I guess what I'm saying is to either fix the script or the README. Of course, ideally the user would be able to simply type sh ./autogen.sh configure;make;make install and have the libraries compile and install. Most other programs seem to work fine this way. Because we're still in the quasimodo/libs directory, the code for the quasimodo app shouldn't get in the way. Currently,
Re: [linux-audio-dev] User Interface
But then, I'm still using LaTeX 8-) hey tt's cool... : Nick/
Re: [linux-audio-dev] User Interface
* Paul Davis ([EMAIL PROTECTED]) wrote: First, you need to generate the autoconf scripts and Makefiles, since these are not stored in CVS: cd $AD/quasimodo/libs sh autogen.sh -- This is standard CVS practice. configure *NEVER* lives in CVS - its generated by the autoconf tools, and generated files do not belong in CVS. Thats why autogen.sh exists, and this is the standard technique used by all CVS+autoconf packages I have seen. autogen.sh also builds many other files needed by the autoconf/automake tools. Reasonable people differ here. For example, the autoconf authors (http://subversions.gnu.org/cgi-bin/cvsweb/autoconf/). I think it's a better idea to include configure in CVS. Some macros only exist in certain versions of autoconf, and other variables may enter into play that make building it on the fly problematic. Though it makes for lots of big, ugly diffs, you can always be sure that it will get generated correctly if you do it yourself. Joshua -- Joshua Haberman [EMAIL PROTECTED]
Re: [linux-audio-dev] User Interface
Reasonable people differ here. For example, the autoconf authors (http://subversions.gnu.org/cgi-bin/cvsweb/autoconf/). One of the simplest and least-dependent configure.in files you'll find :) I think it's a better idea to include configure in CVS. Some macros only exist in certain versions of autoconf, and other variables may enter into play that make building it on the fly problematic. Thats precisely why I don't think it should be in CVS. If you can't get your system to run the autoconf tools correctly on the configure.in file, the chances are you've got a lot more trouble coming down the line. Better to catch that in the very first instance, rather than leave it till later. libtool in particular can be a source of tremendous pain if not caught correctly at this stage. Furthermore, if a user has local hacks to the autoconf tools so that certain things work correctly on their system, they will never appear in the configure script. --p
Re: [linux-audio-dev] User Interface
ljp wrote: 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. There are people about who would be happy to package things, (eg me, if you are prepared to risk putting anything I packaged on your system 8-) but the fact is ardour needs ALSA beta 6. Current Debian Sid (unstable) release is at beta 4. If I recompile ALSA from source, I'll have to compile very many other debian-packaged alsa-compatible programs as well, possibly patching them, and that's beyond the call of duty. In fact, that's put me off even trying to run Ardour for quite some time now. I've even just bought some hardware (a twin K7 1.2GHz with an RME soundcard amongst other things) to run it on! If it was a higher-level library than ALSA being unstable, then that would be one thing. But with audio apps, it's almost as bad as if libc were to keep changing radically the whole time. One day, ALSA will stabilise, and everybody will be much happier. It is a pretty basic requirement for developing a sound app, that the basic sound API is stable, after all... Nick/ Nick/
Re: [linux-audio-dev] User Interface
On Fri, Jul 27, 2001 at 08:37:18AM +0100, Nick Bailey wrote: (cut) time now. I've even just bought some hardware (a twin K7 1.2GHz with an RME soundcard amongst other things) to run it on! If it was a higher-level library than (cut) Hi, I'm about to buy a new computer too and i was thinking of a dual K7. Which mobo do you use (does it have ata100 working under linux?) and without wanting to be too curious, how much did you have to pay for it ? Kind Regards Vincent
Re: [linux-audio-dev] User Interface
Richard Guenther wrote: Well, people dont stop development on their apps they worked on for one and a half year - this will not happen. Both you and Paul feel the same way on that topic. I don't hold it against you either. I would like to add that I feel it is the ideas that are more important than the individual apps. Each one has different strong points. Things progress so much faster with the sound editors if we combined these ideas. That is where the true value of the Gimp lies. It's not the useful gui design but the fact that the code can be extended in so many ways and is constantly evolving. It also serves as a focal point for a large community of multimedia specialists. Unless I'm mistaken there are three editor projects that have been designed to allow for many kinds of gui toolkits. Some would say skins. This is a very good idea. Seperate the gui from the guts and we have a very portable editing app. The library of useful ideas for each project are reasonably sized but nothing as extensive as the code base for win or mac editors. But if we had combined them all from the start then we would already have a very strong editing suite. How unrealistic is it? Is that posibility just too fantastic? No-one has to stop working on their specialist project unless they want to. What I want to know is why is it so difficult for the people making the editing software to cooperate? It's the ideas that are most important. What does it matter if you run your own medium sized cvs tree or if you contribute to a large universal tree? In fact now that I think about it you would probably get more recognition if you contribute to a large code base. Of course it will probably mean more concessions but then if it is really good you just have to prove it. That is the Linux way. -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Products to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] User Interface
I would like to add that I feel it is the ideas that are more important than the individual apps. Each one has different strong points. Things progress so much faster with the sound editors if we combined these ideas. That is where the true value of the Gimp lies. It's not the useful gui design but the fact that the code can be extended in so many ways and is constantly evolving. It also serves as a focal point for a large community of multimedia specialists. I would point out here that snd has had the same kind of capabilities as the GIMP in the realm of audio for many years now. One might argue even more power, given that it uses Guile for the scripting language. Yet nobody (well, OK, very few people) have jumped into snd and done all kinds of cool extensions and widgets. So before you jump to any conclusions about the value of extensibility, I'd like to hear why snd hasn't become the darling of the audio world, at least on Unix-like systems. I have my own theories, of course :) No-one has to stop working on their specialist project unless they want to. What I want to know is why is it so difficult for the people making the editing software to cooperate? As I said before, its not that we wouldn't cooperate if we agreed on the project's goals. But we don't, and so the kind of tight, intimate cooperation of say, the Apache project, isn't appropriate here. If and when a particular program really gains critical mass (and of course, I'm really hoping it will be ardour, but it could just as easily be GLAME, or Audacity or ecasound or something else), I expect what will happen is that new audio developers will work with that codebase to improve and extend it and include the functionality present in similar programs. gradually, the momentum behind other projects will fade, though perhaps not. At that time, you'll be seeing at lot more Apache-like cooperation. But we're not at that point yet. Someone wants to get to A, someone else wants to get to B. Whats the point of cooperating on two different destinations? --p
Re: [linux-audio-dev] User Interface
The library of useful ideas for each project are reasonably sized but nothing as extensive as the code base for win or mac editors. But if we had combined them all from the start then we would already have a very strong editing suite. How unrealistic is it? Is that posibility just too fantastic? The list of editing operations that one can perform is actually very small. Basically: insert, remove, replace, transform. All other editing operations are just built on these basic blocks. The problem is that it *really* matters what the underlying data representation is. Almost all existing Linux audio editors assume they are working on linear sample streams. At some point, this abstraction has to exist, since thats the form required for playback to the device driver. But the details of how a particular operation is carried out may vary widely depending on the actual internal representation. This means that you can't just take an idea (let alone code) from one project and apply it to another one instantly. In fact, its always a measure for me of how good (or bad) my code is to see how difficult implementing an idea I did not have at the time I wrote it turns out to be. When its easy, I get a nice warm feeling all over. When its difficult, I end up being suspicious about the entire codebase. To give you a specific example: in ardour, when you insert an audio file into a track, the operation you have performed is *nothing* like what happens when you do that in sweep or gnoise or audacity. there is no data copying, the only thing that has changed is a playlist. Now, a playlist is the natural form for audio editing, as we can see in the MacOS/Win world. But a playlist is a much more sophisticated structure than a linear list of samples, and programmers differ greatly in how they want a playlist to be implemented. Some would want such a thing in C, some in C++, some would want it to have certain properties, a specific API etc. Now, if someone produced a library that supported playlist editing in C in a way that could be easily integrated into (1) other languages (2) programs with different goals, there would be chance at cooperation, since we'd stand more chance of working on the same data structures. I'm not a long way from that possibility, but its not one of my current goals, either. --p
Re: [linux-audio-dev] User Interface
On Fri, Jul 27, 2001 at 08:57:01AM -0400, Paul Davis wrote: Now, if someone produced a library that supported playlist editing in C in a way that could be easily integrated into (1) other languages (2) programs with different goals, there would be chance at cooperation, since we'd stand more chance of working on the same data structures. I'm not a long way from that possibility, but its not one of my current goals, either. I was going to say more or less the same thing, it would also mean that it was possible to exchange data between editors (I used to use two on windows, I don't see why I wouldn't want to on Linux) without exporting via wav. The editors of choice on windows were soundforge, vegas and cooledit, each of which had thier benefits, but I wouldn't have wanted them combined into one app, it would have been huge and confusing. Soundforge was great for mono/stereo files, and DX plugins, and vegas was great for multitrack data. - Steve
Re: [linux-audio-dev] User Interface
On Fri, 27 Jul 2001, Paul Davis wrote: I would point out here that snd has had the same kind of capabilities as the GIMP in the realm of audio for many years now. One might argue even more power, given that it uses Guile for the scripting language. Yet nobody (well, OK, very few people) have jumped into snd and done all kinds of cool extensions and widgets. So before you jump to any conclusions about the value of extensibility, I'd like to hear why snd hasn't become the darling of the audio world, at least on Unix-like systems. Humm, before we started GLAME I had a look at the snd codebase (at that time the gtk port was not available) and I quickly came to the point where starting a new project was easier than retrofitting a good backend into snd - its way too much interwinded GUI/backend stuff. 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 Fri, 27 Jul 2001, Patrick Shirkey wrote: Richard Guenther wrote: Well, people dont stop development on their apps they worked on for one and a half year - this will not happen. Both you and Paul feel the same way on that topic. I don't hold it against you either. I would like to add that I feel it is the ideas that are more important than the individual apps. Each one has different strong points. Things progress so much faster with the sound editors if we combined these ideas. I dont think we differ in ideas - its mainly implementation and taste. That is where the true value of the Gimp lies. It's not the useful gui design but the fact that the code can be extended in so many ways and is constantly evolving. It also serves as a focal point for a large community of multimedia specialists. Unless I'm mistaken there are three editor projects that have been designed to allow for many kinds of gui toolkits. Some would say skins. This is a very good idea. Seperate the gui from the guts and we have a very portable editing app. Yes - this was one main focus with glame - have the backend seperated from the GUI. But this now slowly bites us, as f.i. in designing an _interactive_ GUI, like dragging the playing-marker around and have the sound follow it - this is absolutely impossible (err, ok, not really, but then the seperation is no longer) to do with a clean, seperated concept (that didnt think about this usage before). The library of useful ideas for each project are reasonably sized but nothing as extensive as the code base for win or mac editors. But if we had combined them all from the start then we would already have a very strong editing suite. How unrealistic is it? Is that posibility just too fantastic? Its realistic - but you have to think about how much discussion goes on f.i. here on the list about implementation/design issues - I suppose I wont be able to work on the same project as Paul :) For well designed and consistent stuff the Basaar model doesnt really work. No-one has to stop working on their specialist project unless they want to. What I want to know is why is it so difficult for the people making the editing software to cooperate? It's the ideas that are most important. What does it matter if you run your own medium sized cvs tree or if you contribute to a large universal tree? In fact now that I think about it you would probably get more recognition if you contribute to a large code base. Of course it will probably mean more concessions but then if it is really good you just have to prove it. You'll get into big troubles if you dont have one (or say very few) strong and accepted leaders of such a project. And usually all people feel like being one of those :) (me too) 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
Hi, I would like to add that I feel it is the ideas that are more important than the individual apps. Each one has different strong points. Things progress so much faster with the sound editors if we combined these ideas. Yeah thats it and sometimes two different philosophies can't be just married with each other. Mutual exclusive. This is a very good idea. Seperate the gui from the guts and we have a very portable editing app. Thats the point with Glame. It's model view controlled, thats why we need a bit more time to get all the functionality that apps have, where all the editing code is somewhere inlined in the gui. strong editing suite. How unrealistic is it? Is that posibility just too fantastic? Yes. large code base. Of course it will probably mean more concessions but then if it is really good you just have to prove it. It's not just contributing to some code base, someone has to think of software architecture and all the other contributors have to stick with that design. That is the way the linux kernel development goes as well. That is the Linux way. Ah, so why do we have zillions of different shells, editors, desktops then? Anyway this is hobby and people do whatever they like to realize their visions. And as I said before it's not just sticking to programs together and they have double the amount of features :) Cheers, Mag -- If you tell the truth you don't have to remember anything. -- Mark Twain
Re: [linux-audio-dev] User Interface
Richard Guenther wrote: Well, people dont stop development on their apps they worked on for one and a half year - this will not happen. I think it does happen... AFAICT, Boris Nagels disappeared off the 'net sometime after promising to open-source Multitrack, but before actually doing so. You can still get 2.2 from Dave Phillips' website, but it's annoyingly buggy and now it looks like those bugs can never be fixed. -- ...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
- Original Message - From: Paul Davis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 27 July 2001 10:57 Subject: Re: [linux-audio-dev] User Interface jesus man you're hilarious ; ) When its easy, I get a nice warm feeling all over. When its difficult, I end up being suspicious about the entire codebase. de|
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] 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/
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] 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
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] 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] 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] 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] 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] 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] User Interface
On Wed, Jul 25, 2001 at 01:12:29PM +0200, Alexander Ehlert wrote: I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. The waveeditor part is really stable now, we can edit files as large as permitted by the harddisk. We have even documentation, when you click on help. OK, the filternetwork editor is prone to crash. So I would be just curious what people dislike most with glame. Is it the user interface, not enough buttons, too many popup menus? Not enough effects? Glame people suck, always bitching around in this list ,) ? 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 :) Regs, Andy (probably the last person who should complain about user interface design, *cough* alsaplayer *cough*)
Re: [linux-audio-dev] User Interface
mercoledì, 25 luglio 2001 alle 13:12:29, Alexander Ehlert ha scritto: Hi, I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. The waveeditor part is really stable now, we can edit files as large as permitted by the harddisk. We have even documentation, when you click on help. OK, the filternetwork editor is prone to crash. So I would be just curious what people dislike most with glame. Is it the user interface, not enough buttons, too many popup menus? Not enough effects? Glame people suck, always bitching around in this list ,) ? Gimme Feedback :) Mag Hi, I've just grabbed 0.5.2 from the website, and successfully compiled and installed (system is SuSE 7.2). I've already tried in the past to compile, but without luck (I don't remember when), so I gave up. Now I'm very impressed, just have playing with it a bit, not a deep look nor at the manual, but it seems to be a very very good program. this would be one of the best editors for linux (I've tried also snd, sweep, audacity and DAP). I'm not a programmer and I would thank all the people like you that give us (simple users) this kind of powerful applications. Excuse my broken english... Ciao -- ... e-millo '''
Re: [linux-audio-dev] User Interface
On Wed, 25 Jul 2001, Alexander Ehlert wrote: Hi, I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. The waveeditor part is really stable now, we can edit files as large as permitted by the harddisk. We have even documentation, when you click on help. OK, the filternetwork editor is prone to crash. So I would be just curious what people dislike most with glame. Is it the user interface, not enough buttons, too many popup menus? Not enough effects? Glame people suck, always bitching around in this list ,) ? Note that Alexander is talking about the 0.5.2 version announced as unstable rather than the stable version 0.4.2 (while in general the 0.5.2 version has more uncomplete stuff its not generally less stable, the wave editing part should in contrast be more stable than the 0.4 one). Gimme Feedback :) Or better do some colorful dialogs with lots of buttons for Analyze, Resample and Import/Export functionality (which is all implemented in the backend, but probably not too easily reachable by the end user). So - contribute to existing projects, rather than creating new ones... 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
Alexander Ehlert wrote: Hi, I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. The waveeditor part is really stable now, we can edit files as large as permitted by the harddisk. We have even documentation, when you click on help. OK, the filternetwork editor is prone to crash. So I would be just curious what people dislike most with glame. Can't compile it without GNOME. I don't like that. I guess that makes me a luddite. Oh well. -- ...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
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 (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
