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
Adam Zygmunt wrote: ] > You should add the contents of `/usr/share/aclocal/libtool.m4' to > `aclocal.m4'. > aclocal: configure.in: 82: macro `AM_PATH_SIGC' not found in library > > and no configure or install-sh file. Running autoconf;automake by > itself makes a configure file, but it's worthless, and still no > install-sh file. Do you have libsigc++ installed? If you have the RPM installed, you also need the sigc++-devel package. reynald
[linux-audio-dev] re: laaga name
I'd suggest LAIC which stands for Linux Audio InterConnection, taken from the Websters dictionary: laic - Of or relating to the laity - All those who are not members of a profession or specialized field Mark -- FREE ANONYMOUS EMAIL! Sign up now. http://www.subdimension.com/freemail
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/li
Re: [linux-audio-dev] Cross application ladspa settings
Hi! On Sun, Jul 29, 2001 at 04:11:22PM +0200, Linium wrote: > Le Sat, 28 Jul 2001, vous avez écrit : > > On Fri, 27 Jul 2001, Taybin Rutkin wrote: > > > > > It's important to also save mulitple plugins. Save the order of a chain. > > > And some programs also support networks where the plugin's aren't > > > necessarily connected in a linear a->b->c manner. Maybe > > > $LADSPA_PATH/networks/? > > > > This might not be practical because this would be so application specific. > > Networks would be more of a session dependent state. But I still like the > > idea of saving settings for cross application use. > > > > Taybin > > Networks could be seen as big plugins. So it would depend how an application > let the user use the existing networks. There could be some applications for > designing them (alike glame) and other where the networks are just seen > like others plugins (multitrack editors). > For a multitrack recorder/editor like Ardour it is may be not that > pertinent to let users designing networks given the fact that there is probably > a lot of routing possibilities to exploit what would be available (mere ladspa > plugins and our hypothetic networks) ? Well, maybe it's better if the applications that support network design themselves export their designed networks as new LADSPA plugins. For instance I could imagine aRts (which with its own plugins supports connecting a graph of plugins and declare it as new (big) plugin transparently) acting not only as LADSPA host but also as LADSPA plugin provider. That way you could use artsbuilder to connect ten LADSPA plugins to a new plugin, and export this to LADSPA again. The good thing about this is that applications (like ardour) would not even need to know about this - for them, the artsbuilder designed LADSPA plugins would look like normal LADSPA plugins. Cu... Stefan -- -* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
[linux-audio-dev] test-ignore
test -- FREE ANONYMOUS EMAIL! Sign up now. http://www.subdimension.com/freemail
[linux-audio-dev] Brahms-1.0
Hi! I think it might be worth mentioning here that Jan has released Brahms-1.0 yesterday. It requires KDE2.2 (or a beta/CVS version). -Forwarded message from Jan Wuerthner <[EMAIL PROTECTED]>- Hi folks, you'll find today's release of the midi-sequencer and editor "brahms-1.0" at: http://brahms.sourceforge.net/download Thank's for visiting! cheers Jan -- Jan Wuerthner --> http://brahms.sourceforge.net -End of forwarded message- Cu... Stefan -- -* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
Re: [linux-audio-dev] Cross application ladspa settings
Le Sat, 28 Jul 2001, vous avez écrit : > On Fri, 27 Jul 2001, Taybin Rutkin wrote: > > > It's important to also save mulitple plugins. Save the order of a chain. > > And some programs also support networks where the plugin's aren't > > necessarily connected in a linear a->b->c manner. Maybe > > $LADSPA_PATH/networks/? > > This might not be practical because this would be so application specific. > Networks would be more of a session dependent state. But I still like the > idea of saving settings for cross application use. > > Taybin Networks could be seen as big plugins. So it would depend how an application let the user use the existing networks. There could be some applications for designing them (alike glame) and other where the networks are just seen like others plugins (multitrack editors). For a multitrack recorder/editor like Ardour it is may be not that pertinent to let users designing networks given the fact that there is probably a lot of routing possibilities to exploit what would be available (mere ladspa plugins and our hypothetic networks) ? I tried to catch the attention about an ergonomic issue which is cross application presets, but it is may be more interesting to go toward this network idea (which would include such a possibility as well) ? Is there some excitement for such a beast ? Linium
Re[2]: [linux-audio-dev] LAAGA name
I like Jack myself, its got a simple direct name. Rick Saturday, July 28, 2001, you wrote: >>How about this one: >>PAUL - Paul's Audio Universal Linker. >>Incorporate's the name of the inventor and is (sort of) recursive. PD> I'm not the inventor. PD> LAAGA represents the accumulation of 2 years of LAD discussions, with PD> strong input from Kai, David Olofson, Benno, Richard Furse, Abramo and PD> many others. PD> It would be immensely inappropriate for me to make any claims to have PD> invented LAAGA, and even more inappropriate for my name to be part its PD> name. PD> I still like "JACK", "API" and "LAAGA". "ALBA" is not bad but I agree PD> that its a bit to close to ALSA for comfortable distinction between PD> the two (should that be necessary). PD> --p
