From sjenkins at blueyonder.co.uk Sat Apr 1 04:49:20 2006 From: sjenkins at blueyonder.co.uk (Simon Jenkins) Date: Sat Apr 1 04:49:25 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060330203358.GB8210@mobilat> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> <20060330194802.19ed910e.mle+la@mega-nerd.com> <20060330203358.GB8210@mobilat> Message-ID: <1143884960.7889.29.camel@localhost.localdomain> On Thu, 2006-03-30 at 22:33 +0200, torbenh@gmx.de wrote: > i need all features of libsrc (slowly changing samplerate, and resample > factors of 1.00001 or so) Lets assume - unrealistically, but for the convenience of the maths - a sample rate of 50kHz and a buffer size of 1000. Your resample factor of 1.00001 or so means you need to "find" or "lose" a sample about once every 2 seconds, and 99% of your buffers will be precisely the same size going out as they are coming in. Is putting the entire stream through a resampler (especially a "crap" one) the thing to do here? I'm wondering if there might be a better way to gain or lose the occasional sample. erm... Anyone? Simon Jenkins Bristol, UK From stefan at space.twc.de Sat Apr 1 05:30:40 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Sat Apr 1 05:18:11 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060330203358.GB8210@mobilat> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> <20060330194802.19ed910e.mle+la@mega-nerd.com> <20060330203358.GB8210@mobilat> Message-ID: <20060401103040.GA21016@space.twc.de> Hi! On Thu, Mar 30, 2006 at 10:33:58PM +0200, torbenh@gmx.de wrote: > i cant use a 2 times upsampler.... > i want to use an unsynced soundcard with clockdrift as a recording > source. and i really dont want to make any quality compromises. > > i need all features of libsrc (slowly changing samplerate, and resample > factors of 1.00001 or so) Ok, I thought a bit in this case. You probably can get better quality than the libsrc linear interpolation while still being quite a bit faster than libsrc sinc interpolation. First algorithm: upsample by factor 2 (you can use my code as it is), then use linear interpolation. Why this is better than plain linear interpolation? Because low frequency signals can be better approximated by lines than high frequency signals, and after upsampling by factor 2 your signals will tend to be low frequency signals. Second algorithm: perform factor N upsampling (for instance factor 16 upsampling), then use linear interpolation. The quality should become even better. The performance will not suck as badly as "factor 16 upsampling" sounds, because you only need to compute those sample values that you need to do linear interpolation. As performance estimate, I think the first algorithm should outperform libsrc with a factor between 10 and 30, the second algorithm should outperform libsrc with a factor between 3 and 15 (given that both are implemented in an SSE accelerated way, like I did). As for quality, I'd really like to know what quality can be attained by this approach at what speed. Could it even outperform libsrc on both, quality and performance, under some circumstances? Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From mle+la at mega-nerd.com Sat Apr 1 06:11:34 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sat Apr 1 06:11:43 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060401103040.GA21016@space.twc.de> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> <20060330194802.19ed910e.mle+la@mega-nerd.com> <20060330203358.GB8210@mobilat> <20060401103040.GA21016@space.twc.de> Message-ID: <20060401211134.41d8a93e.mle+la@mega-nerd.com> Stefan Westerfeld wrote: > First algorithm: upsample by factor 2 (you can use my code as it is), > then use linear interpolation. Why this is better than plain linear > interpolation? Because low frequency signals can be better approximated > by lines than high frequency signals, and after upsampling by factor 2 > your signals will tend to be low frequency signals. > > Second algorithm: perform factor N upsampling (for instance factor 16 > upsampling), then use linear interpolation. The quality should become > even better. The performance will not suck as badly as "factor 16 > upsampling" sounds, because you only need to compute those sample values > that you need to do linear interpolation. Upsampling followed by linear resampling can be a good approach. Linear resampling can produce high quality results if you can guarantee that the input signal is strictly band limited well below half the sample rate. I even have some rough figures for this on page 11 of this paper which was given at the Audio Miniconf attached to 2005 Linux.conf.au : http://www.mega-nerd.com/tmp/secret_rabbit_code.pdf For the case of upsampling from 44100Hz to 48000Hz, with the source signal consisting of a single sine wave, I got the following SNR values: Sine Freq Signal to Noise ratio 333 Hz 146.0 dB 666 Hz 115.8 dB 1332 Hz 103.8 dB 2664 Hz 49.8 dB 5328 Hz 38.7 dB 10656 Hz 28.4 dB 21312 Hz 19.5 dB However, beware that the upsample followed by linear resampling will only work correctly when the output sample rate is greater than the input sample rate. When this is not the case, extra filtering is needed on the input side which complicates things somewhat. > As for quality, I'd really like to know what quality can be attained by > this approach at what speed. Could it even outperform libsrc on both, > quality and performance, under some circumstances? Linear resampling can outperfrom the best resampler in libsamplerate under some conditions. That still doesn't make linear resampling a good idea unless you can be 100% sure that your data *always* fits the specific conditions where linear resampling performs well. I'll say it again, libsamplerate is a *general purpose* resampler. For any pair of constant input and output sample rates, it has a well specified worst case behaviour of greater than 96 db SNR. On top of that, it *also* handles the case where the ratio between input and output sample rates is not constant. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Unix and C are the ultimate computer viruses." -- Richard P Gabriel From torbenh at gmx.de Sat Apr 1 06:16:33 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sat Apr 1 06:20:47 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <1143884960.7889.29.camel@localhost.localdomain> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> <20060330194802.19ed910e.mle+la@mega-nerd.com> <20060330203358.GB8210@mobilat> <1143884960.7889.29.camel@localhost.localdomain> Message-ID: <20060401111633.GA8049@mobilat> On Sat, Apr 01, 2006 at 10:49:20AM +0100, Simon Jenkins wrote: > On Thu, 2006-03-30 at 22:33 +0200, torbenh@gmx.de wrote: > > > i need all features of libsrc (slowly changing samplerate, and resample > > factors of 1.00001 or so) > > Lets assume - unrealistically, but for the convenience of the > maths - a sample rate of 50kHz and a buffer size of 1000. Your > resample factor of 1.00001 or so means you need to "find" or > "lose" a sample about once every 2 seconds, and 99% of your > buffers will be precisely the same size going out as they are > coming in. > > Is putting the entire stream through a resampler (especially > a "crap" one) the thing to do here? I'm wondering if there > might be a better way to gain or lose the occasional sample. well... there are some soundcards which can only do one samplerate (48k or 44k1 namely) so for this case its real resampling... i have just found that there was a timeout value in the select() in net_driver_wait() resulting in kernel busy waiting... this changed the cpu usage in some unfavourable manner... i am off for some other tests... and going back to SINC_FASTEST now... also for the internet case i am getting quite bursty clocking an currently dont have a way to get timestamps etc from the jack_driver to the client. so while experimenting with this stuff, i am experiencing resampling of 5% or so... i am currently experimenting with the coefficients and function for the delay locked loop controlling the resample factor... > > erm... Anyone? > > Simon Jenkins > Bristol, UK > > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From patrickkidd.lists at gmail.com Sun Apr 2 01:36:28 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Sun Apr 2 01:36:32 2006 Subject: [linux-audio-dev] libsndfile: sf_seek return value Message-ID: <664bf2b80604012236t1fcb3d9ejebcee50772f72075@mail.gmail.com> has anyone seek sf_seek return zero on success instead of the frame offset from the start of the audio data, as it says in the API docs? The seek appears to work because a call to read behaves correctly at the end of the stream afterwards. Thanks. From patrickkidd.lists at gmail.com Sun Apr 2 01:47:32 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Sun Apr 2 01:47:37 2006 Subject: [linux-audio-dev] pysndfile, pyrtaudio, pyrtmidi, pysoundtouch Message-ID: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> I just finished writing python bindings for libsndfile if anyone is interested. I only wrapped the functions I needed to read files, but I could reasily finish the wrapper in a couple of hours if anyone is interested. unit tests are included. That makes the following python extensions available on my site. They all seem to work on OS X and linux: pysndfile pyrtaudio pyrtmidi pysoundtouch (not quite functional) Let me know if anyone has problems or comments, this was quite fun to do, and I'd like to make them complete for the sake of the world... -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From TimBlechmann at gmx.net Sun Apr 2 07:28:41 2006 From: TimBlechmann at gmx.net (Tim Blechmann) Date: Sun Apr 2 07:26:43 2006 Subject: [linux-audio-dev] pysndfile, pyrtaudio, pyrtmidi, pysoundtouch In-Reply-To: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> References: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> Message-ID: <1143977322.24200.1.camel@localhost> On Sat, 2006-04-01 at 21:47 -0900, Patrick Stinson wrote: > I just finished writing python bindings for libsndfile if anyone is > interested. I only wrapped the functions I needed to read files, but I > could reasily finish the wrapper in a couple of hours if anyone is > interested. unit tests are included. i'm curious, what's the advantage of your libsndfile python bindings over libsndfile-python (http://arcsin.org/softwares/libsndfile-python.html)? cheers ... tim -- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk Life is really simple, but we insist on making it complicated. Confucius -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060402/abda4281/attachment.bin From patrickkidd.lists at gmail.com Mon Apr 3 03:15:09 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 3 03:15:25 2006 Subject: [linux-audio-dev] pysndfile, pyrtaudio, pyrtmidi, pysoundtouch In-Reply-To: <1143977322.24200.1.camel@localhost> References: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> <1143977322.24200.1.camel@localhost> Message-ID: <664bf2b80604030015s4c0bf55ax27729b0f1b78c171@mail.gmail.com> oh, not much I suppose. His does look nice. On 4/2/06, Tim Blechmann wrote: > On Sat, 2006-04-01 at 21:47 -0900, Patrick Stinson wrote: > > I just finished writing python bindings for libsndfile if anyone is > > interested. I only wrapped the functions I needed to read files, but I > > could reasily finish the wrapper in a couple of hours if anyone is > > interested. unit tests are included. > > i'm curious, what's the advantage of your libsndfile python bindings > over libsndfile-python > (http://arcsin.org/softwares/libsndfile-python.html)? > > cheers ... tim > > -- > TimBlechmann@gmx.de ICQ: 96771783 > http://www.mokabar.tk > > Life is really simple, but we insist on making it complicated. > Confucius > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD8DBQBEL7VpNDZZF/Yk3sURAsT1AJ46oRynW8Sl8U/XyfD2HUgZlpgDCQCfdDBB > 1DohzLNWEbLUKq65gfaQ1V0= > =TJgx > -----END PGP SIGNATURE----- > > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From patrickkidd.lists at gmail.com Mon Apr 3 03:17:03 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 3 03:17:15 2006 Subject: [linux-audio-dev] pysndfile, pyrtaudio, pyrtmidi, pysoundtouch In-Reply-To: <1143977322.24200.1.camel@localhost> References: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> <1143977322.24200.1.camel@localhost> Message-ID: <664bf2b80604030017x3913f04fwf8bef747f0b06b00@mail.gmail.com> I suppose I got a little antsy. Once you get CPython under your belt you (I?) tend to want to wrap everything in sight. I also became a bit weary of searching for python bindings for this and that, because I see so many extensions that are never completed or maintained... On 4/2/06, Tim Blechmann wrote: > On Sat, 2006-04-01 at 21:47 -0900, Patrick Stinson wrote: > > I just finished writing python bindings for libsndfile if anyone is > > interested. I only wrapped the functions I needed to read files, but I > > could reasily finish the wrapper in a couple of hours if anyone is > > interested. unit tests are included. > > i'm curious, what's the advantage of your libsndfile python bindings > over libsndfile-python > (http://arcsin.org/softwares/libsndfile-python.html)? > > cheers ... tim > > -- > TimBlechmann@gmx.de ICQ: 96771783 > http://www.mokabar.tk > > Life is really simple, but we insist on making it complicated. > Confucius > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD8DBQBEL7VpNDZZF/Yk3sURAsT1AJ46oRynW8Sl8U/XyfD2HUgZlpgDCQCfdDBB > 1DohzLNWEbLUKq65gfaQ1V0= > =TJgx > -----END PGP SIGNATURE----- > > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From loki.davison at gmail.com Mon Apr 3 03:50:57 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Apr 3 03:51:04 2006 Subject: [linux-audio-dev] Re: pysndfile, pyrtaudio, pyrtmidi, pysoundtouch In-Reply-To: <664bf2b80604030017x3913f04fwf8bef747f0b06b00@mail.gmail.com> References: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> <1143977322.24200.1.camel@localhost> <664bf2b80604030017x3913f04fwf8bef747f0b06b00@mail.gmail.com> Message-ID: On 4/3/06, Patrick Stinson wrote: > I suppose I got a little antsy. Once you get CPython under your belt > you (I?) tend to want to wrap everything in sight. I also became a bit > weary of searching for python bindings for this and that, because I > see so many extensions that are never completed or maintained... Well, don't bother wrapping phat, pyphat already works ;-) Great to see python growing though. C and python working together, One true path to happiness. Loki From loki.davison at gmail.com Mon Apr 3 12:27:19 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Apr 3 12:27:30 2006 Subject: [linux-audio-dev] Pyphat 0.1 and phat 0.4 released. Message-ID: G'day All, The first release of phat python bindings, pyphat and an updated phat are now out. 2 new widgets are added, phatknob and phatpad. Phat pad is a 5-d input pad that is xinput enabled. X, y, pressure, tilt x and tilt y can returned when used with an xinput device such as a graphics tablet. Knobs and fansliders know have a log mode and an resize bug in sliderbuttons is fixed. Both can be download at http://phat.berlios.de/ Cheers, Loki From patrickkidd.lists at gmail.com Mon Apr 3 15:16:20 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 3 15:16:35 2006 Subject: [linux-audio-dev] Re: pysndfile, pyrtaudio, pyrtmidi, pysoundtouch In-Reply-To: References: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> <1143977322.24200.1.camel@localhost> <664bf2b80604030017x3913f04fwf8bef747f0b06b00@mail.gmail.com> Message-ID: <664bf2b80604031216s341ef0c4r558ffac151ad0510@mail.gmail.com> Nice Loki. good job on 0.1. I also tend to follow the ideal of encouraging growth in an area by writing code. Now I just wish we had a qt/gtk unification. That's tough because they encourage competition, but it would be nice to not have to translate between the two! On 4/2/06, Loki Davison wrote: > On 4/3/06, Patrick Stinson wrote: > > I suppose I got a little antsy. Once you get CPython under your belt > > you (I?) tend to want to wrap everything in sight. I also became a bit > > weary of searching for python bindings for this and that, because I > > see so many extensions that are never completed or maintained... > > Well, don't bother wrapping phat, pyphat already works ;-) Great to > see python growing though. C and python working together, One true > path to happiness. > > Loki > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From ix at replic.net Mon Apr 3 16:17:22 2006 From: ix at replic.net (carmen) Date: Mon Apr 3 16:17:22 2006 Subject: [linux-audio-dev] Re: pysndfile, pyrtaudio, pyrtmidi, pysoundtouch In-Reply-To: <664bf2b80604031216s341ef0c4r558ffac151ad0510@mail.gmail.com> References: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> <1143977322.24200.1.camel@localhost> <664bf2b80604030017x3913f04fwf8bef747f0b06b00@mail.gmail.com> <664bf2b80604031216s341ef0c4r558ffac151ad0510@mail.gmail.com> Message-ID: <20060403201722.GB2140@replic.net> > encouraging growth in an area by writing code. Now I just wish we had > a qt/gtk unification i dont think wishing one of them will go away is going to work. it seems in tech spaces, there are always 2 player in a given field which benefit from the borrowing/uneupmanship that goes on: google/yahoo, apple/microsoft, amd/intel, gtk/qt, ie/firefox, vhs/beta->dvd+r/dvd-r->hd-dvd/bluray, etc. if you want to start talking about duplicated efforts, tell me why do MHWaveEdit, Audacity, Rezound, Sweep, GnuSound, Snd, Glame, and Waveforge, Wavesurfer, and Xsox all exist? (meanwhile, theres no graphical OSC sequencer available in GTK/QT, and the only nondestructive wave editor ive seen (protux) seems abandoned and doesnt even compile (despite the concept haven proven itself in the win32 world with aps like wavelab's multichannel mode, ableton live, samplitude, pyramix..) anyways, i think people should be encouraged, but gently told that theyre reinventing a wheel when theres a warehouse of them sitting by. > but it would be nice to not have to translate between the two! what do you mean? youre constantly porting stuff back and forth between gtk and qt to satisfy some sick craving? :) From patrickkidd.lists at gmail.com Mon Apr 3 16:49:45 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 3 16:49:52 2006 Subject: [linux-audio-dev] Re: pysndfile, pyrtaudio, pyrtmidi, pysoundtouch In-Reply-To: <20060403201722.GB2140@replic.net> References: <664bf2b80604012247m5b2c093bp6fdc73b6f646b6f8@mail.gmail.com> <1143977322.24200.1.camel@localhost> <664bf2b80604030017x3913f04fwf8bef747f0b06b00@mail.gmail.com> <664bf2b80604031216s341ef0c4r558ffac151ad0510@mail.gmail.com> <20060403201722.GB2140@replic.net> Message-ID: <664bf2b80604031349p34acd2d9h30439b2665b13d03@mail.gmail.com> On 4/3/06, carmen wrote: > > encouraging growth in an area by writing code. Now I just wish we had > > a qt/gtk unification > > i dont think wishing one of them will go away is going to work. it seems in tech spaces, there are always 2 player in a given field which benefit from the borrowing/uneupmanship that goes on: google/yahoo, apple/microsoft, amd/intel, gtk/qt, ie/firefox, vhs/beta->dvd+r/dvd-r->hd-dvd/bluray, etc. if you want to start talking about duplicated efforts, tell me why do MHWaveEdit, Audacity, Rezound, Sweep, GnuSound, Snd, Glame, and Waveforge, Wavesurfer, and Xsox all exist? (meanwhile, theres no graphical OSC sequencer available in GTK/QT, and the only nondestructive wave editor ive seen (protux) seems abandoned and doesnt even compile (despite the concept haven proven itself in the win32 world with aps like wavelab's multichannel mode, ableton live, samplitude, pyramix..) anyways, i think people should be encouraged, but gently told that theyre reinventing a wheel when theres a warehouse of them sitting by. I'm with you there. > > > but it would be nice to not have to translate between the two! > > what do you mean? youre constantly porting stuff back and forth between gtk and I've ported some widgets, yes, but this was more light commentary. qt to satisfy some sick craving? :) > You may be getting somewhere with that... -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From patrickkidd.lists at gmail.com Mon Apr 3 16:51:31 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 3 16:52:54 2006 Subject: [linux-audio-dev] python: thread cpu usage Message-ID: <664bf2b80604031351m89b5cf0mb8e41ee9ce7383b9@mail.gmail.com> Does anyone know how to get the cpu usage of a specific thread from python? (I don't subscribe to python-list, too much traffic) From rlrevell at joe-job.com Mon Apr 3 17:16:47 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Apr 3 17:16:56 2006 Subject: [linux-audio-dev] python: thread cpu usage In-Reply-To: <664bf2b80604031351m89b5cf0mb8e41ee9ce7383b9@mail.gmail.com> References: <664bf2b80604031351m89b5cf0mb8e41ee9ce7383b9@mail.gmail.com> Message-ID: <1144099009.17713.83.camel@mindpipe> On Mon, 2006-04-03 at 12:51 -0800, Patrick Stinson wrote: > Does anyone know how to get the cpu usage of a specific thread from > python? (I don't subscribe to python-list, too much traffic) > $ man ps | grep -A4 thread | head -4 Reformatting ps(1), please wait... To get info about threads: ps -eLf ps axms From smithbone at gmail.com Mon Apr 3 22:33:03 2006 From: smithbone at gmail.com (Richard Smith) Date: Mon Apr 3 22:33:11 2006 Subject: [linux-audio-dev] GPL Audio Hardware Message-ID: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> The following post came across the the Open graphics list from one of the founders of the project looking for other things to do with the technology they have developed. I thought I'd post it here. Anyone interested should contact Tim. For anyone who dosen't know what OGD1 is see: http://kerneltrap.org/node/6262 I would think that with a little guidence from this list and tight integration with ardour and jack that a _really_ kicking pro audio setup could be produced. ============= From: Timothy Miller To: ogml Since we're having a bit of a lull in the discussions on OGML, I thought I might start off a discussion about some ideas I've had that would benefit the Linux community as well as give OGP and Traversal a boost financially. The Open Graphics Project has gotten everyone involved a lot of attention. While it's still possible to get graphics cards supported by open source drivers, that supply is dwinding. At the rate things are going, we'll soon have no choices left. Politically and socially, the OGP is a great idea. Economically, however, it's entirely a different story. Because of the development and costs involved, low-end graphics is actually not such a great place to start. The attention we get because we want to do graphics is a major driving force, but there are much better ways to get our stream of funds started. One such idea that's been brought up before is ultra high end audio. The low-end is solved; it's called AC97 and is found in every PC chipset you can buy today. But imagine taking what would normally cost tens to hundreds of thousands of dollars in audio recording and production equipment and applying the open source model to it. Designing and producing a low-end commodity product is hard. But designing a niche audio product that sold competitively for thousands of dollars is relatively easy to pull off. To begin with, we now become much less cost-sensitive for parts, so the end product can be FPGA-based. That makes OGD1 an ideal development platform for a new audio device; in fact, it's major overkill. Once the new design is finished, we'd mass-produce a new board using a smaller FPGA and include all of the audio I/O hardware directly on-board. I know basically nothing about audio technology. But given what little I do know, here are some things that I think would be relatively easy to do with OGD1 and, what shall we call it, OAC1: - 60+ audio channels (pick your combination of in and out) - (A specialized card could handle lots more channels) - 24-bit precision per channel - Sample rates in the hundreds of kilohertz - Thousands of audio samples and MIDI instruments - Sample-based and algorithmically-generated sound-effects - Fourier analysis, band filters, mixing, and other sorts of math stuff that if I could name it, you'd be impressed - Noise-free signals (because we have experience with graphics) - Accelerated "3D sound" - Accelerated compression/decompression - Lots of other things Given hardware acceleration for most parts of audio processing, plus some excellent piece of open source sound studio software, I don't see why we couldn't produce a combination that is as good as or better than what you find in music recording studios, television stations, and every other place where you might find a need for this. Imagine how much money this could save musicians. The only thing we can't provide is the recording room with the proper accoustics. If a reduced version of the card sold for $1000, we'd have more than a few gamers and multimedia enthusiasts buying it for their 50-speaker surround-sound reality-immersion systems. Were such a project started, I would have to carefully tune my involvement. Since Howard, Andy, and I do not have a background in audio technology, it would probably be best for someone with appropriate experience to lead. But if the community can spec this product and help us design it (we can put into hardware any algorithm you specify), Traversal can produce it. The whole project, from start to finish, would be developed under GPL. This would be quite a major effort, due to the requirement for more than just drivers. Unlike the OGP, which started out of a corporation and has retained some of that flavor, the OAP would have to organize itself and push itself along. In my mind, the first major problem is getting the right people in the community together to develop the specs. So, what do you all think of this idea? Comments? Suggestions? Discussion! :) ================== -- Richard A. Smith From rlrevell at joe-job.com Mon Apr 3 22:58:35 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Apr 3 22:58:45 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> Message-ID: <1144119518.22082.13.camel@mindpipe> On Mon, 2006-04-03 at 21:33 -0500, Richard Smith wrote: > The following post came across the the Open graphics list from one of > the founders of the project looking for other things to do with the > technology they have developed. Heh... I suggested this on LKML before even the open graphics project started and no one bit. This is good news! I strongly suggest they implement a device with a programmable firmware... Obviously the first step is to look at what RME, M-Audio, Echo, and other companies are doing and ask themselves how they can improve on it. Lee From rlrevell at joe-job.com Mon Apr 3 22:59:28 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Apr 3 23:00:15 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> Message-ID: <1144119571.22082.15.camel@mindpipe> On Mon, 2006-04-03 at 21:33 -0500, Richard Smith wrote: > Economically, however, it's entirely a > different story. Because of the development and costs involved, > low-end graphics is actually not such a great place to start. The > attention we get because we want to do graphics is a major driving > force, but there are much better ways to get our stream of funds > started. Are they saying the open graphics project is dead - that they won't be releasing any hardware? Lee From paul at linuxaudiosystems.com Mon Apr 3 23:16:05 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Apr 3 23:12:28 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: <1144119518.22082.13.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144119518.22082.13.camel@mindpipe> Message-ID: <1144120565.14746.4.camel@localhost.localdomain> On Mon, 2006-04-03 at 22:58 -0400, Lee Revell wrote: > On Mon, 2006-04-03 at 21:33 -0500, Richard Smith wrote: > > The following post came across the the Open graphics list from one of > > the founders of the project looking for other things to do with the > > technology they have developed. > > Heh... I suggested this on LKML before even the open graphics project > started and no one bit. This is good news! I strongly suggest they > implement a device with a programmable firmware... > > Obviously the first step is to look at what RME, M-Audio, Echo, and > other companies are doing and ask themselves how they can improve on it. the next step is to get a grip on reality. the capabilities they are describing do not cost "tens of thousands of dollars". they cost on the order of US$300-1500. i don't doubt that there are improvements that could be made to existing h/w and f/w, but its not orders of magnitude measured in either cost or functionality. --p From loki.davison at gmail.com Mon Apr 3 23:22:20 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Apr 3 23:22:30 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> Message-ID: > I know basically nothing about audio technology. But given what > little I do know, here are some things that I think would be > relatively easy to do with OGD1 and, what shall we call it, OAC1: > - 60+ audio channels (pick your combination of in and out) > - (A specialized card could handle lots more channels) > - 24-bit precision per channel > - Sample rates in the hundreds of kilohertz > - Thousands of audio samples and MIDI instruments > - Sample-based and algorithmically-generated sound-effects > - Fourier analysis, band filters, mixing, and other sorts of math > stuff that if I could name it, you'd be impressed > - Noise-free signals (because we have experience with graphics) > - Accelerated "3D sound" > - Accelerated compression/decompression > - Lots of other things This collection sounds very consumer great. Thousands of audio samples and MIDI instruments? wtf? Sample-based and algorithmically-generated sound-effects? Accelerated "3D sound"? Accelerated compression/decompression? I have a big freaking cpu for that stuff. Sounds very soundblaster esq. Apart from the 60+ channels which sounds like a really, really big rack mounting. If that is on xlr plugs or 1/4" it's huge. Also no discussion about non-soundbasteresq stuff like balanced in/out, decent pre's, hi-z inputs, dat optical in/out, master clock and clock source, etc. I think looking at the echo layla or maudio 1010 is somewhat more useful to most of us than 60 channels. Loki From dsbaikov at gmail.com Tue Apr 4 03:22:18 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Tue Apr 4 03:22:31 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> Message-ID: <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> LAD guys, You are right in your comments, but please, take it easier. Richard and OGP company have no illusions about them being audio professionals. And yes, it's more useful to look at RME, Echo, M-Audio, but keep it cool, please ;) Thank you. Best regards, Dmitry. From smithbone at gmail.com Tue Apr 4 05:25:47 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue Apr 4 05:25:54 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> Message-ID: <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> On 4/4/06, Dmitry Baikov wrote: > You are right in your comments, but please, take it easier. > > Richard and OGP company have no illusions about them being audio professionals. > And yes, it's more useful to look at RME, Echo, M-Audio, but keep it > cool, please ;) Its ok. I was prepared for the responses. I think the candid opinions have value, keep em comming. I'll point Tim at the RME, Echo, and M-Audio to look at as examples. Basically OGD1 is a big FPGA board with 256Mb of DDR RAM and some nice clean high speed analog and digital ouputs. The question Tim is asking (audio cluelessness aside) are: Can the audio community use such a board? Will they help in producing the feature set and design? What features would it need? What would they pay for it? -- Richard A. Smith From smithbone at gmail.com Tue Apr 4 05:29:47 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue Apr 4 05:29:54 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: <1144119571.22082.15.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144119571.22082.15.camel@mindpipe> Message-ID: <8a0c36780604040229m609cfae1j7f8044e3f3f3ad2a@mail.gmail.com> On 4/3/06, Lee Revell wrote: > On Mon, 2006-04-03 at 21:33 -0500, Richard Smith wrote: > > Economically, however, it's entirely a > > different story. Because of the development and costs involved, > > low-end graphics is actually not such a great place to start. The > > attention we get because we want to do graphics is a major driving > > force, but there are much better ways to get our stream of funds > > started. > > Are they saying the open graphics project is dead - that they won't be > releasing any hardware? No the OGP is still alive and moving. Just slowly. To build the ASIC they need about $2M and Tim is trying to explore every avenue that he can find for selling the OGD1 board to raise the cash (and investors) to make that goal. -- Richard A. Smith From jayv at synth.net Tue Apr 4 05:41:45 2006 From: jayv at synth.net (Jay Vaughan) Date: Tue Apr 4 05:42:10 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: <8a0c36780604040229m609cfae1j7f8044e3f3f3ad2a@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144119571.22082.15.camel@mindpipe> <8a0c36780604040229m609cfae1j7f8044e3f3f3ad2a@mail.gmail.com> Message-ID: in the meantime, hardware that is audio capable, and cheap, and Open Source-friendly is plentiful.. put this: http://gbax.com/ together with this: http://www.gp32x.com/board/index.php?showtopic=27289&hl= and you have cheap audio hardware with plenty of capabilities to support the open source ideal. there is no need to invest $2million in hardware that is affordable and powerful for audio-related use. there are plenty of far, far cheaper solutions to this problem that can still result in amazing, consumer-friendly, sound production .. me, personally, i can't stand the idea of someone making a PCI card for a PC to do audio. for crying out load, its absolutely no fun watching people make music on such a boat anchor! where are the cell-phone synths?! -- ; Jay Vaughan From james at dis-dot-dat.net Tue Apr 4 05:48:14 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Tue Apr 4 05:48:16 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> Message-ID: <20060404094814.GB857@phlunky.Belkin> On Tue, 04 Apr, 2006 at 04:25AM -0500, Richard Smith spake thus: > On 4/4/06, Dmitry Baikov wrote: > > > You are right in your comments, but please, take it easier. > > > > Richard and OGP company have no illusions about them being audio professionals. > > And yes, it's more useful to look at RME, Echo, M-Audio, but keep it > > cool, please ;) > > Its ok. I was prepared for the responses. I think the candid > opinions have value, keep em comming. I'll point Tim at the RME, > Echo, and M-Audio to look at as examples. > > Basically OGD1 is a big FPGA board with 256Mb of DDR RAM and some nice > clean high speed analog and digital ouputs. The question Tim is > asking (audio cluelessness aside) are: My personal views: > Can the audio community use such a board? I'd love to see something like this, but at a reasonable cost. I have a grant application in at the moment to work on something related... > Will they help in producing the feature set and design? Of course. We like talking. > What features would it need? Off the top of my head: 1. Samprerate conversion - fastfastfast! 2. Allocatable memory. It would be nice to be able to allocate memory on the card as long as it came with some benefits: i. Fast access ii. Playing straight from card-ram to outputs ii. Others... 3. Convolution. And/or frequency domain filtering. 4. Audio-specific instructions sound good, but I don't know exactly what they would be, yet. Start with a point operation, so we can do things like gain adjustments fast and maybe wave shaping? 5. Something like shader for audio? Am I dreaming? 6. JACK in hardware? With the features above, this could be very nice. > What would they pay for it? As little as possible. I personally might manage 300 quid (600 dollars-ish). And we'd love you, of course. Physically, if it's as good as I hope ;) For me, if this cost $1000 upwards, it would just be another piece of hardware to dream about owning. James -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power) From fons.adriaensen at alcatelaleniaspace.com Tue Apr 4 06:27:25 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Tue Apr 4 06:27:38 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> Message-ID: <20060404102725.GA3586@bth05w.ABSp.alcatel.be> On Tue, Apr 04, 2006 at 04:25:47AM -0500, Richard Smith wrote: > Can the audio community use such a board? Probably yes :-) > Will they help in producing the feature set and design? Probably yes. I would as far as I can. > What features would it need? For me: * operate at 48 and 96 kHz. * 8 / 16 / 24 analog inputs (line level, balanced) * 8 / 16 / 24 analog outputs (line level) * top quality converters and analog circuits * fixed and calibrated audio levels * support for RMS and peak metering * XLR or stereo jack connectors * no on-board processing, mixing, etc required * optional ADAT interfaces * optional AES/EBU interfaces > What would they pay for it? Whatever I'd pay for commercial hardware of the same performance and quality. HW required - bus interface (PLX) - FPGA - some memory - codecs - analog cirquits Nothing fancy really. -- FA Follie! Follie! Delirio vano e' questo! From dsbaikov at gmail.com Tue Apr 4 06:35:46 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Tue Apr 4 06:35:51 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404102725.GA3586@bth05w.ABSp.alcatel.be> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404102725.GA3586@bth05w.ABSp.alcatel.be> Message-ID: <70a871c80604040335g114da64fy6b36bad6c7b012e0@mail.gmail.com> It will be cool to have something like RME Multiface with ExpressCard/34 option. Dmitry. From fbar at footils.org Tue Apr 4 07:22:48 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue Apr 4 07:22:33 2006 Subject: GPX32 [was: Re: [linux-audio-dev] GPL Audio Hardware] In-Reply-To: References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144119571.22082.15.camel@mindpipe> <8a0c36780604040229m609cfae1j7f8044e3f3f3ad2a@mail.gmail.com> Message-ID: <20060404112248.GC28093@fliwatut.scifi> Hallo, Jay Vaughan hat gesagt: // Jay Vaughan wrote: > in the meantime, hardware that is audio capable, and cheap, and Open > Source-friendly is plentiful.. > > put this: > > http://gbax.com/ > > together with this: > > http://www.gp32x.com/board/index.php?showtopic=27289&hl= > > and you have cheap audio hardware with plenty of capabilities to > support the open source ideal. The GPXi32 indeed is funky, however to my knowledge it misses recording capabilities. It could make a great mobile recorder, but without audio-in it is useless. Shouldn't it be possible to build such a USB breakout box with recording capabilities? Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From jayv at synth.net Tue Apr 4 07:27:29 2006 From: jayv at synth.net (Jay Vaughan) Date: Tue Apr 4 07:27:42 2006 Subject: GPX32 [was: Re: [linux-audio-dev] GPL Audio Hardware] In-Reply-To: <20060404112248.GC28093@fliwatut.scifi> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144119571.22082.15.camel@mindpipe> <8a0c36780604040229m609cfae1j7f8044e3f3f3ad2a@mail.gmail.com> <20060404112248.GC28093@fliwatut.scifi> Message-ID: >The GPXi32 indeed is funky, however to my knowledge it misses >recording capabilities. It could make a great mobile recorder, but >without audio-in it is useless. Shouldn't it be possible to build such >a USB breakout box with recording capabilities? sure. its also possible to plug in a USB microphone, or any kind of USB input device, and use it to record.. -- ; Jay Vaughan From rlrevell at joe-job.com Tue Apr 4 09:49:42 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 4 09:49:55 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144119571.22082.15.camel@mindpipe> <8a0c36780604040229m609cfae1j7f8044e3f3f3ad2a@mail.gmail.com> Message-ID: <1144158584.22082.35.camel@mindpipe> On Tue, 2006-04-04 at 11:41 +0200, Jay Vaughan wrote: > where are the > cell-phone synths?! This made me throw up in my mouth a little. Lee From jens.andreasen at chello.se Tue Apr 4 11:53:17 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Tue Apr 4 11:53:31 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: <1144158584.22082.35.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144119571.22082.15.camel@mindpipe> <8a0c36780604040229m609cfae1j7f8044e3f3f3ad2a@mail.gmail.com> <1144158584.22082.35.camel@mindpipe> Message-ID: <1144165997.9165.2.camel@c80-216-124-251.cm-upc.chello.se> On Tue, 2006-04-04 at 09:49 -0400, Lee Revell wrote: > On Tue, 2006-04-04 at 11:41 +0200, Jay Vaughan wrote: > > where are the > > cell-phone synths?! > > This made me throw up in my mouth a little. > > Lee > [Make way for Lee now ...] CME professional will release U-Key - the first mobiltone keyboard of the world during winter NAMM 2006. It will fill the gap of the particular hardware for composing cell phone ring, which has the market of billions of dollar. U-Key uses ultra thin full action semi-weighted keys and the total ply of U-Key is only 3.7cm, but the key feel of U-Key is as same as keyboards in standard ply. U-Key has build in high 64-polyphony high quality mobile phone sound module ... ... -- From j4strngs at bitless.net Tue Apr 4 13:54:39 2006 From: j4strngs at bitless.net (John Check) Date: Tue Apr 4 13:54:43 2006 Subject: [linux-audio-dev] GPL Audio Hardware In-Reply-To: <1144158584.22082.35.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144158584.22082.35.camel@mindpipe> Message-ID: <200604041354.39543.j4strngs@bitless.net> On Tuesday 04 April 2006 09:49 am, Lee Revell wrote: > On Tue, 2006-04-04 at 11:41 +0200, Jay Vaughan wrote: > > where are the > > cell-phone synths?! > > This made me throw up in my mouth a little. > > Lee Better than my shoes ;) From j4strngs at bitless.net Tue Apr 4 13:57:04 2006 From: j4strngs at bitless.net (John Check) Date: Tue Apr 4 13:57:30 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404102725.GA3586@bth05w.ABSp.alcatel.be> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404102725.GA3586@bth05w.ABSp.alcatel.be> Message-ID: <200604041357.04699.j4strngs@bitless.net> On Tuesday 04 April 2006 06:27 am, Alfons Adriaensen wrote: > > > What would they pay for it? > > Whatever I'd pay for commercial hardware of the same > performance and quality. > > "Not any different, just better" > HW required > > - bus interface (PLX) > - FPGA > - some memory > - codecs > - analog cirquits > > Nothing fancy really. From torbenh at gmx.de Tue Apr 4 14:17:21 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Apr 4 14:21:33 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> Message-ID: <20060404181721.GB8102@mobilat> On Tue, Apr 04, 2006 at 04:25:47AM -0500, Richard Smith wrote: > On 4/4/06, Dmitry Baikov wrote: > > > You are right in your comments, but please, take it easier. > > > > Richard and OGP company have no illusions about them being audio professionals. > > And yes, it's more useful to look at RME, Echo, M-Audio, but keep it > > cool, please ;) > > Its ok. I was prepared for the responses. I think the candid > opinions have value, keep em comming. I'll point Tim at the RME, > Echo, and M-Audio to look at as examples. > > Basically OGD1 is a big FPGA board with 256Mb of DDR RAM and some nice > clean high speed analog and digital ouputs. The question Tim is > asking (audio cluelessness aside) are: how expensive is a firewire port ? firewire stuff is THE niche to fill. most newer firewire devices are not supported if if i understand correctly. ahh... and this magic "getting the audio clock from jack" stuff would be really nice. > > Can the audio community use such a board? > Will they help in producing the feature set and design? > What features would it need? > What would they pay for it? > > -- > Richard A. Smith -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From ix at replic.net Tue Apr 4 14:41:19 2006 From: ix at replic.net (carmen) Date: Tue Apr 4 14:41:23 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404181721.GB8102@mobilat> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> Message-ID: <20060404184119.GA15294@replic.net> > how expensive is a firewire port ? > firewire stuff is THE niche to fill. > most newer firewire devices are not supported if if i understand > correctly. yeah this would be where my interest is as well. somehow i dont believe the 2 million figure (maybe designing a video card from scratch, and printing it up) . i mean can't you just go to whatever factory in Shenzen is churning out crap for Behringer and have them slap a GNU label on it and ship it with schematics and open source drivers? From rlrevell at joe-job.com Tue Apr 4 14:59:53 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 4 15:00:02 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404184119.GA15294@replic.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> <20060404184119.GA15294@replic.net> Message-ID: <1144177194.2887.7.camel@mindpipe> On Tue, 2006-04-04 at 18:41 +0000, carmen wrote: > > how expensive is a firewire port ? > > firewire stuff is THE niche to fill. > > most newer firewire devices are not supported if if i understand > > correctly. > > yeah this would be where my interest is as well. somehow i dont believe the 2 million figure (maybe designing a video card from scratch, and printing it up) . i mean can't you just go to whatever factory in Shenzen is churning out crap for Behringer and have them slap a GNU label on it and ship it with schematics and open source drivers? > I think it's probably the old story, of "it will cost you $2 million to fab your first board, after that it's 25 cents each" ;-) Lee From rlrevell at joe-job.com Tue Apr 4 15:00:54 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 4 15:01:44 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404181721.GB8102@mobilat> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> Message-ID: <1144177255.2887.9.camel@mindpipe> On Tue, 2006-04-04 at 20:17 +0200, torbenh@gmx.de wrote: > how expensive is a firewire port ? > firewire stuff is THE niche to fill. > most newer firewire devices are not supported if if i understand > correctly. What is the status of Linux drivers for this DICE firmware that Paul mentioned a few times? I can't find a single reference to it by Googling. Lee From rlrevell at joe-job.com Tue Apr 4 15:10:36 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 4 15:10:44 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404102725.GA3586@bth05w.ABSp.alcatel.be> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404102725.GA3586@bth05w.ABSp.alcatel.be> Message-ID: <1144177837.2887.15.camel@mindpipe> On Tue, 2006-04-04 at 12:27 +0200, Alfons Adriaensen wrote: > For me: > > * operate at 48 and 96 kHz. Many users also demand 44.1 support, although I don't quite understand why. Lee From dsbaikov at gmail.com Tue Apr 4 15:40:02 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Tue Apr 4 15:40:11 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404181721.GB8102@mobilat> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> Message-ID: <70a871c80604041240x5ec8ff5dv5eef353638d82290@mail.gmail.com> On 4/4/06, torbenh@gmx.de wrote: > how expensive is a firewire port ? > firewire stuff is THE niche to fill. > most newer firewire devices are not supported if if i understand > correctly. It's is THE niche if it can provide 1-3ms roundtrip latencies. For now (under linux at least) PCI/PCMCIA is unbeatable. If I remember correctly, Motu 828 II (fw) under Mac OS X gives ~280 samples in audio loop. It's good, but on the edge of usability for realtime processing. From smithbone at gmail.com Tue Apr 4 15:48:44 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue Apr 4 15:48:51 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404184119.GA15294@replic.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> <20060404184119.GA15294@replic.net> Message-ID: <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> On 4/4/06, carmen wrote: > > how expensive is a firewire port ? > > firewire stuff is THE niche to fill. > > most newer firewire devices are not supported if if i understand > > correctly. I'll ask. That's a fairly large difference to the current design though. But if there was enough interest perhaps. For it to fit into the current model someone would have to do the VHDL code for a firewire interface rather than PCI. I don't think Tim is opposed to a totally different design but there would be less reuse from what they already have. >yeah this would be where my interest is as well. somehow i dont believe the 2 million >figure (maybe designing a video card from scratch, and printing it up) . i mean can't you >just go to whatever factory in Shenzen is churning out crap for Behringer and have them >slap a GNU label on it and ship it with schematics and open source drivers? I think you are missing the point. The current design for OGD1 is a large FPGA with lots of onboard fast RAM and high speed IO ability. Tim is wondering if such a card (perhaps with some modification for audio) would be useful to the audio community. The FPGA lets the card be any manner of different things if you write the VHDL code to make it happen. As it stands now OGP has a lot of code for doing graphics work. So if there are things that could benefit from a type of audio "hardware acceleration" that is completely user programmable then this card would be great for it. If not well then it may not be of much use. The $2 Million is the cost of getting a video card with a fast ASIC of the final VHDL rather than a big expensive FPGA. Custom silicon ain't cheap. -- Richard A. Smith From ix at replic.net Tue Apr 4 16:02:29 2006 From: ix at replic.net (carmen) Date: Tue Apr 4 16:02:30 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> <20060404184119.GA15294@replic.net> <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> Message-ID: <20060404200229.GB15294@replic.net> > I think you are missing the point. The current design for OGD1 is a > large FPGA with lots of onboard fast RAM and high speed IO ability. > Tim is wondering if such a card (perhaps with some modification for > audio) would be useful to the audio community. there are several commercial PCI/Firewire products similar to this. namely the Pulsar, UAD1, TC PowerCore, and a recent card from Creative. they generally provide DACs and onboard DSP to be used for synths/fx for audio production, or in creative's case, gaming.. considering how many LADSPA plugins are straight up broken on 64bit, for example, i doubt theres a critical mass of developer interest to make them run on an optional DSP card , especially before making them run on the core CPU that AMD has been selling the past 3 or 4 years. can GCC compile C code to run on the FPGA? that could be a swing factor.. i dont think im missing the point of what the card can do. but i think most of us would foremost like something that can be used with low latency with JACK, of suitable quality and portability, and not have to worry about the developer deciding no longer to make ALSA drivers next week because 96% of their users run MacOSX or WinXP.. Carmen From ix at replic.net Tue Apr 4 16:08:09 2006 From: ix at replic.net (carmen) Date: Tue Apr 4 16:08:09 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404200229.GB15294@replic.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> <20060404184119.GA15294@replic.net> <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> <20060404200229.GB15294@replic.net> Message-ID: <20060404200809.GC15294@replic.net> > the vendor deciding no longer to make ALSA drivers next week because 96% of their users run MacOSX or WinXP.. this is a distortion. i'm not aware of any vendor actively supporting linux at all, so open audio hardware would definitely be welcomed.. i mean in Echo's case, they gave some generic non-OS-specific driver code to some Italian dude who ran with it, and eventually got it working nice enough to be rolled into alsa-driver, for firewire it just happened that most vendors were using the same chip, and even then afaik it still required using a patched JACK and bypassed ALSA entirely? and the vendors have moved onto other chips by now? and no idea what is the story behind RME..but i vaguely remember them pulling the rug out from whatever official support.. so yes, i think its a great idea. but we need to get audio first. then we can worry about accelerated DSP..thats the icing on the cake really.. From rlrevell at joe-job.com Tue Apr 4 16:20:31 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 4 16:20:38 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404200229.GB15294@replic.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> <20060404184119.GA15294@replic.net> <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> <20060404200229.GB15294@replic.net> Message-ID: <1144182031.2887.59.camel@mindpipe> On Tue, 2006-04-04 at 20:02 +0000, carmen wrote: > > I think you are missing the point. The current design for OGD1 is a > > large FPGA with lots of onboard fast RAM and high speed IO ability. > > Tim is wondering if such a card (perhaps with some modification for > > audio) would be useful to the audio community. > > there are several commercial PCI/Firewire products similar to this. > namely the Pulsar, UAD1, TC PowerCore, and a recent card from > Creative. they generally provide DACs and onboard DSP to be used for > synths/fx for audio production, or in creative's case, gaming.. > I think there would be a market for this, if the DSP plugin API is fully documented. Usually it's proprietary because the vendors' business model is selling DSP plugins. Lee From mista.tapas at gmx.net Tue Apr 4 16:28:24 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Apr 4 16:28:31 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <1144177837.2887.15.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404102725.GA3586@bth05w.ABSp.alcatel.be> <1144177837.2887.15.camel@mindpipe> Message-ID: <20060404222824.28de1c8d@mango.fruits> On Tue, 04 Apr 2006 15:10:36 -0400 Lee Revell wrote: > On Tue, 2006-04-04 at 12:27 +0200, Alfons Adriaensen wrote: > > For me: > > > > * operate at 48 and 96 kHz. > > Many users also demand 44.1 support, although I don't quite understand > why. errm, to be able to play audio cd's without resampling? Flo -- Palimm Palimm! http://tapas.affenbande.org From pieterp at joow.be Tue Apr 4 16:38:36 2006 From: pieterp at joow.be (Pieter Palmers) Date: Tue Apr 4 16:38:28 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> <20060404184119.GA15294@replic.net> <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> Message-ID: <4432D94C.8030103@joow.be> Richard Smith wrote: > On 4/4/06, carmen wrote: > > >>>how expensive is a firewire port ? >>>firewire stuff is THE niche to fill. >>>most newer firewire devices are not supported if if i understand >>>correctly. > > > I'll ask. That's a fairly large difference to the current design > though. But if there was enough interest perhaps. > For it to fit into the current model someone would have to do the VHDL > code for a firewire interface rather than PCI. I don't think Tim is > opposed to a totally different design but there would be less reuse > from what they already have. If you want to build a firewire soundcard, use the 1394 chipsets already available from different manufacturers. Don't start writing your own VHDL... it's not worth it. They did the $2M investment to develop the ASIC and are selling their chips for a pretty good price. From what I understand the BridgeCo DM1500, the successor of the DM1000 that is used in e.g. the edirol FA101 etc, has a price tag that is about the same of a FPGA that can implement the same functionallity. It should also be able to do single packet latency processing with the DM1500 (1 firewire packet equals 8 frames). This would make the roundtrip latency of the DM1500 - D/A - A/D - DM1500 about 2*8/Fs + AD/DA latency. This comes down to about 1-2ms depending on the dataconverters used. I've recently looked at the datasheet of the DICE-II chipset, and that also handles all firewire to audio (I2S) conversion and framing for >32 channels in each direction. But I don't know how it performs. Count some extra latency introduced by the PC host controller though. I'm sorry to say, but a PCI based system will always be intrinsically lower latency than a FW based system. This is because there is a PCI-to-FireWire bridge present (the host controller). On top of that, virtually all host controllers are OHCI compliant, with only a few vendors selling OHCI chipsets (TI, VIA, NEC, ...) upon which all card manufacturers base their designs. Apparently only TI based OHCI chipsets perform good wrt lowest latency they can handle (although I can't prove this, someone that tested them told me). Why reinvent the wheel? If anything firewire related should be built, the best thing would be a firewire host controller that has built in support for (de)framing the firewire packets, directly into host memory. But why bother using firewire device then... And then we're not even talking about the drivers that have to be written... The freebob project at this point consists of only 2 people, notwithstanding the fact that we do have active manufacturer support and all nescessary documentation. The hardware is out, is priced pretty good and is of quite good quality (e.g. the edirol fa-101, $500 at zzsound.com). The basic functionallity is already present for a year (demo-ed at LAC last year), and we (at least I) expected that getting that code ready in time for LAC would help us getting more people interested in helping. But alas, up till now no contributions have been made. So I ask myself: Would anyone here pay much more than $500 for a similar device that probably won't reach the same performance as currently available devices, and where the drivers still have to be written for. Based upon my experience, I might be sceptical, but I don't think so. My opinion: If the community wants a GPL like firewire audio device, I suggest that you base it on the DM1500 chip, and help us out with FreeBob. That way you can actually get to a decent device with a decent performance in a realistic timeframe. Pieter Palmers FeeBob developer PS: Although the previous might make you think the opposite, I'm NOT on the BridgeCo payroll nor do I own any BridgeCo shares. PPS: The FreeBob project is written in such a way that other firewire based devices can be supported too. For the moment the DM1x00 based devices are the only ones we have the nescessary info for. But there might be others soon. From rlrevell at joe-job.com Tue Apr 4 16:51:30 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 4 16:51:38 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404222824.28de1c8d@mango.fruits> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404102725.GA3586@bth05w.ABSp.alcatel.be> <1144177837.2887.15.camel@mindpipe> <20060404222824.28de1c8d@mango.fruits> Message-ID: <1144183890.2887.67.camel@mindpipe> On Tue, 2006-04-04 at 22:28 +0200, Florian Schmidt wrote: > On Tue, 04 Apr 2006 15:10:36 -0400 > Lee Revell wrote: > > > On Tue, 2006-04-04 at 12:27 +0200, Alfons Adriaensen wrote: > > > For me: > > > > > > * operate at 48 and 96 kHz. > > > > Many users also demand 44.1 support, although I don't quite understand > > why. > > errm, to be able to play audio cd's without resampling? Well, CD audio usually gets resampled anyway if you play them in analog mode. 44.1 is essential for a consumer or "prosumer" device but I would think most users of a high end interface would run at 96Khz and resample 44.1 content. Lee From wagi at monom.org Tue Apr 4 17:07:06 2006 From: wagi at monom.org (Daniel Wagner) Date: Tue Apr 4 17:06:52 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404181721.GB8102@mobilat> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> Message-ID: <4432DFFA.8020800@monom.org> > how expensive is a firewire port ? > firewire stuff is THE niche to fill. > most newer firewire devices are not supported if if i understand > correctly. Just to make a bit advertisement, freebob supports few firewire devices on the market :) Generally, I would not recommend to build a firewire based device in any way. It is has some very nasty features which are hard to get right, e.g. the LLC is extreme difficult. daniel From rlrevell at joe-job.com Tue Apr 4 17:20:54 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 4 17:21:05 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404181721.GB8102@mobilat> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> Message-ID: <1144185655.2887.94.camel@mindpipe> On Tue, 2006-04-04 at 20:17 +0200, torbenh@gmx.de wrote: > how expensive is a firewire port ? > firewire stuff is THE niche to fill. > most newer firewire devices are not supported if if i understand > correctly. I think there's still a future for PCI devices - I don't expect laptop vendors to start making them durable enough to use on stage in a rock club anytime soon. My dream is that with the right hardware the Linux effects box could be the "MythTV box" for musucians, and complete n00bs will be learning Linux just to build them... Lee From loki.davison at gmail.com Tue Apr 4 20:29:58 2006 From: loki.davison at gmail.com (Loki Davison) Date: Tue Apr 4 20:30:05 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404200229.GB15294@replic.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404181721.GB8102@mobilat> <20060404184119.GA15294@replic.net> <8a0c36780604041248g23fad12fp4d93821cde15cfdf@mail.gmail.com> <20060404200229.GB15294@replic.net> Message-ID: On 4/5/06, carmen wrote: > > I think you are missing the point. The current design for OGD1 is a > > large FPGA with lots of onboard fast RAM and high speed IO ability. > > Tim is wondering if such a card (perhaps with some modification for > > audio) would be useful to the audio community. > > there are several commercial PCI/Firewire products similar to this. namely > the Pulsar, UAD1, TC PowerCore, and a recent card from Creative. they > generally provide DACs and onboard DSP to be used for synths/fx for audio > production, or in creative's case, gaming.. > > considering how many LADSPA plugins are straight up broken on 64bit, for > example, i doubt theres a critical mass of developer interest to make them > run on an optional DSP card , especially before making them run on the core > CPU that AMD has been selling the past 3 or 4 years. can GCC compile C code > to run on the FPGA? that could be a swing factor.. > > i dont think im missing the point of what the card can do. but i think most > of us would foremost like something that can be used with low latency with > JACK, of suitable quality and portability, and not have to worry about the > developer deciding no longer to make ALSA drivers next week because 96% of > their users run MacOSX or WinXP.. > > Carmen > I'd never pay 500 euro for a dsp card. Never. A sound card, with nice pre's etc yeah, maybe. I can get a whole lot of cpu for 500 euro. I think this covers the whole client side dsp thing as stated on ardour's website. For that price i can buy 2 dual core amd64 4200+ cpus. I think that would be a better use of the money and do more audio dsp. To me a card like the layla or 1010 is good for 300 euro or less, but dsp chips are no use. Loki From seablaede at gmail.com Wed Apr 5 10:40:44 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Wed Apr 5 10:38:06 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <1144183890.2887.67.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <70a871c80604040022y362a7a0aua97cc7b0a61150a0@mail.gmail.com> <8a0c36780604040225t5b7dee6cre20713fb6542a093@mail.gmail.com> <20060404102725.GA3586@bth05w.ABSp.alcatel.be> <1144177837.2887.15.camel@mindpipe> <20060404222824.28de1c8d@mango.fruits> <1144183890.2887.67.camel@mindpipe> Message-ID: <4433D6EC.1000102@gmail.com> > Well, CD audio usually gets resampled anyway if you play them in analog > mode. 44.1 is essential for a consumer or "prosumer" device but I would > think most users of a high end interface would run at 96Khz and resample > 44.1 content. Possibly to work on material destined for audio CD. 44.1 is still quite common for this use as resampling adds some artifacts. Seablade From ajc at gmx.net Wed Apr 5 19:27:02 2006 From: ajc at gmx.net (Andrew Cannon) Date: Wed Apr 5 19:27:14 2006 Subject: [linux-audio-dev] fast linear resampling on ARM - suggestions? In-Reply-To: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> Message-ID: <44345246.9050502@gmx.net> Tobias Scharnberg wrote: > Hello List, > I'm trying to find a library or code-snippet in order to do audio > resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to > resample the data in realtime - resampling a buffer of data, not a > soundfile. The quality doesn't need to be good so I guess the best > solution might be linear audio resampling. The device to do the > resampling on is an ARM CM-X255 running at 400MHz. > > I tried out libsamplerate so far but when I tested it with the > soundfile conversion test program it needed 3,5 secs to sample from > 8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me. > > Is there something faster that can do the job? > > Any suggestions are highly welcome Hi Tobias I suggest using a Kaiser-window based interpolation algorithm. This is the best filter method to use for sample rate conversion. You can get decent results with 8 taps or even fewer. For example you can get a 6dB bandwidth of about 2.8kHz (at Fs=8kHz) with 50dB alias rejection. (of course you need more taps for high-quality results) I implemented an 8 tap SRC on an ARM-9 using integer arithmetic... I can't remember the exact CPU usage but it was only of the order of 10MHz or so. I'm not familiar with the CPU you mention - if it hasn't got the DSP instructions then it will be a bit slower but you seem to have plenty to spare! Linear interpolation is no good for audio - you will have about 10% distortion! Andrew From linux at blennerhassett.gen.nz Wed Apr 5 19:45:14 2006 From: linux at blennerhassett.gen.nz (Eliot Blennerhassett) Date: Wed Apr 5 19:46:29 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060404200809.GC15294@replic.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <20060404200229.GB15294@replic.net> <20060404200809.GC15294@replic.net> Message-ID: <200604061145.14845.linux@blennerhassett.gen.nz> On Wed, 05 Apr 2006 08:08, carmen wrote: > > the vendor deciding no longer to make ALSA drivers next week because 96% > > of their users run MacOSX or WinXP.. > > this is a distortion. i'm not aware of any vendor actively supporting linux > at all, so open audio hardware would definitely be welcomed. FYI AudioScience has put a lot of effort into making linux drivers, firstly our own HPI API, then ALSA. This is ongoing. Driver is released under GPL, users libs under BSD style licence. We could always do with more help from the community though ;-) http://audioscience.com/internet/download/linux_drivers.htm regards Eliot Blennerhassett AudioScience Inc. From drobilla at connect.carleton.ca Wed Apr 5 19:56:23 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 5 19:56:30 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> Message-ID: <1144281383.25773.18.camel@localhost.localdomain> On Tue, 2006-04-04 at 13:22 +1000, Loki Davison wrote: > > I know basically nothing about audio technology. But given what > > little I do know, here are some things that I think would be > > relatively easy to do with OGD1 and, what shall we call it, OAC1: > > - 60+ audio channels (pick your combination of in and out) > > - (A specialized card could handle lots more channels) > > - 24-bit precision per channel > > - Sample rates in the hundreds of kilohertz > > - Thousands of audio samples and MIDI instruments > > - Sample-based and algorithmically-generated sound-effects > > - Fourier analysis, band filters, mixing, and other sorts of math > > stuff that if I could name it, you'd be impressed > > - Noise-free signals (because we have experience with graphics) > > - Accelerated "3D sound" > > - Accelerated compression/decompression > > - Lots of other things > > > This collection sounds very consumer great. Thousands of audio samples > and MIDI instruments? wtf? Sample-based and algorithmically-generated > sound-effects? Accelerated "3D sound"? Accelerated > compression/decompression? I have a big freaking cpu for that stuff. > Sounds very soundblaster esq. Apart from the 60+ channels which sounds > like a really, really big rack mounting. If that is on xlr plugs or > 1/4" it's huge. Also no discussion about non-soundbasteresq stuff like > balanced in/out, decent pre's, hi-z inputs, dat optical in/out, master > clock and clock source, etc. I think looking at the echo layla or > maudio 1010 is somewhat more useful to most of us than 60 channels. Agreed. "We" don't need a bunch of useless consumer cruft on a card. However channels are good, don't downplay channels :). This thing should have as many channels as possible. Obviously there is a physical limit to how many you can cram in physically, but that's what lightpipe is for. There's many 8x8 rackmount preamps out there you could hook up (including a nice and cheap one from Behringer) Frankly I think 60+ channels is completely unrealistic (otherwise one would probably exist), but what do I know. If it's possible, hell yes put them in there. FWIW, my ideal audio interface _requires_: * As many channels as possible * At least 1 ADAT Lightpipe in/out * Clock sync * Balanced everything * Real 19" rackmount breakout box * Good low latency operation (in Linux w/ Jack) Without those I wouldn't even consider buying it. Some extra stuff would be nice though (preamps, MIDI, headphone amp, etc) -DR- From smithbone at gmail.com Wed Apr 5 20:52:26 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed Apr 5 20:52:33 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <1144281383.25773.18.camel@localhost.localdomain> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> Message-ID: <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> > > Frankly I think 60+ channels is completely unrealistic (otherwise one > would probably exist), but what do I know. If it's possible, hell yes > put them in there. > The hammerfall will do 52 so I don't see 60+ as that much of a stretch.. http://www.rme-audio.com/english/hammer/d9652.htm 60 channels @192/24 is 35Megs/s. A SCSI cards and Gigabit ethernet interface do much more than that. Perhaps you could not get super low latency running all 60 channels. All 60 channels would take a minimum of 300mS to move across the bus. You would need PCI 64/66 at that stage. PCIe cuts that in half or a quarter if you do x2 Getting that to fly in an FPGA however may be the problem as you start running into clock speed limits. And an ASIC suffers from the lack of startup cash. > FWIW, my ideal audio interface _requires_: Thanks for the info. > * At least 1 ADAT Lightpipe in/out Where can I find the spec on this? Google finds lots of Lightpipes. -- Richard A. Smith From rlrevell at joe-job.com Wed Apr 5 21:08:14 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Apr 5 21:08:28 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> Message-ID: <1144285695.2866.19.camel@mindpipe> On Wed, 2006-04-05 at 19:52 -0500, Richard Smith wrote: > > 60 channels @192/24 is 35Megs/s. A SCSI cards and Gigabit ethernet > interface do much more than that. Perhaps you could not get super low > latency running all 60 channels. All 60 channels would take a minimum > of 300mS to move across the bus. You would need PCI 64/66 at that ^^^^^ Do you mean microseconds? To move how many frames? > stage. PCIe cuts that in half or a quarter if you do x2 Also I don't think 192/24 is really a typical config, most people would use 96. Lee From smithbone at gmail.com Wed Apr 5 21:31:29 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed Apr 5 21:31:35 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <1144285695.2866.19.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> <1144285695.2866.19.camel@mindpipe> Message-ID: <8a0c36780604051831v16f5bc37g6cfacfb742130567@mail.gmail.com> On 4/5/06, Lee Revell wrote: > On Wed, 2006-04-05 at 19:52 -0500, Richard Smith wrote: > > > > 60 channels @192/24 is 35Megs/s. A SCSI cards and Gigabit ethernet > > interface do much more than that. Perhaps you could not get super low > > latency running all 60 channels. All 60 channels would take a minimum > > of 300mS to move across the bus. You would need PCI 64/66 at that > ^^^^^ > Do you mean microseconds? To move how many frames? Ah.. yeah.. I _totally_ fsked up the math. Gotta lay off all that crack. A whole frame of 60 channels @ 24bit is only 1.4 uS. Jeez. talk about being bad wrong. That's good news though. That means an fairly low powered FPGA could do that plus a whole lot more. > Also I don't think 192/24 is really a typical config, most people would > use 96. All the more reason to be able to run at 192/24. Using the onboard PLLs of the FPGA you could pretty much run at whatever sample rate you wanted with just a firmware change. But clocking at 192k gets 96 and 48 with simple divisors. 44.1 could be a special case. Most of the fpga now days have more than 1 pll so you could do 1 for the 192 multiples and one for the 44.1 rate. -- Richard A. Smith From rlrevell at joe-job.com Wed Apr 5 21:58:44 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Apr 5 21:58:53 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <1144281383.25773.18.camel@localhost.localdomain> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> Message-ID: <1144288725.2866.30.camel@mindpipe> On Wed, 2006-04-05 at 19:56 -0400, Dave Robillard wrote: > Agreed. "We" don't need a bunch of useless consumer cruft on a card. > However channels are good, don't downplay channels :). This thing > should have as many channels as possible. Obviously there is a physical > limit to how many you can cram in physically, but that's what lightpipe > is for. There's many 8x8 rackmount preamps out there you could hook up > (including a nice and cheap one from Behringer) > > Frankly I think 60+ channels is completely unrealistic (otherwise one > would probably exist), but what do I know. If it's possible, hell yes > put them in there. > > FWIW, my ideal audio interface _requires_: > > * As many channels as possible > * At least 1 ADAT Lightpipe in/out > * Clock sync > * Balanced everything > * Real 19" rackmount breakout box > * Good low latency operation (in Linux w/ Jack) I think after reading the comments in this thread that you may have a hard time finding a niche. There are already devices on the market with good GPL drivers that do all this - the appeal of the open graphics project was that there were no good graphics cards with GPL drivers. That leaves the options of competing on price/quality with the likes of RME and M-Audio, or a DSP device, which although I think it's a cool idea, there's a lot of resistance to it. I don't think your feature set is necessarily "consumer stuff", it's just that most such devices to date (Creative) have kind of been crap. Lately however Creative/EMU's DSP cards have been getting great reviews (X-Fi, EMU 1212M, etc) - they seem to have fixed a lot of the common complaints about the SBLive! based devices (crappy codecs, horrible resampling). And they are still damn cheap ($200-300 tops IIRC) but have no Linux drivers. This might be an area to investigate, but I suspect you would need years of development to produce a device of that quality for anywhere near Creative's price point. Lee From ikeastod at oplink.net Thu Apr 6 00:33:17 2006 From: ikeastod at oplink.net (ikeastod@oplink.net) Date: Thu Apr 6 00:32:45 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <442D231B.2060206@woh.rr.com> Message-ID: <200604060433.k364XH6R006648@localhost.linksys> Dave, Is this to be "Volume 2" or a rewrite? Either one is OK, but I would far more quickly shell out $$$ for the former since I own your first book. Perhaps I'm not alone? Whatever its content, I'll be looking forward to the new one! Thanks for all your good words, Ike Stoddard From v2 at iki.fi Thu Apr 6 01:57:05 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Thu Apr 6 01:57:20 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware Message-ID: <1144303025.4434adb130560@www2.helsinki.fi> Quoting Dave Robillard : > On Tue, 2006-04-04 at 13:22 +1000, Loki Davison wrote: > * At least 1 ADAT Lightpipe in/out I'd vote for at least 4 ADAT inputs so you could connect two 8 channel preamps using 88.2k or 96k to the device. ;) Sampo From mle+la at mega-nerd.com Thu Apr 6 04:03:31 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Apr 6 05:39:56 2006 Subject: [linux-audio-dev] fast linear resampling on ARM - suggestions? In-Reply-To: <44345246.9050502@gmx.net> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <44345246.9050502@gmx.net> Message-ID: <20060406180331.53609004.mle+la@mega-nerd.com> Andrew!!! How's life post-Farilight? What are you up to now? Maybe off list :-). Andrew Cannon wrote: > I suggest using a Kaiser-window based interpolation algorithm. This is > the best filter method to use for sample rate conversion. You can get > decent results with 8 taps or even fewer. For example you can get a 6dB > bandwidth of about 2.8kHz (at Fs=8kHz) with 50dB alias rejection. (of > course you need more taps for high-quality results) By way of comparison, the fastest of my three sinc based converters has a 3dB bandwidth of 3.2kHz with reference to Fs of 8kHz. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "A mouse is a device used to point at the xterm you want to type in." -- Kim Alm, a.s.r From dsbaikov at gmail.com Thu Apr 6 06:36:34 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 6 06:36:40 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> Message-ID: <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> Hello! I'm planning to get RME Multiface (II) and have a question to it's owners. Can you, please, post its latency in audio loop, measured with jaaa in 2x64 buffer setup. Thank you. Regards, Dmitry. P.S. crossposted from LAU, since there were no responces. From fons.adriaensen at alcatelaleniaspace.com Thu Apr 6 07:42:17 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Apr 6 07:42:31 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> Message-ID: <20060406114216.GA4653@bth05w.ABSp.alcatel.be> On Thu, Apr 06, 2006 at 02:36:34PM +0400, Dmitry Baikov wrote: > Hello! > > I'm planning to get RME Multiface (II) and have a question to it's owners. > Can you, please, post its latency in audio loop, measured with jaaa in > 2x64 buffer setup. Better use jdelay for that, that's why it exists ! -- FA Follie! Follie! Delirio vano e' questo! From patrickkidd.lists at gmail.com Thu Apr 6 08:14:32 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Thu Apr 6 08:14:42 2006 Subject: [linux-audio-dev] music engine Message-ID: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> I've been looking for a high-performance music engine. It must have an asynchronous control (socket, pipe?) mechanism to seperate the application from the audio thread. I'm looking for: start/stop samples on the beat scaled tempo control across all samples volume effects? easily wrappable (I'll write extensions, implement protocol plugins...) with python I'm trying to write something like ableton live without writing an engine all over again. FMODex would be *perfect* if it had a well-defined tempo/beat/sync interface. thanks -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From James at superbug.co.uk Thu Apr 6 08:32:41 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Apr 6 08:32:49 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <1144288725.2866.30.camel@mindpipe> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> <1144288725.2866.30.camel@mindpipe> Message-ID: <44350A69.5030903@superbug.co.uk> Lee Revell wrote: > Lately however Creative/EMU's DSP cards have been getting great reviews > (X-Fi, EMU 1212M, etc) - they seem to have fixed a lot of the common > complaints about the SBLive! based devices (crappy codecs, horrible > resampling). And they are still damn cheap ($200-300 tops IIRC) but > have no Linux drivers. This might be an area to investigate, but I > suspect you would need years of development to produce a device of that > quality for anywhere near Creative's price point. > Creative have actually donated an X-Fi and an EMU1212M to me. No datasheets, but at least having the hardware is a start. (Creative pass me some datasheets for other cards though) I have currently got as far as horrible noises coming from the EMU1212M. So, after some more reverse engineering, we should have that working. The X-Fi is a totally new beast, so that is a long way off currently. My point is that with reverse engineering, we can get these commercial cards working with Linux, so do we really need to build our own open source ones? Sound cards are not nearly as complicated as graphics cards, so the reverse engineering task is less and therefore do-able. Saying that, the X-Fi might be an exception. If I was designing a GPL sound hardware, I would want to separate the DAC and ADC tasks from any other processing done by the card. I.e. The card would do all the DSP, FPGA processing and only have digital external links. Then have the DAC and ADC as a separate external device. The main task would be designing a good interface to the DAC and ADCs that would not require any firmware on the DAC and ADC device. The EMU1212M has this separation. It has two parts: a) The EMU1010 is the DSP/FPGA card. b) The EMU0202 is the DAC/ADC device. There is another area of GPL development work that might be of interest to the list and that is the Software Defined Radio open source work going on at the moment. A lot of that is based around using a sound card for the ADC, but sampling at 96khz/24bit. One has an external device that does the down mixing of RF to an IF of about 32khz. The sound card then samples that IF at 96khz and then processes the IF. The main requirement for SDR is dynamic range, so the 24bit is important. So the aim of getting a very good ADC for 96khz/24bit in the SDR market, is the same as that in the Audio market. So, you might be able to combine efforts. James From dsbaikov at gmail.com Thu Apr 6 08:50:37 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 6 08:50:43 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <20060406114216.GA4653@bth05w.ABSp.alcatel.be> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <20060406114216.GA4653@bth05w.ABSp.alcatel.be> Message-ID: <70a871c80604060550te46dd0ar9e66a4664a8f995f@mail.gmail.com> > Better use jdelay for that, that's why it exists ! Oops, my bad - I mixed up the names... jdelay, definetely! P.S. that's why I get no responces - they are still measuring.... From dsbaikov at gmail.com Thu Apr 6 08:54:23 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 6 08:54:29 2006 Subject: [linux-audio-dev] EMU 1212M Message-ID: <70a871c80604060554o6cb3f29wf426d0be17f0a234@mail.gmail.com> On 4/6/06, James Courtier-Dutton wrote: > Creative have actually donated an X-Fi and an EMU1212M to me. > No datasheets, but at least having the hardware is a start. (Creative > pass me some datasheets for other cards though) > I have currently got as far as horrible noises coming from the EMU1212M. So, does it mean that soon we'll have linux drivers for Emu 1212, 1616 and 1818? Regards, Dmitry. From James at superbug.co.uk Thu Apr 6 09:43:12 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Apr 6 09:43:30 2006 Subject: [linux-audio-dev] Re: EMU 1212M In-Reply-To: <70a871c80604060554o6cb3f29wf426d0be17f0a234@mail.gmail.com> References: <70a871c80604060554o6cb3f29wf426d0be17f0a234@mail.gmail.com> Message-ID: <44351AF0.50506@superbug.co.uk> Dmitry Baikov wrote: > On 4/6/06, James Courtier-Dutton wrote: > >> Creative have actually donated an X-Fi and an EMU1212M to me. >> No datasheets, but at least having the hardware is a start. (Creative >> pass me some datasheets for other cards though) >> I have currently got as far as horrible noises coming from the EMU1212M. >> > > So, does it mean that soon we'll have linux drivers for Emu 1212, 1616 and 1818? > > Regards, > > Dmitry. > It kind of depends on the amount of time I have, and which tasks I do first. I don't get paid for any particular task, so I just work on things as and when I feel like it. Most recently I have been doing some SDR work. James From fons.adriaensen at alcatelaleniaspace.com Thu Apr 6 10:40:54 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Apr 6 10:41:13 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <70a871c80604060550te46dd0ar9e66a4664a8f995f@mail.gmail.com> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <20060406114216.GA4653@bth05w.ABSp.alcatel.be> <70a871c80604060550te46dd0ar9e66a4664a8f995f@mail.gmail.com> Message-ID: <20060406144053.GB4653@bth05w.ABSp.alcatel.be> On Thu, Apr 06, 2006 at 04:50:37PM +0400, Dmitry Baikov wrote: > > Better use jdelay for that, that's why it exists ! > > Oops, my bad - I mixed up the names... > > P.S. that's why I get no responces - they are still measuring.... It shouldn't take more than a minute... -- FA Follie! Follie! Delirio vano e' questo! From dsbaikov at gmail.com Thu Apr 6 10:44:13 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 6 10:44:29 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <20060406144053.GB4653@bth05w.ABSp.alcatel.be> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <20060406114216.GA4653@bth05w.ABSp.alcatel.be> <70a871c80604060550te46dd0ar9e66a4664a8f995f@mail.gmail.com> <20060406144053.GB4653@bth05w.ABSp.alcatel.be> Message-ID: <70a871c80604060744r382da6e9n768cb2cdf25627c9@mail.gmail.com> > > P.S. that's why I get no responces - they are still measuring.... > It shouldn't take more than a minute... I mean they are measuring with jaaa ;) Still hoping to get the info, Dmitry. From rlrevell at joe-job.com Thu Apr 6 11:48:15 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 6 11:49:09 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> Message-ID: <1144338496.2866.60.camel@mindpipe> On Thu, 2006-04-06 at 04:14 -0800, Patrick Stinson wrote: > I've been looking for a high-performance music engine. It must have an > asynchronous control (socket, pipe?) mechanism to seperate the > application from the audio thread. > > I'm looking for: > > start/stop samples on the beat > scaled tempo control across all samples > volume > effects? > easily wrappable (I'll write extensions, implement protocol > plugins...) with python > > I'm trying to write something like ableton live without writing an > engine all over again. FMODex would be *perfect* if it had a > well-defined tempo/beat/sync interface. > I think FreeWheeling might be the closest thing to Live that exists for Linux, have you looked at it? Lee From paul at linuxaudiosystems.com Thu Apr 6 12:00:07 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Apr 6 11:56:27 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144338496.2866.60.camel@mindpipe> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> Message-ID: <1144339207.14746.117.camel@localhost.localdomain> On Thu, 2006-04-06 at 11:48 -0400, Lee Revell wrote: > On Thu, 2006-04-06 at 04:14 -0800, Patrick Stinson wrote: > > I've been looking for a high-performance music engine. It must have an > > asynchronous control (socket, pipe?) mechanism to seperate the > > application from the audio thread. > > > > I'm looking for: > > > > start/stop samples on the beat > > scaled tempo control across all samples > > volume > > effects? > > easily wrappable (I'll write extensions, implement protocol > > plugins...) with python > > > > I'm trying to write something like ableton live without writing an > > engine all over again. FMODex would be *perfect* if it had a > > well-defined tempo/beat/sync interface. > > > > I think FreeWheeling might be the closest thing to Live that exists for > Linux, have you looked at it? Freewheeling is *so* unlike Live its hard to even link the two. Just for a start, Live is organized around a timeline, Freewheeling is not. From geoff at riyal.ugcs.caltech.edu Thu Apr 6 12:25:13 2006 From: geoff at riyal.ugcs.caltech.edu (Lance Blisters) Date: Thu Apr 6 12:25:24 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> Message-ID: <20060406162513.GA16158@riyal.ugcs.caltech.edu> On Thu, Apr 06, 2006 at 04:14:32AM -0800, Patrick Stinson wrote: > I've been looking for a high-performance music engine. It must have an > asynchronous control (socket, pipe?) mechanism to seperate the > application from the audio thread. Everytime this comes up, i hesitantly recommend GDAM. Its an 8 year old C and glib project, a server/client music engine with various music interfaces on top. Its core goal was DJ mixing, back when there were few software dj apps available. The design for this was not at all "mimic a turntable or cd deck's interface" but rather "digital music files, each with one or more areas with regular rhythm, combined and symchronized in different ways". So there are server-side, sample-accurate synch functions based on defining tempo-and-downbeat for two tracks and commanding one to beatmatch to the other. It will even walk the audio tree and take filters which change tempo, resample, or add latency into account. It is truly sample accurate, you can play two copies of a song, invert one, beatmatch, and get silence. GDAM also has seamless queueing of upcoming tracks, numerous builtin effects and LADSPA and JACK support. You could implement the GDAM protocol yourself in any language, or program against the "client" library which handles the protocol, or program against the "model" library where a number of higher level client-side concepts (turntables, sequencers etc) are implemented. Also a GTK-based GUI library is available with pixmap-based widgets. Why the hesitance? I can't promise any time at all to explain or help. Development of GDAM has been ongoing but i haven't made a release in years, and the documentation is quite old, and doesn't cover developer topics. GDAM server audio engine really should be able to handle nearly anything you can dream up, its just a matter of all the organization and interface work. I was close to doing a live-alike myself (and have a half-finished attempt at a matrix-style loop mixing skin in CVS). If you search for GDAM or ableton in the list archives you'll find some other responses with more details. http://gdam.ffem.org/ -geoff From dave at pawfal.org Thu Apr 6 13:24:21 2006 From: dave at pawfal.org (Dave Griffiths) Date: Thu Apr 6 13:25:51 2006 Subject: [linux-audio-dev] liblo: restarting the server thread Message-ID: <29385.193.203.82.226.1144344261.squirrel@www.webmail.pawfal.org> Hi all, I'm trying to restart a liblo thread with the same port, but something seems to being kept hold of, as it fails (this may be intentional though). I have a test case here - am I being daft, or should this work: ---8<--- #include #include void handler(int num, const char *msg, const char *path) { printf("liblo server error %d\n",num); } int main() { printf("once\n"); lo_server_thread thr = lo_server_thread_new("4444",handler); lo_server_thread_start(thr); lo_server_thread_stop(thr); lo_server_thread_free(thr); printf("twice\n"); thr = lo_server_thread_new("4444",handler); } --->8--- I get the output: once twice liblo server error 9904 cheers, dave From tito at rumford.de Thu Apr 6 14:35:29 2006 From: tito at rumford.de (Wolfgang Woehl) Date: Thu Apr 6 13:51:58 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <70a871c80604060744r382da6e9n768cb2cdf25627c9@mail.gmail.com> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <20060406144053.GB4653@bth05w.ABSp.alcatel.be> <70a871c80604060744r382da6e9n768cb2cdf25627c9@mail.gmail.com> Message-ID: <200604062035.29945.tito@rumford.de> "Dmitry Baikov" : > > > P.S. that's why I get no responces - they are still > > > measuring.... Might be because there are no Multiface II's around. Anyway, here are numbers for a hdsp 9652 + Behringer ada8000 audio loop, the hdsp has similar core specs down to the FPGA architecture. jackd with -p 64 -n 2 jdelay -> pcm_playback -> ada8000 -> pcm_capture -> jdelay makes jdelay say 195.440 frames which is good for 2 x 64 frames jack latency + 2 x 33.72 frames non-jack latency (in part hdsp's handling, in part the ada8000's handling) Can't take the ada8000 out of the picture because the hdsp has no analog inputs, same "problem" with a digiface, I guess. I'd appreciate the same measurement from a multiface owner. -- Wolfgang From Jan.Weil at web.de Thu Apr 6 14:28:32 2006 From: Jan.Weil at web.de (Jan Weil) Date: Thu Apr 6 14:28:38 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> Message-ID: <1144348112.6757.16.camel@localhost> Hi Dmitry, Am Donnerstag, den 06.04.2006, 14:36 +0400 schrieb Dmitry Baikov: > I'm planning to get RME Multiface (II) and have a question to it's owners. > Can you, please, post its latency in audio loop, measured with jaaa in > 2x64 buffer setup. 206.805 This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y, jackd 0.100.7, 2x64@48000. Now what does that value tell me? These are samples, I suppose, i. e. 4.308 msec? Fons, how do you think about a little accompanying README? :) Jan From fons.adriaensen at skynet.be Thu Apr 6 14:52:29 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Thu Apr 6 14:45:23 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <1144348112.6757.16.camel@localhost> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <1144348112.6757.16.camel@localhost> Message-ID: <20060406185229.GB4748@linux-1> On Thu, Apr 06, 2006 at 08:28:32PM +0200, Jan Weil wrote: > 206.805 > > This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y, > jackd 0.100.7, 2x64@48000. > > Now what does that value tell me? These are samples, I suppose, i. e. > 4.308 msec? Yep, it's samples. > Fons, how do you think about a little accompanying README? :) Good idea :-) This was written and released in a hurry... Or maby I should just add 'frames' to the printed value. Have you been able to use -p 64 with 2.6.16 on the Thinkpad with ACPI ? I had no problems with it on my R51 when using 2.6.8 (SuSE 9.2), but since 2.6.13 (SuSE 10.0) I have to disable it. Killing the modules doesn't help, but acpi=off on the kernel command line does. Same with 2.6.15-rt. APM doesn't seem to do any harm, so that's what I use now. I wonder if the new dbus things are causing this. -- FA Follie! Follie! Delirio vano e' questo! From rzewnickie at rfa.org Thu Apr 6 14:47:39 2006 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Thu Apr 6 14:48:28 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> Message-ID: <20060406184739.GB24387@rfa.org> On Wed, Apr 05, 2006 at 07:52:26PM -0500, Richard Smith wrote: > > > > Frankly I think 60+ channels is completely unrealistic (otherwise one > > would probably exist), but what do I know. If it's possible, hell yes > > put them in there. > > > > The hammerfall will do 52 so I don't see 60+ as that much of a stretch.. > > http://www.rme-audio.com/english/hammer/d9652.htm And there's the madi interface, too, with 128 channels: http://www.rme-audio.com/english/madi/hdspmadi.htm -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network@rfa.org. From rlrevell at joe-job.com Thu Apr 6 14:57:28 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 6 14:57:39 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <20060406185229.GB4748@linux-1> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <1144348112.6757.16.camel@localhost> <20060406185229.GB4748@linux-1> Message-ID: <1144349849.2866.84.camel@mindpipe> On Thu, 2006-04-06 at 20:52 +0200, fons adriaensen wrote: > Have you been able to use -p 64 with 2.6.16 on the Thinkpad with > ACPI ? I had no problems with it on my R51 when using 2.6.8 (SuSE > 9.2), but since 2.6.13 (SuSE 10.0) I have to disable it. Killing the > modules doesn't help, but acpi=off on the kernel command line does. > Same with 2.6.15-rt. APM doesn't seem to do any harm, so that's what I > use now. I wonder if the new dbus things are causing this. I doubt it's related to dbus, it sounds more like an ACPI kernel bug was introduced. How exactly does it fail? Lee From fons.adriaensen at skynet.be Thu Apr 6 15:25:24 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Thu Apr 6 15:18:10 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <1144349849.2866.84.camel@mindpipe> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <1144348112.6757.16.camel@localhost> <20060406185229.GB4748@linux-1> <1144349849.2866.84.camel@mindpipe> Message-ID: <20060406192524.GC4748@linux-1> On Thu, Apr 06, 2006 at 02:57:28PM -0400, Lee Revell wrote: > On Thu, 2006-04-06 at 20:52 +0200, fons adriaensen wrote: > > Have you been able to use -p 64 with 2.6.16 on the Thinkpad with > > ACPI ? I had no problems with it on my R51 when using 2.6.8 (SuSE > > 9.2), but since 2.6.13 (SuSE 10.0) I have to disable it. Killing the > > modules doesn't help, but acpi=off on the kernel command line does. > > Same with 2.6.15-rt. APM doesn't seem to do any harm, so that's what I > > use now. I wonder if the new dbus things are causing this. > > I doubt it's related to dbus, it sounds more like an ACPI kernel bug was > introduced. > > How exactly does it fail? Every 40 seconds I get a shower of timeouts in JACK, even when no clients are running. I suspected the battery check of course, but that is configured for a 60 second period, and it didn't do any harm before. Killing powersaved and friends doesn't help, so indeed it looks like a kernel bug. BTW, I noticed your talk in the LAC2006 program just a few minutes ago. Looking forward to see you there ! -- FA Follie! Follie! Delirio vano e' questo! From rlrevell at joe-job.com Thu Apr 6 15:31:42 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 6 15:31:52 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <20060406192524.GC4748@linux-1> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <1144348112.6757.16.camel@localhost> <20060406185229.GB4748@linux-1> <1144349849.2866.84.camel@mindpipe> <20060406192524.GC4748@linux-1> Message-ID: <1144351903.2866.93.camel@mindpipe> On Thu, 2006-04-06 at 21:25 +0200, fons adriaensen wrote: > Every 40 seconds I get a shower of timeouts in JACK, even when no clients > are running. I suspected the battery check of course, but that is configured > for a 60 second period, and it didn't do any harm before. Killing powersaved > and friends doesn't help, so indeed it looks like a kernel bug. > If you really want to solve this and are sure it broke between 2.6.12 and 2.6.13 you could do a git bisect to find the problem. If all you know is it broke between 2.6.8 and 2.6.13 - ugh ;-) > BTW, I noticed your talk in the LAC2006 program just a few minutes > ago. Looking forward to see you there ! Yep, looking forward to it myself! Lee From ix at replic.net Thu Apr 6 15:40:52 2006 From: ix at replic.net (carmen) Date: Thu Apr 6 15:40:51 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144339207.14746.117.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> Message-ID: <20060406194052.GA16853@replic.net> > Freewheeling is *so* unlike Live its hard to even link the two. Just for > a start, Live is organized around a timeline, Freewheeling is not. Live does have a freewheeling mode.where you can basically turn on and off loops and fx, McMusic style. you can record the actions in this mode, and view them on the timeline.. From tito at rumford.de Thu Apr 6 16:26:49 2006 From: tito at rumford.de (Wolfgang Woehl) Date: Thu Apr 6 15:42:52 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <20060406162513.GA16158@riyal.ugcs.caltech.edu> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406162513.GA16158@riyal.ugcs.caltech.edu> Message-ID: <200604062226.49928.tito@rumford.de> Lance Blisters : > GDAM also has seamless queueing of upcoming tracks, > numerous builtin effects and LADSPA and JACK support. You Is there an available release somewhere with jack support? Am I missing a magic switch? Jack support, that would be just awesome. I have an elder suse rpm (gdam-0.942-349) with no hint about where and how to invoke jack ports. Oh, the current tarball build fails with "gdasspatialstereo.c:73:40: pasting "->" and "lear" does not give a valid preprocessing token" -- Wolfgang From rlrevell at joe-job.com Thu Apr 6 15:54:35 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 6 15:54:43 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060406194052.GA16853@replic.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> Message-ID: <1144353276.2866.109.camel@mindpipe> On Thu, 2006-04-06 at 19:40 +0000, carmen wrote: > > Freewheeling is *so* unlike Live its hard to even link the two. Just for > > a start, Live is organized around a timeline, Freewheeling is not. > > Live does have a freewheeling mode.where you can basically turn on and > off loops and fx, McMusic style. you can record the actions in this > mode, and view them on the timeline.. > Yeah, this is what I was referring to. I've never touched the sequencer view in Live. And, I don't think it's fair to call it McMusic - all I use Live for is an effects host for my guitar, because I like the builtin effects and it has by far the best interface of any audio app. Lee From geoff at riyal.ugcs.caltech.edu Thu Apr 6 16:02:38 2006 From: geoff at riyal.ugcs.caltech.edu (Lance Blisters) Date: Thu Apr 6 16:02:55 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <200604062226.49928.tito@rumford.de> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406162513.GA16158@riyal.ugcs.caltech.edu> <200604062226.49928.tito@rumford.de> Message-ID: <20060406200238.GA17901@riyal.ugcs.caltech.edu> Sorry, no release since then. I'm 90% certain that full JACK support is in CVS already, if not then it'll be in within a week as i'm planning a big cvs commit binge (purge?) of the last month's developments. Unfortunately I have no plans to release but do plan to keep CVS compileable and up to date. Simply can't be done given my schedule. -geoff On Thu, Apr 06, 2006 at 10:26:49PM +0200, Wolfgang Woehl wrote: > Lance Blisters : > > > GDAM also has seamless queueing of upcoming tracks, > > numerous builtin effects and LADSPA and JACK support. You > > Is there an available release somewhere with jack support? Am > I missing a magic switch? Jack support, that would be just > awesome. > > I have an elder suse rpm (gdam-0.942-349) with no hint about > where and how to invoke jack ports. > > Oh, the current tarball build fails with > "gdasspatialstereo.c:73:40: pasting "->" and "lear" does not > give a valid preprocessing token" > > -- > Wolfgang From jdboyd at jdboyd.net Thu Apr 6 15:56:55 2006 From: jdboyd at jdboyd.net (Joshua Boyd) Date: Thu Apr 6 16:11:50 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <1144281383.25773.18.camel@localhost.localdomain> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> Message-ID: <20060406195655.GD19660@jdboyd.zill.net> On Wed, Apr 05, 2006 at 07:56:23PM -0400, Dave Robillard wrote: > Agreed. "We" don't need a bunch of useless consumer cruft on a card. > However channels are good, don't downplay channels :). This thing > should have as many channels as possible. Obviously there is a physical > limit to how many you can cram in physically, but that's what lightpipe > is for. There's many 8x8 rackmount preamps out there you could hook up > (including a nice and cheap one from Behringer) Has anyone ever tried to build a lightpipe device? I'm not sure you can get the recievers or transmitters for them for building open or hobbiest devices, but would love to hear otherwise. > Frankly I think 60+ channels is completely unrealistic (otherwise one > would probably exist), but what do I know. If it's possible, hell yes > put them in there. I have a 2U box next to me that supports 80 channels in AND out, while still having 20 some connectors for other things. Furthermore, this box has a networking system that puts 64 complete AES channels on coax ring network. This box is all digital audio in and out, not analog. I think this box is a clean indication that it should be feasible to have at least 80 channels in and out from a system that uses a single PCI card and a 2U breakout box. If you want XLR analog, that would probably require more space. I see a lot of pro audio equipment that uses custom wired connectors, but I don't like them. Heck, if one had the specs forthe token ring network used (which is a custom one), one might be able to create a PCI card to do just that reusing the rest of the box. But the company that makes it has no interest in doing such a thing, so someone else probably needs to start from scratch. > FWIW, my ideal audio interface _requires_: > > * As many channels as possible > * At least 1 ADAT Lightpipe in/out > * Clock sync Sure, but why not also ask for it to be able to operate as the master and offer a word clock output to other gear. Or perhaps offer the avility to sync to blackburst coming in and still drive a synced word clock going out. > * Balanced everything I think balanced for digital is overrated. I may be strange, but I prefer coax for digital audio. And I mean real coax with BNCs, not coax with RCA connectors. BNCs are used for word clocks, so why not stick with them for the rest of the digital audio gear? > * Real 19" rackmount breakout box Any such system should be laughed at if it doesn't at least offer that as an option. -- Joshua D. Boyd jdboyd@jdboyd.net http://www.jdboyd.net/ http://www.joshuaboyd.org/ From jdboyd at jdboyd.net Thu Apr 6 15:58:51 2006 From: jdboyd at jdboyd.net (Joshua Boyd) Date: Thu Apr 6 16:14:56 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> Message-ID: <20060406195851.GE19660@jdboyd.zill.net> On Wed, Apr 05, 2006 at 07:52:26PM -0500, Richard Smith wrote: > Getting that to fly in an FPGA however may be the problem as you start > running into clock speed limits. And an ASIC suffers from the lack of > startup cash. I've seen a 64 channel interface fit into a single Spartan 2E that was small enough to be supported free Xilinx Webpack. Since then, the current web pack supports spartan3s that are bigger and faster than that project used. -- Joshua D. Boyd jdboyd@jdboyd.net http://www.jdboyd.net/ http://www.joshuaboyd.org/ From b0ef at esben-stien.name Thu Apr 6 18:02:20 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Thu Apr 6 16:15:28 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> (Patrick Stinson's message of "Thu, 6 Apr 2006 04:14:32 -0800") References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> Message-ID: <87ek0ae51v.fsf@esben-stien.name> "Patrick Stinson" writes: > music engine SuperCollider[1] [1]http://www.audiosynth.com/ -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From fons.adriaensen at skynet.be Thu Apr 6 16:35:50 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Thu Apr 6 16:32:27 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060406195851.GE19660@jdboyd.zill.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> <8a0c36780604051752k4c4a2af2j13502e3fbe030e06@mail.gmail.com> <20060406195851.GE19660@jdboyd.zill.net> Message-ID: <20060406203550.GE4748@linux-1> On Thu, Apr 06, 2006 at 03:58:51PM -0400, Joshua Boyd wrote: > On Wed, Apr 05, 2006 at 07:52:26PM -0500, Richard Smith wrote: > > > Getting that to fly in an FPGA however may be the problem as you start > > running into clock speed limits. And an ASIC suffers from the lack of > > startup cash. > > I've seen a 64 channel interface fit into a single Spartan 2E that was > small enough to be supported free Xilinx Webpack. Since then, the > current web pack supports spartan3s that are bigger and faster than that > project used. Right. FPGA sizes and speeds are absolutely not a limiting factor when designing an audio interface. Forget about ASICs for small volumes, unless you are already rich. -- FA Follie! Follie! Delirio vano e' questo! From jussi.laako at pp.inet.fi Thu Apr 6 16:37:06 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Thu Apr 6 16:37:18 2006 Subject: [linux-audio-dev] Re: GPL Audio Hardware In-Reply-To: <20060406195655.GD19660@jdboyd.zill.net> References: <8a0c36780604031933o4ecd9e95m1d933fcafaf0e5b0@mail.gmail.com> <1144281383.25773.18.camel@localhost.localdomain> <20060406195655.GD19660@jdboyd.zill.net> Message-ID: <44357BF2.6050404@pp.inet.fi> Joshua Boyd wrote: > Has anyone ever tried to build a lightpipe device? I'm not sure you can > get the recievers or transmitters for them for building open or hobbiest > devices, but would love to hear otherwise. ADAT? Sure, I have pile of those RX/TX units. > I think balanced for digital is overrated. I may be strange, but I > prefer coax for digital audio. And I mean real coax with BNCs, not coax > with RCA connectors. Balanced helps on grounding problems when done correctly (shield connected only from transmitting end and transformer coupled signals). However, I prefer using fiber optics. Much more bandwidth and no grounding problems with large installations. - Jussi From dsbaikov at gmail.com Thu Apr 6 16:44:55 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 6 16:45:05 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <200604062035.29945.tito@rumford.de> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <20060406144053.GB4653@bth05w.ABSp.alcatel.be> <70a871c80604060744r382da6e9n768cb2cdf25627c9@mail.gmail.com> <200604062035.29945.tito@rumford.de> Message-ID: <70a871c80604061344x3f1f9216wada05e6f41027e8a@mail.gmail.com> Thank you for the answers. On 4/6/06, Wolfgang Woehl wrote: > Might be because there are no Multiface II's around. My bad again, too strict specification ;) I'm sure Multiface II has nearly the same values as an original Multiface. They differs in analog part mostly and has different DACs/ADCs (possibly meaning different amout of buffering). From tito at rumford.de Thu Apr 6 17:24:18 2006 From: tito at rumford.de (Wolfgang Woehl) Date: Thu Apr 6 16:48:04 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <20060406200238.GA17901@riyal.ugcs.caltech.edu> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <200604062226.49928.tito@rumford.de> <20060406200238.GA17901@riyal.ugcs.caltech.edu> Message-ID: <200604062324.18180.tito@rumford.de> Lance Blisters : > Sorry, no release since then. I'm 90% certain that full > JACK support is in CVS already, if not then it'll be in > within a week as i'm planning a big cvs commit binge > (purge?) of the last month's developments. Unfortunately I > have no plans to release but do plan to keep CVS > compileable and up to date. Simply can't be done given my > schedule. Some time ago I was showing off music stuff you could do with a linux box and being fascinated I picked GDAM. Both my friend's and my jaws dropped when we slowly realized how far ahead of our mindsets GDAM was. JACK support would just kill me, I guess. Don't. -- Wolfgang From dsbaikov at gmail.com Thu Apr 6 16:51:25 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 6 16:51:31 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <70a871c80604061344x3f1f9216wada05e6f41027e8a@mail.gmail.com> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <20060406144053.GB4653@bth05w.ABSp.alcatel.be> <70a871c80604060744r382da6e9n768cb2cdf25627c9@mail.gmail.com> <200604062035.29945.tito@rumford.de> <70a871c80604061344x3f1f9216wada05e6f41027e8a@mail.gmail.com> Message-ID: <70a871c80604061351q496b355dna57c9cb166701300@mail.gmail.com> My Delta66 has latency of 188 samples. In theory, Multiface's could have the same results, but it definetely should do more buffering to send values to breakout box. As Jan measured, there is a little: ~207 vs 188. Thank you! Dmitry. P.S. if only EMU 1616M had linux drivers... At least RME has much better quality for its price, I hope. From Dr.Graef at t-online.de Thu Apr 6 17:18:09 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Apr 6 17:18:22 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060406194052.GA16853@replic.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> Message-ID: <44358591.8010704@t-online.de> carmen wrote: >>Freewheeling is *so* unlike Live its hard to even link the two. Just for >>a start, Live is organized around a timeline, Freewheeling is not. > > Live does have a freewheeling mode.where you can basically turn on and off loops and fx, McMusic style. you can record the actions in this mode, and view them on the timeline.. Yes, and don't forget the session interface organized like a spreadsheet (rows = scenes, columns = instruments, cells = MIDI or audio clips) which works just great both for live improvisation and experimental compositional work. Might also be neat to have something like this as a frontend for SuperCollider, where the clips may be snippets of SC code to be executed... BTW, regarding the original question: SuperCollider might well be the realtime audio engine you're looking for, it's programmable and extensible (via plugins) and thus very versatile. And it's controlled via OSC. Of course you'll have to add the necessary plugins to do the time stretching/pitch shifting stuff... ;-) Anyway, having something like Ableton Live on Linux would be a great boon, it's the one single program that I still run Windows for. But IMHO recreating that from scratch as open source for Linux is a HUGE project, something of the order of Ardour's complexity. It might be a better idea to add full MIDI support to Ardour and work on the internal data structures so that a session/freewheeling interface could be added to it. (If that's even possible, Paul didn't seem to think that the current architecture would support this when we discussed this question at last year's LAC.) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From rlrevell at joe-job.com Thu Apr 6 17:27:46 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 6 17:27:55 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <44358591.8010704@t-online.de> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> Message-ID: <1144358867.12038.9.camel@mindpipe> On Thu, 2006-04-06 at 23:18 +0200, Albert Graef wrote: > Anyway, having something like Ableton Live on Linux would be a great > boon, it's the one single program that I still run Windows for. But > IMHO recreating that from scratch as open source for Linux is a HUGE > project, something of the order of Ardour's complexity. I heard from someone at Ableton that one guy wrote the Live engine in about 3 months. Lee From ix at replic.net Thu Apr 6 17:45:55 2006 From: ix at replic.net (carmen) Date: Thu Apr 6 17:45:53 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144358867.12038.9.camel@mindpipe> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> Message-ID: <20060406214555.GD16853@replic.net> > I heard from someone at Ableton that one guy wrote the Live engine in > about 3 months. yeah its not that complex. all you need is something that can play audio files realtime at varying pitches/speeds and apply FX chains, and a GUI to facilitate the arrangement and FX parameterization.. i was able to whip up a LIVE-esque timeline GUI in an afternoon using the Tk wavesurfer library: http://whats-your.name/pr/seq.png but have yet to find the optimal backend. heres my investigations so far: PD and xsample~/dssi~: has the raw materials, but unfortunately doesnt work on amd64, and it its lack of subpatch polyphony means you would have to preallocate a set limit of active channels..and even a bit of disk access to load soundfiles is enough to get it kicked out of the jack graph due to its utter nonthreadedness.. SC and Chuck: would likely work as well, but AFAIK neither one supports LADSPA or DSSI at the moment, SCLang definitely doesnt work on x86_64, and Chuck segfaulted as well but i'm guessing since its newer it was designed with 64bit compatibility and mind and the crash is some other issue SooperLooper + OSC-aware LADSPA Rack and Jack Patcher: seems like the jack graph would get crazy quick, but i will probably try this next, since the above options are out for me at the moment unless i setup a 32bit chroot, but maybe i will get good enough at C to be able to port sooperlooper to dssi~, since Om has eveyrhting else i'd need except a decent realtime-resampling audiofile module.. From Dr.Graef at t-online.de Thu Apr 6 17:46:15 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Apr 6 17:47:19 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144358867.12038.9.camel@mindpipe> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> Message-ID: <44358C27.3050307@t-online.de> Lee Revell wrote: > I heard from someone at Ableton that one guy wrote the Live engine in > about 3 months. He must be a great hacker. :) But the engine is probably only a small part of the program. Getting the UI right is an entirely different issue. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From rlrevell at joe-job.com Thu Apr 6 17:59:52 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 6 18:00:02 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060406214555.GD16853@replic.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> Message-ID: <1144360793.12038.15.camel@mindpipe> On Thu, 2006-04-06 at 21:45 +0000, carmen wrote: > > SC and Chuck: would likely work as well, but AFAIK neither one > supports LADSPA or DSSI at the moment, SCLang definitely doesnt work > on x86_64, and Chuck segfaulted as well but i'm guessing since its > newer it was designed with 64bit compatibility and mind and the crash > is some other issue > Apps really don't have to be designed with 64 bit compatibility in mind - it should be rather simple to port them. Rather than ruling out anything that doesn't work on AMD64 right now, I would advise you to first select a set of apps that work in 32 bit mode, then find out what it would take to port them. You might find that the CVS version supports AMD64, or that the developer just has not seen a demand yet (the vast majority of systems are still 32 bit). Or maybe the developer still has a 32 bit machine and has just never tried it. Lee From patrickkidd.lists at gmail.com Thu Apr 6 18:07:52 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Thu Apr 6 18:08:00 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060406214555.GD16853@replic.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> Message-ID: <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> Nice work with that screenshot. The hard part is finding an engine that appears light-weight to the application code. The engine has to never xrun, and allow me to make calls like sound.set_tempo(140.0), sound.start_on_beat(2345), and channel.set_volume(.678) without worrying about threads. Considering how many people want to learn a graphical kit and write audio apps, these requirements seem only natural. I've been trying to put the pksampler(.sf.net) together for a long time and have always stumbled on the engine; and every time its the communication mecahnism. I can re-write Ableton Live with qt, and even make it fast in python (which escapes the linux-only concept, mind you :)) - that's not hard. What is hard is finding an engine that lets me focus on my GUI as opposed to the engine or *anything* related to communicating with the engine (besides the above calls, of course). Yes, I'm being picky. I think I've thrown away enough C,C++, and now python code to be picky. I'm still sifting through the suggestions above, most I have seen, some I have not. BTW, I write for touchscreens, so I want an Ableton Live with big freakin widgets! On 4/6/06, carmen wrote: > > I heard from someone at Ableton that one guy wrote the Live engine in > > about 3 months. > > yeah its not that complex. all you need is something that can play audio files realtime at varying pitches/speeds and apply FX chains, and a GUI to facilitate the arrangement and FX parameterization.. > > i was able to whip up a LIVE-esque timeline GUI in an afternoon using the Tk wavesurfer library: http://whats-your.name/pr/seq.png but have yet to find the optimal backend. heres my investigations so far: > > PD and xsample~/dssi~: has the raw materials, but unfortunately doesnt work on amd64, and it its lack of subpatch polyphony means you would have to preallocate a set limit of active channels..and even a bit of disk access to load soundfiles is enough to get it kicked out of the jack graph due to its utter nonthreadedness.. > > SC and Chuck: would likely work as well, but AFAIK neither one supports LADSPA or DSSI at the moment, SCLang definitely doesnt work on x86_64, and Chuck segfaulted as well but i'm guessing since its newer it was designed with 64bit compatibility and mind and the crash is some other issue > > SooperLooper + OSC-aware LADSPA Rack and Jack Patcher: seems like the jack graph would get crazy quick, but i will probably try this next, since the above options are out for me at the moment unless i setup a 32bit chroot, but maybe i will get good enough at C to be able to port sooperlooper to dssi~, since Om has eveyrhting else i'd need except a decent realtime-resampling audiofile module.. > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From rlrevell at joe-job.com Thu Apr 6 18:17:17 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 6 18:17:28 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> Message-ID: <1144361838.12038.18.camel@mindpipe> On Thu, 2006-04-06 at 14:07 -0800, Patrick Stinson wrote: > > BTW, I write for touchscreens, so I want an Ableton Live with big > freakin widgets! Man, would it ever revolutionize live computer audio if touchscreens become cheap... Lee From Jan.Weil at web.de Fri Apr 7 04:44:10 2006 From: Jan.Weil at web.de (Jan Weil) Date: Fri Apr 7 04:44:22 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <20060406185229.GB4748@linux-1> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <1144348112.6757.16.camel@localhost> <20060406185229.GB4748@linux-1> Message-ID: <1144399450.4889.36.camel@localhost.localdomain> Am Donnerstag, den 06.04.2006, 20:52 +0200 schrieb fons adriaensen: > On Thu, Apr 06, 2006 at 08:28:32PM +0200, Jan Weil wrote: > > > 206.805 > > > > This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y, > > jackd 0.100.7, 2x64@48000. > > > > Now what does that value tell me? These are samples, I suppose, i. e. > > 4.308 msec? > > Yep, it's samples. > > > Fons, how do you think about a little accompanying README? :) > > Good idea :-) This was written and released in a hurry... > Or maby I should just add 'frames' to the printed value. Well, now that it's found its way to the LAD archives... just for the sake of googleability I'll add that we're talking about jdelay here which is used to measure the latency of your sound card. From Jan.Weil at web.de Fri Apr 7 04:48:47 2006 From: Jan.Weil at web.de (Jan Weil) Date: Fri Apr 7 04:48:54 2006 Subject: [linux-audio-dev] debugging xruns In-Reply-To: <20060406185229.GB4748@linux-1> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <1144348112.6757.16.camel@localhost> <20060406185229.GB4748@linux-1> Message-ID: <1144399728.4889.38.camel@localhost.localdomain> Am Donnerstag, den 06.04.2006, 20:52 +0200 schrieb fons adriaensen: > On Thu, Apr 06, 2006 at 08:28:32PM +0200, Jan Weil wrote: > > This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y, > > jackd 0.100.7, 2x64@48000. > Have you been able to use -p 64 with 2.6.16 on the Thinkpad with ACPI ? > I had no problems with it on my R51 when using 2.6.8 (SuSE 9.2), but > since 2.6.13 (SuSE 10.0) I have to disable it. Killing the modules doesn't > help, but acpi=off on the kernel command line does. Same with 2.6.15-rt. > APM doesn't seem to do any harm, so that's what I use now. I wonder if > the new dbus things are causing this. Yes, ACPI is enabled and running ardour the system is rock solid, no xruns at all (which is great!). I still have problems running other apps, though, e. g. freewheeling. After a couple of minutes xruns start occuring on a regular basis. Disabling ACPI didn't help, neither did -rt10. Unfortunately, I suspect these xruns being caused by the hdsp module sharing its interrupt with several others including eth0 and ATIs binary-only fglrx which I'm currently forced to use because xorg refuses to start otherwise. Additionally, -rt10 somehow made my system appear slugghish, e. g. booting takes significantly longer. I guess that's not what it's supposed to do. I'm still tweaking the whole system. Maybe Lee & Co. can lead me through the debugging process. How can I find out what causes these xruns? [And yes, I'm trying hard to get rid of fglrx. ;-)] Jan From list at phasorlab.de Fri Apr 7 05:27:20 2006 From: list at phasorlab.de (Matthias Koenig) Date: Fri Apr 7 05:27:41 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <44358C27.3050307@t-online.de> Message-ID: <87r749n3bb.fsf@zebra.localdomain> Albert Graef writes: > Lee Revell wrote: >> I heard from someone at Ableton that one guy wrote the Live engine in >> about 3 months. > > He must be a great hacker. :) But the engine is probably only a small > part of the program. Getting the UI right is an entirely different > issue. True, and don't forget that the one of the Ableton founders and the main developer have already been involved in Native Instruments Reactor engine. So there has been lots of experience accumulated in this context. For now, most of the stuff on their to do list is mainly GUI related (the engine is just working, they told me in a job interview). Matthias From list at phasorlab.de Fri Apr 7 05:28:24 2006 From: list at phasorlab.de (Matthias Koenig) Date: Fri Apr 7 05:29:10 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <1144353276.2866.109.camel@mindpipe> Message-ID: <87k6a1n39j.fsf@zebra.localdomain> Lee Revell writes: > And, I don't think it's fair to call it McMusic - all I use Live for is > an effects host for my guitar, because I like the builtin effects and it > has by far the best interface of any audio app. Ack. The reason why Live has so much success is simply that the traditional sequencer interface is missing some very important point. The traditional interface assumes you already know what you want to do, there is no room for improvisation and testing. If you want to compose something, it is good to have some scratch paper close to you. Thats why the success of Live is justified and has nothing to do with "McMusic". Matthias From dsbaikov at gmail.com Fri Apr 7 06:18:08 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Fri Apr 7 06:18:18 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> Message-ID: <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> > I can re-write Ableton Live with qt, and even > make it fast in python (which escapes the linux-only concept, mind you > :)) - that's not hard. What is hard is finding an engine that lets me > focus on my GUI as opposed to the engine or *anything* related to > communicating with the engine (besides the above calls, of course). Wow! I'm thinking about something like Ableton Live (but I'm mostly interested in MIDI), and I hate writing GUIs. I tried to do some GUI stuff first as the most dull and complex(for me) part. But it's a pain. Since there are peolpe wanting to make GUI stuff (surprise!), I'm throwing this away and start working on the engine. Btw, Live leaves much to be desired. Different tempos for different tracks, for example. Dmitry. From david at olofson.net Fri Apr 7 06:24:24 2006 From: david at olofson.net (David Olofson) Date: Fri Apr 7 06:25:07 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144360793.12038.15.camel@mindpipe> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406214555.GD16853@replic.net> <1144360793.12038.15.camel@mindpipe> Message-ID: <200604071224.24359.david@olofson.net> On Thursday 06 April 2006 23:59, Lee Revell wrote: > On Thu, 2006-04-06 at 21:45 +0000, carmen wrote: > > > > SC and Chuck: would likely work as well, but AFAIK neither one > > supports LADSPA or DSSI at the moment, SCLang definitely doesnt > > work > > on x86_64, and Chuck segfaulted as well but i'm guessing since its > > newer it was designed with 64bit compatibility and mind and the > > crash is some other issue > > > > Apps really don't have to be designed with 64 bit compatibility in > mind > - it should be rather simple to port them. Rather than ruling out > anything that doesn't work on AMD64 right now, I would advise you to > first select a set of apps that work in 32 bit mode, then find out > what it would take to port them. > > You might find that the CVS version supports AMD64, or that the > developer just has not seen a demand yet (the vast majority of > systems > are still 32 bit). Or maybe the developer still has a 32 bit > machine and has just never tried it. Indeed. I've been working on native AMD64 (Gentoo) for almost a year, and even though I spent most of my time hacking code for embedded 32 bit systems, I compile and test all code as native 64 bit as well. The only real problem I can remember having was with the heap relocation in EEL, where some messy pointer arithmetics is needed. Other than that, I'm using the exact same source code for 32 bit and 64 bit targets; no special cases or anything. Basically, just don't assume that a pointer is 32 bits, and you're fine. (That is, unless your programming style includes various inherently non-portable tricks. :-) Even in "naturally aligned" structs, you can usually get away with placing the pointers before any potentially smaller fields. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From drobilla at connect.carleton.ca Fri Apr 7 13:40:35 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Apr 7 13:40:40 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060406214555.GD16853@replic.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> Message-ID: <1144431635.30095.1.camel@localhost.localdomain> On Thu, 2006-06-04 at 21:45 +0000, carmen wrote: > > I heard from someone at Ableton that one guy wrote the Live engine > in > > about 3 months. > > yeah its not that complex. all you need is something that can play > audio files realtime at varying pitches/speeds and apply FX chains, > and a GUI to facilitate the arrangement and FX parameterization.. [snip] > SooperLooper + OSC-aware LADSPA Rack and Jack Patcher: seems like the > jack graph would get crazy quick, but i will probably try this next, > since the above options are out for me at the moment unless i setup a > 32bit chroot, but maybe i will get good enough at C to be able to port > sooperlooper to dssi~, since Om has eveyrhting else i'd need except a > decent realtime-resampling audiofile module.. I've been toying with the idea of adding support for gstreamer sources... -DR- From drobilla at connect.carleton.ca Fri Apr 7 13:43:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Apr 7 13:43:20 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144360793.12038.15.camel@mindpipe> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <1144360793.12038.15.camel@mindpipe> Message-ID: <1144431794.30095.3.camel@localhost.localdomain> On Thu, 2006-06-04 at 17:59 -0400, Lee Revell wrote: > On Thu, 2006-04-06 at 21:45 +0000, carmen wrote: > > > > SC and Chuck: would likely work as well, but AFAIK neither one > > supports LADSPA or DSSI at the moment, SCLang definitely doesnt work > > on x86_64, and Chuck segfaulted as well but i'm guessing since its > > newer it was designed with 64bit compatibility and mind and the crash > > is some other issue > > > > Apps really don't have to be designed with 64 bit compatibility in mind > - it should be rather simple to port them. You'd be surprised at the shit people come up with ;) -Wall should not be optional.... -DR- From torbenh at gmx.de Fri Apr 7 13:41:22 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri Apr 7 13:45:24 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060406214555.GD16853@replic.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> Message-ID: <20060407174122.GA8082@mobilat> On Thu, Apr 06, 2006 at 09:45:55PM +0000, carmen wrote: > > I heard from someone at Ableton that one guy wrote the Live engine in > > about 3 months. > > yeah its not that complex. all you need is something that can play audio files realtime at varying pitches/speeds and apply FX chains, and a GUI to facilitate the arrangement and FX parameterization.. uh ? this sound like libardour to me... you forgot the midi stuff, which is not yet in ardours engine... > > i was able to whip up a LIVE-esque timeline GUI in an afternoon using the Tk wavesurfer library: http://whats-your.name/pr/seq.png but have yet to find the optimal backend. heres my investigations so far: > > PD and xsample~/dssi~: has the raw materials, but unfortunately doesnt work on amd64, and it its lack of subpatch polyphony means you would have to preallocate a set limit of active channels..and even a bit of disk access to load soundfiles is enough to get it kicked out of the jack graph due to its utter nonthreadedness.. > > SC and Chuck: would likely work as well, but AFAIK neither one supports LADSPA or DSSI at the moment, SCLang definitely doesnt work on x86_64, and Chuck segfaulted as well but i'm guessing since its newer it was designed with 64bit compatibility and mind and the crash is some other issue > > SooperLooper + OSC-aware LADSPA Rack and Jack Patcher: seems like the jack graph would get crazy quick, but i will probably try this next, since the above options are out for me at the moment unless i setup a 32bit chroot, but maybe i will get good enough at C to be able to port sooperlooper to dssi~, since Om has eveyrhting else i'd need except a decent realtime-resampling audiofile module.. > what about om ? -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From torbenh at gmx.de Fri Apr 7 13:44:30 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri Apr 7 13:48:31 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <200604071224.24359.david@olofson.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406214555.GD16853@replic.net> <1144360793.12038.15.camel@mindpipe> <200604071224.24359.david@olofson.net> Message-ID: <20060407174430.GB8082@mobilat> On Fri, Apr 07, 2006 at 12:24:24PM +0200, David Olofson wrote: > On Thursday 06 April 2006 23:59, Lee Revell wrote: > > On Thu, 2006-04-06 at 21:45 +0000, carmen wrote: > > > > > > SC and Chuck: would likely work as well, but AFAIK neither one > > > supports LADSPA or DSSI at the moment, SCLang definitely doesnt > > > work > > > on x86_64, and Chuck segfaulted as well but i'm guessing since its > > > newer it was designed with 64bit compatibility and mind and the > > > crash is some other issue > > > > > > > Apps really don't have to be designed with 64 bit compatibility in > > mind > > - it should be rather simple to port them. Rather than ruling out > > anything that doesn't work on AMD64 right now, I would advise you to > > first select a set of apps that work in 32 bit mode, then find out > > what it would take to port them. > > > > You might find that the CVS version supports AMD64, or that the > > developer just has not seen a demand yet (the vast majority of > > systems > > are still 32 bit). Or maybe the developer still has a 32 bit > > machine and has just never tried it. > > Indeed. I've been working on native AMD64 (Gentoo) for almost a year, > and even though I spent most of my time hacking code for embedded 32 > bit systems, I compile and test all code as native 64 bit as well. > > The only real problem I can remember having was with the heap > relocation in EEL, where some messy pointer arithmetics is needed. > Other than that, I'm using the exact same source code for 32 bit and > 64 bit targets; no special cases or anything. > > Basically, just don't assume that a pointer is 32 bits, and you're but those bytecode interpreters of pd and such just assume, that int and pointer are the same size... well... perhaps it would work ok, if the integer was changed to int64 also... dont ask me. i did not look at the code... > fine. (That is, unless your programming style includes various > inherently non-portable tricks. :-) Even in "naturally aligned" > structs, you can usually get away with placing the pointers before > any potentially smaller fields. > > > //David Olofson - Programmer, Composer, Open Source Advocate > > .------- http://olofson.net - Games, SDL examples -------. > | http://zeespace.net - 2.5D rendering engine | > | http://audiality.org - Music/audio engine | > | http://eel.olofson.net - Real time scripting | > '-- http://www.reologica.se - Rheology instrumentation --' > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From patrickkidd.lists at gmail.com Fri Apr 7 15:11:30 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Fri Apr 7 15:11:38 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> Message-ID: <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> What are you working on, if I may pry? On 4/7/06, Dmitry Baikov wrote: > > I can re-write Ableton Live with qt, and even > > make it fast in python (which escapes the linux-only concept, mind you > > :)) - that's not hard. What is hard is finding an engine that lets me > > focus on my GUI as opposed to the engine or *anything* related to > > communicating with the engine (besides the above calls, of course). > > Wow! I'm thinking about something like Ableton Live (but I'm mostly > interested in MIDI), > and I hate writing GUIs. > I tried to do some GUI stuff first as the most dull and complex(for > me) part. But it's a pain. > Since there are peolpe wanting to make GUI stuff (surprise!), I'm > throwing this away and start working on the engine. > > Btw, Live leaves much to be desired. Different tempos for different > tracks, for example. > > Dmitry. > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From dsbaikov at gmail.com Fri Apr 7 15:21:26 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Fri Apr 7 15:21:48 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> Message-ID: <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> On 4/7/06, Patrick Stinson wrote: > What are you working on, if I may pry? In short, smth like Ableton Live, but with support for several tempos and subclips (i.e. clips with complex structure, not just looped wav/midi piece). Can't call it "working" since I have only few hacks and smth like design-document. From rlrevell at joe-job.com Fri Apr 7 15:29:37 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Apr 7 15:29:42 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144431794.30095.3.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <1144360793.12038.15.camel@mindpipe> <1144431794.30095.3.camel@localhost.localdomain> Message-ID: <1144438177.22490.85.camel@mindpipe> On Fri, 2006-04-07 at 13:43 -0400, Dave Robillard wrote: > > Apps really don't have to be designed with 64 bit compatibility in mind > > - it should be rather simple to port them. > > You'd be surprised at the shit people come up with ;) > > -Wall should not be optional.... http://www.thedailywtf.com/ Lee From Dr.Graef at t-online.de Fri Apr 7 17:22:48 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Fri Apr 7 17:22:52 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144431635.30095.1.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <1144431635.30095.1.camel@localhost.localdomain> Message-ID: <4436D828.8050305@t-online.de> Dave Robillard wrote: > I've been toying with the idea of adding support for gstreamer > sources... I also have a Q module for gstreamer on my TODO list (more geared towards video playback and editing, though). Has anyone tried gstreamer lately? Is it usable? Does the API still change a lot? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From david at olofson.net Fri Apr 7 18:01:46 2006 From: david at olofson.net (David Olofson) Date: Fri Apr 7 18:02:28 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060407174430.GB8082@mobilat> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <200604071224.24359.david@olofson.net> <20060407174430.GB8082@mobilat> Message-ID: <200604080001.46482.david@olofson.net> On Friday 07 April 2006 19:44, torbenh@gmx.de wrote: [...] > > Basically, just don't assume that a pointer is 32 bits, and you're > > but those bytecode interpreters of pd and such just assume, that int > and pointer are the same size... Yeah, it's tempting to do it that way... I'm not doing any of that in EEL though, and that's using a byte code VM too. It definitely helps to have portability in mind all the way from the design stage, especially with that kind of code. (Inherently messy, in a way...) > well... perhaps it would work ok, if the integer was changed to > int64 also... > > dont ask me. i did not look at the code... Are they using computed gotos or similar, or is this a struct/union problem? Either way, I can't see why it couldn't be fixed, but I can see a few design styles that would require some 32/64 #ifdefs. Could be a bit hairy to track all spots down if the pointer size is implicitly built into the code. (Something I try to avoid in general. You never know when, why or what you might want to change down the road.) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From patrickkidd.lists at gmail.com Fri Apr 7 18:23:00 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Fri Apr 7 18:23:04 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> Message-ID: <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> As an added note to my previous comments, I really like the app interface that mpd uses. Writing ascii events using some spec or another to a file descriptor (socket in mpd's case) seems to be a terrific way to communicated with apps and libs. I run the svn pksampler like this: pksampler | pkaudiod I could just as easily have either use a socket or some other pipe, and this is easy to debug, script, profile, etc. On the client and server sides, I wrap my 10-minute rpc into an interface with generic calls. Everything having to do with input (MIDI, OSC, whatever) happens in the app code. The interface functions resemble those of FMODEx's interface; add sample, connect to channel, set sample attrs, etc. As an interface designer, the first thing I look for on an engine's project site is some sort of asynchronous API - I should never concern myself with anything outside referencing the api from my app's one windowing thread. FMOD, gstreamer, and my dead pkaudio project do this very well. I don't ever want to worry about what thread it happens in, what threads it will affect, or what the performance effects of *making* the call will be (as opposed to residual effects). This is why I like $ interface | engine > engine.log On 4/7/06, Dmitry Baikov wrote: > On 4/7/06, Patrick Stinson wrote: > > What are you working on, if I may pry? > > In short, smth like Ableton Live, but with support for several tempos > and subclips (i.e. clips with complex structure, not just looped > wav/midi piece). > Can't call it "working" since I have only few hacks and smth like > design-document. > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From ix at replic.net Fri Apr 7 23:04:19 2006 From: ix at replic.net (carmen) Date: Fri Apr 7 23:04:22 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <4436D828.8050305@t-online.de> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <1144431635.30095.1.camel@localhost.localdomain> <4436D828.8050305@t-online.de> Message-ID: <20060408030419.GB20524@replic.net> On Fri Apr 07, 2006 at 11:22:48PM +0200, Albert Graef wrote: > Dave Robillard wrote: > >I've been toying with the idea of adding support for gstreamer > >sources... > > I also have a Q module for gstreamer on my TODO list (more geared > towards video playback and editing, though). Has anyone tried gstreamer > lately? Is it usable? Does the API still change a lot? its definitely the first point of failure, be it some weird pipe issue, refusing to playback at all, buffering problems, file-metainfo-chokage, etc. in any audio app ive tried that users it (well mainly banshee, rhythmbox, bmpx, and amarok). im not alone (and my comrades have different reasons): http://lwn.net/Articles/178336/ what advantage does it serve other than insulating yourself against the external API (ALSA dying in 6 months? i think not..) > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de > WWW: http://www.musikinformatik.uni-mainz.de/ag From torbenh at gmx.de Fri Apr 7 23:07:29 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri Apr 7 23:11:36 2006 Subject: [linux-audio-dev] [ANN] netjack-0.11rc5 Message-ID: <20060408030728.GA8258@mobilat> netjack-0.11rc5 Some pieces of Code which can deliver you the full jackd experience with multiple Computers. Links JackPorts via generic IP networks. The alsa_in and alsa_out client can connect jackd to an unrelated alsa Soundcard. And their algorithm has been improved. Also downsampling and bitrate reduction is included now, to make it work on low bitrate links. Tested over the Internet some times now, with moderate success. Also compiles on OSX... with-alsa=0 -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From paul at linuxaudiosystems.com Fri Apr 7 23:26:54 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Apr 7 23:23:05 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> Message-ID: <1144466814.5040.16.camel@localhost.localdomain> On Fri, 2006-04-07 at 14:23 -0800, Patrick Stinson wrote: > As an added note to my previous comments, I really like the app > interface that mpd uses. Writing ascii events using some spec or > another to a file descriptor (socket in mpd's case) seems to be a > terrific way to communicated with apps and libs. I run the svn > pksampler like this: > > pksampler | pkaudiod > > I could just as easily have either use a socket or some other pipe, > and this is easy to debug, script, profile, etc. On the client and > server sides, I wrap my 10-minute rpc into an interface with generic > calls. Everything having to do with input (MIDI, OSC, whatever) > happens in the app code. The interface functions resemble those of > FMODEx's interface; add sample, connect to channel, set sample attrs, > etc. > > As an interface designer, the first thing I look for on an engine's > project site is some sort of asynchronous API - I should never concern > myself with anything outside referencing the api from my app's one > windowing thread. FMOD, gstreamer, and my dead pkaudio project do this > very well. I don't ever want to worry about what thread it happens in, > what threads it will affect, or what the performance effects of > *making* the call will be (as opposed to residual effects). although i agree that this is the right design for many classes of application design, i would like to see how you propose to tackle metering and waveform display (the two most difficult examples). ardour would be relatively easy to separate into interface+engine processes (as opposed to just a lib/lib-client separation) if it were not for these issues. moving waveform and metering data back and forth between two processes via a wire protocol is very expensive and inefficient. --p From rlrevell at joe-job.com Fri Apr 7 23:28:35 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Apr 7 23:28:44 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060408030419.GB20524@replic.net> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <1144431635.30095.1.camel@localhost.localdomain> <4436D828.8050305@t-online.de> <20060408030419.GB20524@replic.net> Message-ID: <1144466916.22490.130.camel@mindpipe> On Sat, 2006-04-08 at 03:04 +0000, carmen wrote: > > what advantage does it serve other than insulating yourself against > the external API (ALSA dying in 6 months? i think not..) > I found this very interesting: http://lurkertech.com/linuxvideoio.html It seems as if ALSA+JACK does exactly what this SGI engineer recommends ("just give me the data!") while gstreamer does the opposite... Lee From patrickkidd.lists at gmail.com Sat Apr 8 00:05:53 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Sat Apr 8 00:05:57 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144466814.5040.16.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> <1144466814.5040.16.camel@localhost.localdomain> Message-ID: <664bf2b80604072105j2ee75444vec070cd15602aae8@mail.gmail.com> On 4/7/06, Paul Davis wrote: > On Fri, 2006-04-07 at 14:23 -0800, Patrick Stinson wrote: > > As an added note to my previous comments, I really like the app > > interface that mpd uses. Writing ascii events using some spec or > > another to a file descriptor (socket in mpd's case) seems to be a > > terrific way to communicated with apps and libs. I run the svn > > pksampler like this: > > > > pksampler | pkaudiod > > > > I could just as easily have either use a socket or some other pipe, > > and this is easy to debug, script, profile, etc. On the client and > > server sides, I wrap my 10-minute rpc into an interface with generic > > calls. Everything having to do with input (MIDI, OSC, whatever) > > happens in the app code. The interface functions resemble those of > > FMODEx's interface; add sample, connect to channel, set sample attrs, > > etc. > > > > As an interface designer, the first thing I look for on an engine's > > project site is some sort of asynchronous API - I should never concern > > myself with anything outside referencing the api from my app's one > > windowing thread. FMOD, gstreamer, and my dead pkaudio project do this > > very well. I don't ever want to worry about what thread it happens in, > > what threads it will affect, or what the performance effects of > > *making* the call will be (as opposed to residual effects). > > although i agree that this is the right design for many classes of > application design, i would like to see how you propose to tackle > metering and waveform display (the two most difficult examples). > ardour would be relatively easy to separate into interface+engine > processes (as opposed to just a lib/lib-client separation) if it were > not for these issues. moving waveform and metering data back and forth > between two processes via a wire protocol is very expensive and > inefficient. > > --p > > > Yes, that's always the first hangup, isn't it! Everyone want's those cool r,p,d meters, and they want them to be *fast*, don't they? I am doing my best to keep my app out of the realm of needing that sort of shared data to keep the app/engine as simple as possible. Your comment is correct, and I can only agree that there is a fine line between needing cool levels and not. -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From musical_snake at gmx.de Sat Apr 8 08:28:19 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Sat Apr 8 08:33:54 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144466814.5040.16.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> <1144466814.5040.16.camel@localhost.localdomain> Message-ID: <4437AC63.6030005@gmx.de> Paul Davis schrieb: > although i agree that this is the right design for many classes of > >application design, i would like to see how you propose to tackle >metering and waveform display (the two most difficult examples). >ardour would be relatively easy to separate into interface+engine >processes (as opposed to just a lib/lib-client separation) if it were >not for these issues. moving waveform and metering data back and forth >between two processes via a wire protocol is very expensive and >inefficient. > >--p > > > The key here is to reduce the data to be displayed to what the GUI actually needs. Example: metering You can send every rms + peak at 32 float at 44.1kHz, requiring 4 * 2* 44100 Bytes/sec per track or send the peak and the RMS reduced to 8-Bit resolution at a rate of 25Hz => 50 Bytes/sec per track The latter will satisfy even people running a display at 1280x1024 with the full vertical resolution dedicated to the meters. 4 Bit displayed resolution isn't that noticable, nor is the 25Hz update rate. Example: waveform Let the GUI send a request with startposition, endposition, length + required resolution and return only the requested data. Suppose you have a 10sec wave you want to display from second 4 to second 6, using a canvas of 256 * 1024 pixels, your engine only needs to send 1024 bytes. Actually, i consider any realtime application, which does not separated rt part and gui into different processes, a bad design. Not to mention that this separation allows to run several rt engines in a single process thread and have each of them communicate to their guis, independent of what toolkits the guis are based on and whether or not these guis run on completely different machines/architectures. Ralf From James at superbug.co.uk Sat Apr 8 12:17:14 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Apr 8 12:17:19 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. Message-ID: <4437E20A.2050104@superbug.co.uk> Hi, Are there any linux tools out there that will sample the line in, and display a detailed spectrum scope of the detected sound? E.g. http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif Eventually I wish to send a test signal from one sound card to another and compare the frequency response/noise etc. of the line input of the card. James From a at gaydenko.com Sat Apr 8 12:31:21 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sat Apr 8 12:32:30 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: <4437E20A.2050104@superbug.co.uk> References: <4437E20A.2050104@superbug.co.uk> Message-ID: <200604082031.21173@goldspace.net> jaaa: http://users.skynet.be/solaris/linuxaudio/ I use it for my audio-DIY-ing. ======= On Saturday 08 April 2006 20:17, James Courtier-Dutton wrote: ======= Hi, Are there any linux tools out there that will sample the line in, and display a detailed spectrum scope of the detected sound? E.g. http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif Eventually I wish to send a test signal from one sound card to another and compare the frequency response/noise etc. of the line input of the card. James From fons.adriaensen at skynet.be Sat Apr 8 12:44:44 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Apr 8 12:37:30 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: <4437E20A.2050104@superbug.co.uk> References: <4437E20A.2050104@superbug.co.uk> Message-ID: <20060408164444.GD5084@linux-1> On Sat, Apr 08, 2006 at 05:17:14PM +0100, James Courtier-Dutton wrote: > Hi, > > Are there any linux tools out there that will sample the line in, and > display a detailed spectrum scope of the detected sound? > > E.g. > http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif > > Eventually I wish to send a test signal from one sound card to another > and compare the frequency response/noise etc. of the line input of the card. For 'technical' measurements: JAAA For 'musical' measurements: JAPA Both at The JAAA release is quite old now and shows it. Improved looks version soon. Don't forget the shared libs at the bottom of the page. -- FA Follie! Follie! Delirio vano e' questo! From James at superbug.co.uk Sat Apr 8 15:09:49 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Apr 8 15:09:55 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: <20060408164444.GD5084@linux-1> References: <4437E20A.2050104@superbug.co.uk> <20060408164444.GD5084@linux-1> Message-ID: <44380A7D.2080104@superbug.co.uk> fons adriaensen wrote: > On Sat, Apr 08, 2006 at 05:17:14PM +0100, James Courtier-Dutton wrote: >> Hi, >> >> Are there any linux tools out there that will sample the line in, and >> display a detailed spectrum scope of the detected sound? >> >> E.g. >> http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif >> >> Eventually I wish to send a test signal from one sound card to another >> and compare the frequency response/noise etc. of the line input of the card. > > For 'technical' measurements: JAAA > For 'musical' measurements: JAPA > > Both at > > The JAAA release is quite old now and shows it. Improved looks version soon. > Don't forget the shared libs at the bottom of the page. > Neither of those applications work. I have ardour working fine with stereo in/stereo out. jaaa -J seems to talk to jack, but does not capture or play any sound. jaaa -A fails to even open the alsa device. jdelay also does not work. Responding with "Signal below threshold..." Have these application actually been tested with jackd recently? James From James at superbug.co.uk Sat Apr 8 15:33:31 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Apr 8 15:33:36 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: <44380A7D.2080104@superbug.co.uk> References: <4437E20A.2050104@superbug.co.uk> <20060408164444.GD5084@linux-1> <44380A7D.2080104@superbug.co.uk> Message-ID: <4438100B.8080907@superbug.co.uk> James Courtier-Dutton wrote: > fons adriaensen wrote: >> On Sat, Apr 08, 2006 at 05:17:14PM +0100, James Courtier-Dutton wrote: >>> Hi, >>> >>> Are there any linux tools out there that will sample the line in, and >>> display a detailed spectrum scope of the detected sound? >>> >>> E.g. >>> http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif >>> >>> Eventually I wish to send a test signal from one sound card to >>> another and compare the frequency response/noise etc. of the line >>> input of the card. >> >> For 'technical' measurements: JAAA >> For 'musical' measurements: JAPA >> >> Both at >> >> The JAAA release is quite old now and shows it. Improved looks version >> soon. >> Don't forget the shared libs at the bottom of the page. >> > > Neither of those applications work. > I have ardour working fine with stereo in/stereo out. > > jaaa -J seems to talk to jack, but does not capture or play any sound. > jaaa -A fails to even open the alsa device. > > jdelay also does not work. Responding with "Signal below threshold..." > > Have these application actually been tested with jackd recently? > > James > > My mistake. Please ignore. From fons.adriaensen at skynet.be Sat Apr 8 15:41:06 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Apr 8 15:34:04 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: <44380A7D.2080104@superbug.co.uk> References: <4437E20A.2050104@superbug.co.uk> <20060408164444.GD5084@linux-1> <44380A7D.2080104@superbug.co.uk> Message-ID: <20060408194106.GE5084@linux-1> On Sat, Apr 08, 2006 at 08:09:49PM +0100, James Courtier-Dutton wrote: > Neither of those applications work. > I have ardour working fine with stereo in/stereo out. > > jaaa -J seems to talk to jack, but does not capture or play any sound. > jaaa -A fails to even open the alsa device. > > Have these application actually been tested with jackd recently? I've been using jaaa most of this afternoon. It's some time since I used the official release (development goes on) but nothing has been changed in the ALSA / JACK interfaces for as long as I can remember. There should be some messages printed in the terminal where you start jaaa... > jdelay also does not work. Responding with "Signal below threshold..." Which normally means it doesn't see any enough of its output back on the input. And it doesn't need much. You *have* to connect it... -- FA Follie! Follie! Delirio vano e' questo! From patrickkidd.lists at gmail.com Sat Apr 8 16:58:22 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Sat Apr 8 16:58:29 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144338496.2866.60.camel@mindpipe> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> Message-ID: <664bf2b80604081358s34bd3aa9n40493a25fb9b54f8@mail.gmail.com> Freewheeling looks pretty good, except it's more designed to take the place of a more standard pedal-controlled loop machine. I don't really want to just record myself live, but I want to play pre-recorded samples and midi sequences, much like you would if you had a ton of dj decks lying around, and got them all to fit in a touchscreen. Plus, I want the engine so I can write my own app. On 4/6/06, Lee Revell wrote: > On Thu, 2006-04-06 at 04:14 -0800, Patrick Stinson wrote: > > I've been looking for a high-performance music engine. It must have an > > asynchronous control (socket, pipe?) mechanism to seperate the > > application from the audio thread. > > > > I'm looking for: > > > > start/stop samples on the beat > > scaled tempo control across all samples > > volume > > effects? > > easily wrappable (I'll write extensions, implement protocol > > plugins...) with python > > > > I'm trying to write something like ableton live without writing an > > engine all over again. FMODex would be *perfect* if it had a > > well-defined tempo/beat/sync interface. > > > > I think FreeWheeling might be the closest thing to Live that exists for > Linux, have you looked at it? > > Lee > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From patrickkidd.lists at gmail.com Sat Apr 8 17:06:53 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Sat Apr 8 17:07:09 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <87ek0ae51v.fsf@esben-stien.name> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <87ek0ae51v.fsf@esben-stien.name> Message-ID: <664bf2b80604081406w4ef1db8bg7e069f268606c411@mail.gmail.com> On 4/6/06, Esben Stien wrote: > "Patrick Stinson" writes: > > > music engine > > SuperCollider[1] > > [1]http://www.audiosynth.com/ > > -- > Esben Stien is b0ef@e s a > http://www. s t n m > irc://irc. b - i . e/%23contact > [sip|iax]: e e > jid:b0ef@ n n > The last time I looked into supercollider, I was turned on by qualities like "mature", "reliable", "interface", and "music". I also recall quickly becoming confused by having to put together networks and stuff like that, not finding instructions to do so, and the whole model sounding rather static, as opposed to incredibly dynamic and unpredictable, which is what I'm trying to do. I found the same prejudice with CSound and orchestra files. I hope, and am somewhat certain, that my prejudices are founded on ignorance. Yes? No? > Steve McConville to paul, A > More options Apr 6 (2 days ago) > Have you already considered Csound5 (with the new API and python > bindings)? And if so, what is it lacking for your needs? I found the same problem with CSound5. comments? -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From alberto.botti at gmail.com Sun Apr 9 08:56:56 2006 From: alberto.botti at gmail.com (Alberto Botti) Date: Sun Apr 9 08:57:12 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <20060406200238.GA17901@riyal.ugcs.caltech.edu> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406162513.GA16158@riyal.ugcs.caltech.edu> <200604062226.49928.tito@rumford.de> <20060406200238.GA17901@riyal.ugcs.caltech.edu> Message-ID: <1144587417.11319.7.camel@localhost.localdomain> Il giorno gio, 06/04/2006 alle 13.02 -0700, Lance Blisters ha scritto: > Sorry, no release since then. I'm 90% certain that full JACK > support is in CVS already, if not then it'll be in within a > week as i'm planning a big cvs commit binge (purge?) of the > last month's developments. Unfortunately I have no plans > to release but do plan to keep CVS compileable and up to > date. Simply can't be done given my schedule. Great work, man! I assumed that the development of GDAM was stopped years ago... but I'm happy to be proved wrong. :) I've built GDAM from CVS multiple times since the last release, but I never have been able to make it work with JACK... I'll wait for the new improvements. Thanks for all the good work. > -geoff From alberto.botti at gmail.com Sun Apr 9 09:22:31 2006 From: alberto.botti at gmail.com (Alberto Botti) Date: Sun Apr 9 09:22:39 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144466916.22490.130.camel@mindpipe> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <1144431635.30095.1.camel@localhost.localdomain> <4436D828.8050305@t-online.de> <20060408030419.GB20524@replic.net> <1144466916.22490.130.camel@mindpipe> Message-ID: <1144588951.11319.25.camel@localhost.localdomain> Il giorno ven, 07/04/2006 alle 23.28 -0400, Lee Revell ha scritto: > On Sat, 2006-04-08 at 03:04 +0000, carmen wrote: > > > > what advantage does it serve other than insulating yourself against > > the external API (ALSA dying in 6 months? i think not..) > > > > I found this very interesting: > > http://lurkertech.com/linuxvideoio.html > > It seems as if ALSA+JACK does exactly what this SGI engineer recommends > ("just give me the data!") while gstreamer does the opposite... Well, I think than applications like Totem or Rhythmbox have different goals than professional audio apps... they don't need to know explicitly (nor want to code for special cases) about the properties of the data stream. They also (at least for Totem) need to deal with video, which is way more complex. But an audio processing engine *has* to deal with the raw samples. I'm writing a small audio server-client application, called FreeMix, which uses GStreamer as the input source (reading from files and decoding them into audio frames), then processing/mixing them and handling the results to JACK, in a RT-safe way. It's input layer is currently awaiting a rewrite for the new gst 0.10 API (and I really need to remove all the dirty hacks I've used...), but I don't have any time to work on it at the moment. In my testing the audio part of gstreamer (I used 0.8) worked pretty well on most formats (WAV, Ogg/Vorbis, MP3, FLAC, and some MODs...). I'll take a deeper look at 0.10, sooner or later. From radarsat1 at gmail.com Sun Apr 9 11:47:40 2006 From: radarsat1 at gmail.com (Steve) Date: Sun Apr 9 11:47:47 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144588951.11319.25.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406194052.GA16853@replic.net> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <1144431635.30095.1.camel@localhost.localdomain> <4436D828.8050305@t-online.de> <20060408030419.GB20524@replic.net> <1144466916.22490.130.camel@mindpipe> <1144588951.11319.25.camel@localhost.localdomain> Message-ID: <9b3e2dc20604090847o82ab86fpd0f330ab88392fbd@mail.gmail.com> Just to add my 2cents to this thread, I've been developing a live performance application for Linux which I have used in several shows. It's called LoopDub and is really just for mixing loops. So far it's not super user-friendly, but it does the job I designed it for. It allows to load 8 loops and then load other loops in the background, and switch between them on beat. It can be completely controlled via MIDI so I could conceivably just close my laptop and stick it under the desk when playing (except that I tend to forget which program is which, so I need the screen..) I intend to add more methods for modifying the sound live and whatnot. So far it just has some built-in filters and echo. The CVS version has several improvements, so watch for a new release soon. (I'm too busy with school at the moment to work on it but summer will see the next release for sure.) http://loopdub.sf.net Steve From hans at fugal.net Sun Apr 9 23:06:42 2006 From: hans at fugal.net (Hans Fugal) Date: Sun Apr 9 23:07:02 2006 Subject: [linux-audio-dev] Linux Audio Wiki on port 2500 no more Message-ID: <20060410030642.GA25949@falcon.fugal.net> The wiki that was at http://fugal.net:2500 is no longer there. It now has its own subdomain: http://lawiki.fugal.net I would be perfectly happy to entertain a more dedicated domain name, or more appropriate subdomain of an existing domain, if someone wants to foot the bill. If I can figure out how in a short amount of time, I'll put up a redirect at the old address. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060409/20adece3/attachment.bin From Cedric.Roux at eurecom.fr Mon Apr 10 04:58:34 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Mon Apr 10 04:58:41 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: <4437E20A.2050104@superbug.co.uk> Message-ID: On Sat, 8 Apr 2006, James Courtier-Dutton wrote: > Hi, > > Are there any linux tools out there that will sample the line in, and > display a detailed spectrum scope of the detected sound? > > E.g. > http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif > > Eventually I wish to send a test signal from one sound card to another > and compare the frequency response/noise etc. of the line input of the card. > > James what about baudline ? http://www.baudline.com/ (it's not free software) C?dric. From voidcreature at paradise.net.nz Mon Apr 10 05:03:57 2006 From: voidcreature at paradise.net.nz (voidcreature@paradise.net.nz) Date: Mon Apr 10 05:03:16 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: References: Message-ID: <200604102103.58441.voidcreature@paradise.net.nz> On Monday 10 April 2006 20:58, Cedric Roux wrote: > what about baudline ? http://www.baudline.com/ > (it's not free software) > > C=E9dric. does baudline support alsa yet? last time i checked it was OSS only, which= is=20 a great pity, because its otherwise a pretty neat tool. From arnold.krille at gmail.com Mon Apr 10 07:39:25 2006 From: arnold.krille at gmail.com (Arnold Krille) Date: Mon Apr 10 07:39:30 2006 Subject: [linux-audio-dev] Re: Measuring playback and capture quality. In-Reply-To: <20060408164444.GD5084@linux-1> References: <4437E20A.2050104@superbug.co.uk> <20060408164444.GD5084@linux-1> Message-ID: <2def88b80604100439u6ca9df1eu5a83a4e93e05178b@mail.gmail.com> 2006/4/8, fons adriaensen : > For 'technical' measurements: JAAA > For 'musical' measurements: JAPA > Both at > The JAAA release is quite old now and shows it. Improved looks version soon. Feature Request: Is there a way to add the sinus/noise generator to japa too? That way I only have to use one app to setup the PA... Arnold -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. From a at gaydenko.com Mon Apr 10 08:02:10 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Mon Apr 10 08:03:30 2006 Subject: [linux-audio-dev] Re: Measuring playback and capture quality. In-Reply-To: <2def88b80604100439u6ca9df1eu5a83a4e93e05178b@mail.gmail.com> References: <4437E20A.2050104@superbug.co.uk> <20060408164444.GD5084@linux-1> <2def88b80604100439u6ca9df1eu5a83a4e93e05178b@mail.gmail.com> Message-ID: <200604101602.10684@goldspace.net> BTW, you can start multiple 'jaaa' instances using '-name' option to define jaaa's JACK client name. ======= On Monday 10 April 2006 15:39, Arnold Krille wrote: ======= 2006/4/8, fons adriaensen : > For 'technical' measurements: JAAA > For 'musical' measurements: JAPA > Both at > The JAAA release is quite old now and shows it. Improved looks version soon. Feature Request: Is there a way to add the sinus/noise generator to japa too? That way I only have to use one app to setup the PA... Arnold -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. From julien at c-lab.de Mon Apr 10 09:11:49 2006 From: julien at c-lab.de (Julien Claassen) Date: Mon Apr 10 09:12:03 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? Message-ID: Hi all! I know it's completely OT, but I think there maybe people here, who could help me. Problem is: I'm still on my libcui (character user interface) project and I wonder: I push a button, slide a slider... How does the UI notify the program of this change? How do Engine and UI communicate? Please anyone: HELP ME! Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From dsbaikov at gmail.com Mon Apr 10 09:31:48 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Mon Apr 10 09:31:54 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: Message-ID: <70a871c80604100631t389534f0sa9996b2cad8ca114@mail.gmail.com> http://liblo.sourceforge.net/ From fons.adriaensen at alcatelaleniaspace.com Mon Apr 10 10:09:01 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Apr 10 10:09:15 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: Message-ID: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> On Mon, Apr 10, 2006 at 03:11:49PM +0200, Julien Claassen wrote: > Hi all! > I know it's completely OT, but I think there maybe people here, who could > help me. > Problem is: I'm still on my libcui (character user interface) project and I > wonder: > I push a button, slide a slider... How does the UI notify the program of > this change? How do Engine and UI communicate? > Please anyone: HELP ME! Hello Julien, This is a tricky subject, and most toolkits have their own peculiar methods of solving the problem. In general terms this needs callback functions - a function supplied as a creation parameter to the widget, and which it will call when it has something to report. In C this is quite easy to arrange. The widget is given a function pointer, and usually also a void* which becomes the first argument of the callback fucntion and points to any context the receiver wants to be available when called back. Other arguments depend on what the callback needs to report. In C++ you will want class function members to act as callbacks, and here things get complicated. Since callback functions are strongly typed and this type depends on the class they are in, there is no single variable type you can put into the widget to hold the function pointer. Three solutions: 1. All callbacks first go to a static class function which in most compilers have "C" semantics. So this requires two functions for each callback, the first static one which is seen by the widget as a plain C function, and which then calls the second one. In that case the void* mentioned above would point to the C++ object that receives the call, and the static callback casts it to the right class pointer type and then calls the class member function via that pointer. 2. Use templates. This is nicely encapsulated in GLib, part of GTK, which you can probably re-use (it doesn't depend on the graphical stuff AFAIK). 3. Define on or more callback classes, containing on or more virtual functions. All receiver classes inherit from this or these classses, and a pointer to this type is passed at creation time to each widget. This is what I use in libclxclient. Unless you want to do a lot of things yourself, I guess the GLib way will be the easiest, or else stick to plain C (complicating matters for C++ users, by forcing them to use the indirect callback method explained above). -- FA Follie! Follie! Delirio vano e' questo! From fons.adriaensen at alcatelaleniaspace.com Mon Apr 10 10:17:41 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Apr 10 10:17:48 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: Message-ID: <20060410141740.GD5917@bth05w.ABSp.alcatel.be> On Mon, Apr 10, 2006 at 03:11:49PM +0200, Julien Claassen wrote: > Hi all! > I know it's completely OT, but I think there maybe people here, who could > help me. > Problem is: I'm still on my libcui (character user interface) project and I > wonder: > I push a button, slide a slider... How does the UI notify the program of > this change? How do Engine and UI communicate? > Please anyone: HELP ME! Reading this again I may have misunderstood your question. The message I posted on callbacks relates to how widgets talk to the rest of the UI code. UI to engine is another matter, here I'd say OSC is the way to go as already pointed out by Dmitry. -- FA Follie! Follie! Delirio vano e' questo! From b0ef at esben-stien.name Mon Apr 10 12:23:13 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Mon Apr 10 10:35:21 2006 Subject: [linux-audio-dev] Measuring playback and capture quality. In-Reply-To: (Cedric Roux's message of "Mon, 10 Apr 2006 10:58:34 +0200 (CEST)") References: Message-ID: <87psjpxuvi.fsf@esben-stien.name> Cedric Roux writes: > baudline (it's not free software) I've been in contact with them a couple of times via email and their plan is to release it as free software. Hope it will be soon, cause I sure would like to try this app and see it JACK'ified;). -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From drobilla at connect.carleton.ca Mon Apr 10 12:26:19 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Apr 10 12:26:28 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> Message-ID: <1144686379.4394.1.camel@localhost.localdomain> On Mon, 2006-04-10 at 16:09 +0200, Alfons Adriaensen wrote: > On Mon, Apr 10, 2006 at 03:11:49PM +0200, Julien Claassen wrote: > > Hi all! > > I know it's completely OT, but I think there maybe people here, who could > > help me. > > Problem is: I'm still on my libcui (character user interface) project and I > > wonder: > > I push a button, slide a slider... How does the UI notify the program of > > this change? How do Engine and UI communicate? > > Please anyone: HELP ME! > > Hello Julien, > > This is a tricky subject, and most toolkits have their own peculiar > methods of solving the problem. > > In general terms this needs callback functions - a function supplied > as a creation parameter to the widget, and which it will call when > it has something to report. > > In C this is quite easy to arrange. The widget is given a function > pointer, and usually also a void* which becomes the first argument > of the callback fucntion and points to any context the receiver wants > to be available when called back. Other arguments depend on what the > callback needs to report. > > In C++ you will want class function members to act as callbacks, and > here things get complicated. Since callback functions are strongly > typed and this type depends on the class they are in, there is no single > variable type you can put into the widget to hold the function pointer. If you want this in C++, you definitely want to use libsigc++. (Keyword definitely) -DR- From paul at linuxaudiosystems.com Mon Apr 10 12:38:14 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Apr 10 12:34:25 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <1144686379.4394.1.camel@localhost.localdomain> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> Message-ID: <1144687094.10666.28.camel@localhost.localdomain> On Mon, 2006-04-10 at 12:26 -0400, Dave Robillard wrote: > If you want this in C++, you definitely want to use libsigc++. > > (Keyword definitely) actually, its worse than that. if you do this in C++ and you do not use libsigc++, then a team of ninja open source developers will enter your house overnight and eviscerate your internal organs. you cannot run, you cannot hide. please, don't take chances. use libsigc++ for the sake of your family and loved ones. --p From julien at c-lab.de Mon Apr 10 15:02:13 2006 From: julien at c-lab.de (Julien Claassen) Date: Mon Apr 10 15:02:25 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <1144687094.10666.28.camel@localhost.localdomain> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> Message-ID: In Apr 10 A.D. 2006 Paul Davis scripsit: > On Mon, 2006-04-10 at 12:26 -0400, Dave Robillard wrote: > > > If you want this in C++, you definitely want to use libsigc++. > > > > (Keyword definitely) > > actually, its worse than that. if you do this in C++ and you do not use > libsigc++, then a team of ninja open source developers will enter your > house overnight and eviscerate your internal organs. you cannot run, you > cannot hide. please, don't take chances. use libsigc++ for the sake of > your family and loved ones. > Well, how could I do anything USEFUL in c++ and not use libstdc++, if I have any brains left? - Or do you refer to some special capabilities of libstdc++, that provide for the task at hand? Kindest regards Julien > --p > > > -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From julien at c-lab.de Mon Apr 10 15:04:13 2006 From: julien at c-lab.de (Julien Claassen) Date: Mon Apr 10 15:04:23 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <1144687094.10666.28.camel@localhost.localdomain> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> Message-ID: Hi! Thank you all for your replies. I think they are very helpful, though unfortunitely - dumb as I am - I'll have to think about this and understand it completely. I'm most certainly REALLY worse in programming than you can imagine... :-) No this is a fact, but fortunitely - on the other hand - I'm willing and able to learn. Kindest regards and thanks again Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From patrickkidd.lists at gmail.com Mon Apr 10 15:08:11 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 10 15:08:21 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144339207.14746.117.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <1144338496.2866.60.camel@mindpipe> <1144339207.14746.117.camel@localhost.localdomain> Message-ID: <664bf2b80604101208w55193365u1b606bca36b489bf@mail.gmail.com> Paul, I just wanted to throw another simple thank you your way for ardour. I started saving my girfriend valuable studio time when we started using it yesterday for her album, and I continue to be impressed with it. terrific! On 4/6/06, Paul Davis wrote: > On Thu, 2006-04-06 at 11:48 -0400, Lee Revell wrote: > > On Thu, 2006-04-06 at 04:14 -0800, Patrick Stinson wrote: > > > I've been looking for a high-performance music engine. It must have an > > > asynchronous control (socket, pipe?) mechanism to seperate the > > > application from the audio thread. > > > > > > I'm looking for: > > > > > > start/stop samples on the beat > > > scaled tempo control across all samples > > > volume > > > effects? > > > easily wrappable (I'll write extensions, implement protocol > > > plugins...) with python > > > > > > I'm trying to write something like ableton live without writing an > > > engine all over again. FMODex would be *perfect* if it had a > > > well-defined tempo/beat/sync interface. > > > > > > > I think FreeWheeling might be the closest thing to Live that exists for > > Linux, have you looked at it? > > Freewheeling is *so* unlike Live its hard to even link the two. Just for > a start, Live is organized around a timeline, Freewheeling is not. > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From patrickkidd.lists at gmail.com Mon Apr 10 15:22:54 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 10 15:23:01 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <20060406162513.GA16158@riyal.ugcs.caltech.edu> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406162513.GA16158@riyal.ugcs.caltech.edu> Message-ID: <664bf2b80604101222s53edc2f4ie246b2c46c917201@mail.gmail.com> I'm running OS X, and would like to keep my compile-time dependencies down. Is it possible to get gdam-server running w/o gtk+? libxml is not too bad, but gtk+ requires quite a bit of stuff. cheers... On 4/6/06, Lance Blisters wrote: > On Thu, Apr 06, 2006 at 04:14:32AM -0800, Patrick Stinson wrote: > > I've been looking for a high-performance music engine. It must have an > > asynchronous control (socket, pipe?) mechanism to seperate the > > application from the audio thread. > > Everytime this comes up, i hesitantly recommend GDAM. Its an 8 year old > C and glib project, a server/client music engine with various music interfaces > on top. Its core goal was DJ mixing, back when there were few software > dj apps available. The design for this was not at all "mimic a turntable > or cd deck's interface" but rather "digital music files, each with one > or more areas with regular rhythm, combined and symchronized in > different ways". So there are server-side, sample-accurate synch functions > based on defining tempo-and-downbeat for two tracks and commanding one > to beatmatch to the other. It will even walk the audio tree and take > filters which change tempo, resample, or add latency into account. It > is truly sample accurate, you can play two copies of a song, invert one, > beatmatch, and get silence. > > GDAM also has seamless queueing of upcoming tracks, numerous builtin > effects and LADSPA and JACK support. You could implement the GDAM > protocol yourself in any language, or program against the "client" > library which handles the protocol, or program against the "model" > library where a number of higher level client-side concepts (turntables, > sequencers etc) are implemented. Also a GTK-based GUI library is > available with pixmap-based widgets. > > Why the hesitance? I can't promise any time at all to explain or help. > Development of GDAM has been ongoing but i haven't made a release in > years, and the documentation is quite old, and doesn't cover developer > topics. > > GDAM server audio engine really should be able to handle nearly anything > you can dream up, its just a matter of all the organization and interface > work. I was close to doing a live-alike myself (and have a half-finished > attempt at a matrix-style loop mixing skin in CVS). If you search for GDAM > or ableton in the list archives you'll find some other responses with > more details. > > http://gdam.ffem.org/ > > -geoff > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From ce at christeck.de Mon Apr 10 16:40:25 2006 From: ce at christeck.de (Christoph Eckert) Date: Mon Apr 10 16:39:38 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: <1144687094.10666.28.camel@localhost.localdomain> Message-ID: <200604102240.25672.ce@christeck.de> > Thank you all for your replies. I think they are very helpful, though > unfortunitely - dumb as I am - I'll have to think about this and > understand it completely. I'm most certainly REALLY worse in > programming than you can imagine... :-) No this is a fact, but > fortunitely - on the other hand - I'm willing and able to learn. I'm not sure if this is what you need, but maybe Qt4 is worth a look. Since 4.0 Qt can be used in GUI-less applications. For connecting events it uses a signal and slot mechanism which also works thread save since Qt4. I have to admit that I as a non programmer was able to do some useful stuff in Qt in a short period of time, and the documentation really is very useful. Not sure if their site is readable with console browsers, but if so, maybe you find it interesting to read doc.trolltech.com Best regards ce From paul at linuxaudiosystems.com Mon Apr 10 16:46:42 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Apr 10 16:42:51 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> Message-ID: <1144702002.10666.30.camel@localhost.localdomain> On Mon, 2006-04-10 at 21:02 +0200, Julien Claassen wrote: > In Apr 10 A.D. 2006 Paul Davis scripsit: > > > On Mon, 2006-04-10 at 12:26 -0400, Dave Robillard wrote: > > > > > If you want this in C++, you definitely want to use libsigc++. > > > > > > (Keyword definitely) > > > > actually, its worse than that. if you do this in C++ and you do not use > > libsigc++, then a team of ninja open source developers will enter your > > house overnight and eviscerate your internal organs. you cannot run, you > > cannot hide. please, don't take chances. use libsigc++ for the sake of > > your family and loved ones. > > > > Well, how could I do anything USEFUL in c++ and not use libstdc++, if I have > any brains left? - Or do you refer to some special capabilities of libstdc++, > that provide for the task at hand? libsigc++ != libstdc++ From James at superbug.co.uk Mon Apr 10 16:49:50 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Mon Apr 10 16:49:57 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: Message-ID: <443AC4EE.8000900@superbug.co.uk> Julien Claassen wrote: > Hi all! > I know it's completely OT, but I think there maybe people here, who could > help me. > Problem is: I'm still on my libcui (character user interface) project and I > wonder: > I push a button, slide a slider... How does the UI notify the program of > this change? How do Engine and UI communicate? > Please anyone: HELP ME! > Kindest regards > Julien > Most GUIs are "Event" driven by means of message passing. The GUI would just listen to the messages from the "Engine" and send messages to the engine. The listening thread would register it's interest in a particular message queue. This is done by the listening thread informing the "Engine" of it's callback function via a function pointer. The "Engine" would simply build up a linked list of all the listeners for a particular queue, and then call each callback function for each and every message it received. So, if the user "push a button", that causes a message to be added to the message queue. The "Engine" would then call all the callback functions saying "push a button", so all the listeners now know that a button was pressed. James From julien at c-lab.de Mon Apr 10 17:11:06 2006 From: julien at c-lab.de (Julien Claassen) Date: Mon Apr 10 17:11:18 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <1144702002.10666.30.camel@localhost.localdomain> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> <1144702002.10666.30.camel@localhost.localdomain> Message-ID: Hi! This libsig and libstd was a missreading on my part. They can look a bit similar on a not-so-functional braille-display... :-) Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From dsbaikov at gmail.com Mon Apr 10 18:48:56 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Mon Apr 10 18:49:02 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> <1144702002.10666.30.camel@localhost.localdomain> Message-ID: <70a871c80604101548p56808130g381636ba0c80bdef@mail.gmail.com> Julien, If I understand your question right, you have gui/cui and engine in separate processes and want them to communicate. My answer is: you are going the right way(tm), use OSC via liblo. Regards, Dmitry. From patrickkidd.lists at gmail.com Mon Apr 10 18:58:40 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 10 18:58:45 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144466814.5040.16.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> <1144466814.5040.16.camel@localhost.localdomain> Message-ID: <664bf2b80604101558m676a48b0sf4cc9b418313e2ca@mail.gmail.com> Paul, Everyone, What kind of assumptions can we make about the performance of the various FIFO pipe/socket/whatever mechanisms on a POSIX machine? This is by no means my area of expertise, but I currently hold the assumption that a POSIX machine should provide FIFO pipe-ish things that are *very* fast, considering they dont live in a local context. If native FIFO I/O mechanisms are not fast enough for, say, spewing 1/256th of a 10-20 second wave form's data to some app, isn't there something wrong? What metrics do you keep on the tip of your tongue after working with ardour and jack? On 4/7/06, Paul Davis wrote: > On Fri, 2006-04-07 at 14:23 -0800, Patrick Stinson wrote: > > As an added note to my previous comments, I really like the app > > interface that mpd uses. Writing ascii events using some spec or > > another to a file descriptor (socket in mpd's case) seems to be a > > terrific way to communicated with apps and libs. I run the svn > > pksampler like this: > > > > pksampler | pkaudiod > > > > I could just as easily have either use a socket or some other pipe, > > and this is easy to debug, script, profile, etc. On the client and > > server sides, I wrap my 10-minute rpc into an interface with generic > > calls. Everything having to do with input (MIDI, OSC, whatever) > > happens in the app code. The interface functions resemble those of > > FMODEx's interface; add sample, connect to channel, set sample attrs, > > etc. > > > > As an interface designer, the first thing I look for on an engine's > > project site is some sort of asynchronous API - I should never concern > > myself with anything outside referencing the api from my app's one > > windowing thread. FMOD, gstreamer, and my dead pkaudio project do this > > very well. I don't ever want to worry about what thread it happens in, > > what threads it will affect, or what the performance effects of > > *making* the call will be (as opposed to residual effects). > > although i agree that this is the right design for many classes of > application design, i would like to see how you propose to tackle > metering and waveform display (the two most difficult examples). > ardour would be relatively easy to separate into interface+engine > processes (as opposed to just a lib/lib-client separation) if it were > not for these issues. moving waveform and metering data back and forth > between two processes via a wire protocol is very expensive and > inefficient. > > --p > > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From paul at linuxaudiosystems.com Mon Apr 10 19:14:38 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Apr 10 19:10:49 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604101558m676a48b0sf4cc9b418313e2ca@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <44358591.8010704@t-online.de> <1144358867.12038.9.camel@mindpipe> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> <1144466814.5040.16.camel@localhost.localdomain> <664bf2b80604101558m676a48b0sf4cc9b418313e2ca@mail.gmail.com> Message-ID: <1144710878.10666.39.camel@localhost.localdomain> On Mon, 2006-04-10 at 14:58 -0800, Patrick Stinson wrote: > Paul, Everyone, > > What kind of assumptions can we make about the performance of the > various FIFO pipe/socket/whatever mechanisms on a POSIX machine? This > is by no means my area of expertise, but I currently hold the > assumption that a POSIX machine should provide FIFO pipe-ish things > that are *very* fast, considering they dont live in a local context. > If native FIFO I/O mechanisms are not fast enough for, say, spewing > 1/256th of a 10-20 second wave form's data to some app, isn't there > something wrong? What metrics do you keep on the tip of your tongue > after working with ardour and jack? they are definitely fast enough. the issue for me is the switch from shared pointer access to data to having to fetch/read it via some IPC. this is not a technical problem, its a "do i want to get my head around this" issue. the answer is yes, but the answer to "when" is unclear. ardour and JACK use in-memory FIFO's for interthread wakeups, and although theoretically they are not RT safe, they are as good as it gets unless we want to dump 2.4 kernels and use futexes. the problem in ardour for waveform display is that it has to scale to handle potentially enormous quantities of data. imagining zooming to encompass all of a 4hr, 60 track session. although the number of pixels on screen remains the same, the amount of data that represents is huge. this forces careful threading design onto any naive attempt to "just ask for the peaks and you're done". From patrickkidd.lists at gmail.com Mon Apr 10 19:49:09 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Mon Apr 10 19:49:17 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144710878.10666.39.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406214555.GD16853@replic.net> <664bf2b80604061507h30124854i28af9f582cb683e1@mail.gmail.com> <70a871c80604070318g321acf2dxc1a5c432ee983272@mail.gmail.com> <664bf2b80604071211m6cc93890l8b3bbf60a6aa7f53@mail.gmail.com> <70a871c80604071221x233131cka104276f7f5a4220@mail.gmail.com> <664bf2b80604071523m78c40db5m834f0938898a1c83@mail.gmail.com> <1144466814.5040.16.camel@localhost.localdomain> <664bf2b80604101558m676a48b0sf4cc9b418313e2ca@mail.gmail.com> <1144710878.10666.39.camel@localhost.localdomain> Message-ID: <664bf2b80604101649q317514adve361947a03bcf632@mail.gmail.com> excellent, that's what I thought, thanks. pksampler -p 9000 | pkaudiod | pkuplink -H localhost -p 9000 On 4/10/06, Paul Davis wrote: > On Mon, 2006-04-10 at 14:58 -0800, Patrick Stinson wrote: > > Paul, Everyone, > > > > What kind of assumptions can we make about the performance of the > > various FIFO pipe/socket/whatever mechanisms on a POSIX machine? This > > is by no means my area of expertise, but I currently hold the > > assumption that a POSIX machine should provide FIFO pipe-ish things > > that are *very* fast, considering they dont live in a local context. > > If native FIFO I/O mechanisms are not fast enough for, say, spewing > > 1/256th of a 10-20 second wave form's data to some app, isn't there > > something wrong? What metrics do you keep on the tip of your tongue > > after working with ardour and jack? > > they are definitely fast enough. the issue for me is the switch from > shared pointer access to data to having to fetch/read it via some IPC. > this is not a technical problem, its a "do i want to get my head around > this" issue. the answer is yes, but the answer to "when" is unclear. > > ardour and JACK use in-memory FIFO's for interthread wakeups, and > although theoretically they are not RT safe, they are as good as it gets > unless we want to dump 2.4 kernels and use futexes. > > the problem in ardour for waveform display is that it has to scale to > handle potentially enormous quantities of data. imagining zooming to > encompass all of a 4hr, 60 track session. although the number of pixels > on screen remains the same, the amount of data that represents is huge. > this forces careful threading design onto any naive attempt to "just ask > for the peaks and you're done". > > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From drobilla at connect.carleton.ca Mon Apr 10 20:07:15 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Apr 10 20:07:20 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <1144687094.10666.28.camel@localhost.localdomain> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> Message-ID: <1144714035.5232.1.camel@localhost.localdomain> On Mon, 2006-04-10 at 12:38 -0400, Paul Davis wrote: > On Mon, 2006-04-10 at 12:26 -0400, Dave Robillard wrote: > > > If you want this in C++, you definitely want to use libsigc++. > > > > (Keyword definitely) > > actually, its worse than that. if you do this in C++ and you do not use > libsigc++, then a team of ninja open source developers will enter your > house overnight and eviscerate your internal organs. you cannot run, you > cannot hide. please, don't take chances. use libsigc++ for the sake of > your family and loved ones. and, of course, for great justice. Take off every sigc! -DR- From rlrevell at joe-job.com Tue Apr 11 00:26:58 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Apr 11 00:27:16 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <1144714035.5232.1.camel@localhost.localdomain> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> <1144714035.5232.1.camel@localhost.localdomain> Message-ID: <1144729618.19580.2.camel@mindpipe> On Mon, 2006-04-10 at 20:07 -0400, Dave Robillard wrote: > > and, of course, for great justice. Take off every sigc! > Ah, ZeroWing - Internet meme zero. I can't believe it's been 5 years... Lee From julien at c-lab.de Tue Apr 11 03:44:55 2006 From: julien at c-lab.de (Julien Claassen) Date: Tue Apr 11 03:45:03 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: <70a871c80604101548p56808130g381636ba0c80bdef@mail.gmail.com> References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> <1144702002.10666.30.camel@localhost.localdomain> <70a871c80604101548p56808130g381636ba0c80bdef@mail.gmail.com> Message-ID: In Apr 11 A.D. 2006 Dmitry Baikov scripsit: > Julien, > > If I understand your question right, you have gui/cui and engine in > separate processes and want them to communicate. > My answer is: you are going the right way(tm), use OSC via liblo. Well this sounds good, but I want it to do the "standard-API"- and mechanism-way. I want it to be easy for programmers to use the CUI library. I don't know will this still be ok with OSC as communication? Kindest regards Julien > > Regards, > > Dmitry. > -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From dsbaikov at gmail.com Tue Apr 11 05:50:29 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Tue Apr 11 05:50:35 2006 Subject: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes? In-Reply-To: References: <20060410140901.GC5917@bth05w.ABSp.alcatel.be> <1144686379.4394.1.camel@localhost.localdomain> <1144687094.10666.28.camel@localhost.localdomain> <1144702002.10666.30.camel@localhost.localdomain> <70a871c80604101548p56808130g381636ba0c80bdef@mail.gmail.com> Message-ID: <70a871c80604110250m57511789y43801e83a43bb02b@mail.gmail.com> > Well this sounds good, but I want it to do the "standard-API"- and > mechanism-way. I want it to be easy for programmers to use the CUI library. I > don't know will this still be ok with OSC as communication? No matter what tech you use, you'll need: 1) communicational channel 2) message creation/parsing 3) message routing (handling) Yes, you may use FIFO's (pipes) with standard POSIX API's as a channel, and write messaging stuff yourself. But unless you have very specific requirements, you'll end up writing liblo equivalent. With the exception that you'll have to write and support it yourself. Use liblo, it's easy. Even if you choose to drop it, this experience will help. Regards, Dmitry. From alberto.botti at gmail.com Tue Apr 11 11:29:22 2006 From: alberto.botti at gmail.com (Alberto Botti) Date: Tue Apr 11 11:29:36 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604101222s53edc2f4ie246b2c46c917201@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406162513.GA16158@riyal.ugcs.caltech.edu> <664bf2b80604101222s53edc2f4ie246b2c46c917201@mail.gmail.com> Message-ID: <1144769363.11377.2.camel@localhost.localdomain> Il giorno lun, 10/04/2006 alle 11.22 -0800, Patrick Stinson ha scritto: > I'm running OS X, and would like to keep my compile-time dependencies > down. Is it possible to get gdam-server running w/o gtk+? libxml is > not too bad, but gtk+ requires quite a bit of stuff. GDAM needs GTK+ 1.2, not the more recent GTK+ 2.0. Even the non-gui server code needs GTK (the object system was split from GTK into GLib in GTK 2.0) From patrickkidd.lists at gmail.com Tue Apr 11 13:37:19 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Tue Apr 11 13:37:25 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <1144769363.11377.2.camel@localhost.localdomain> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406162513.GA16158@riyal.ugcs.caltech.edu> <664bf2b80604101222s53edc2f4ie246b2c46c917201@mail.gmail.com> <1144769363.11377.2.camel@localhost.localdomain> Message-ID: <664bf2b80604111037x61814286t118894f156dc72d6@mail.gmail.com> So I suppose ew should all be moving towards OSC for our communication protocols? That means I could be spewing OSC through my pipes: pksampler | pkaudiod | pkvumeter On 4/11/06, Alberto Botti wrote: > Il giorno lun, 10/04/2006 alle 11.22 -0800, Patrick Stinson ha scritto: > > I'm running OS X, and would like to keep my compile-time dependencies > > down. Is it possible to get gdam-server running w/o gtk+? libxml is > > not too bad, but gtk+ requires quite a bit of stuff. > > GDAM needs GTK+ 1.2, not the more recent GTK+ 2.0. Even the non-gui > server code needs GTK (the object system was split from GTK into GLib in > GTK 2.0) > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From ajtee at ajtee.plus.com Tue Apr 11 14:12:08 2006 From: ajtee at ajtee.plus.com (Adam Tee) Date: Tue Apr 11 14:08:27 2006 Subject: [linux-audio-dev] [ANN] GNU Denemo 0.75 Message-ID: <443BF178.6010601@ajtee.plus.com> GNU Denemo, a GTK+ front-end to GNU Lilypond Major changes include: Moved back to Plain C for future releases Reimplementation of keymaps so they are now XML based Midi import Lilypond Export Updates Reimplementation of rc files so that they are now XML Removal of Blank rest modes Crash Recovery Lots of memory leak fixes Help Manual now available Revised CSound export Revised Print functionality Blank notes are now displayed in Yellow to aid in viewing the score Keybindings for inserting Time Signatures, Key Signatures and Clefs Adam Maintainer GNU Denemo http://denemo.sourceforge.net From kjetil at ccrma.Stanford.EDU Tue Apr 11 15:10:27 2006 From: kjetil at ccrma.Stanford.EDU (Kjetil Svalastog Matheussen) Date: Tue Apr 11 15:10:37 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <20060408032845.E7A3DF6320C@music.columbia.edu> References: <20060408032845.E7A3DF6320C@music.columbia.edu> Message-ID: Paul Davis: >> As an interface designer, the first thing I look for on an engine's >> project site is some sort of asynchronous API - I should never concern >> myself with anything outside referencing the api from my app's one >> windowing thread. FMOD, gstreamer, and my dead pkaudio project do this >> very well. I don't ever want to worry about what thread it happens in, >> what threads it will affect, or what the performance effects of >> *making* the call will be (as opposed to residual effects). > >although i agree that this is the right design for many classes of >application design, i would like to see how you propose to tackle >metering and waveform display (the two most difficult examples). >ardour would be relatively easy to separate into interface+engine >processes (as opposed to just a lib/lib-client separation) if it were >not for these issues. moving waveform and metering data back and forth >between two processes via a wire protocol is very expensive and >inefficient. How about creating the gfx waveform data on the engine and then just send a pointer to the gfx process, which displays the data using the MIT-SHM X extension? PS. Please don't let this inspire you to reimplement Ardour. :-) From geoff at hurl.ugcs.caltech.edu Tue Apr 11 19:04:09 2006 From: geoff at hurl.ugcs.caltech.edu (Lance Blisters) Date: Tue Apr 11 19:04:18 2006 Subject: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR Message-ID: <20060411230409.GF13955@hurl.ugcs.caltech.edu> I bought a Layla24 and Cardbus adaptor. Works beatifully with ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8 analog channels as device 0 and 8 digital channels as device 1. JACK will only open one device at a time. So in order to record and play back 16 channels with Ardour, I apparently need to create a virtual ALSA device combining the two LAYLA subdevices. Which brings me back to a place I always find myself when working with new sound gear - ALSA LIMBO, a dark claustrophobic space occupied only by unidentified .asoundrc fragments, paved with device anomolies, mined with disinformation bomblets, seen through the funhouse mirrors of fruitless google sessions. Cascades of similar plugin types of indeterminate direction, each encased in the next like a 12-step turducken, translated through an inconsistent mix of multiple (equivalent?) syntaxes, with the smallest deviation producing a cryptic failure. A breadcrumb trail of trials and errors spirals back further than I can see, and the only sounds I can hear over the queasy rumblings building in my stomach, is me repeating to myself that OF COURSE it is possible, I can't be the ONLY person to try to use all channels with JACK, and if I just dig through another 10 pages of search results i'll surely find a .asoundrc which solves the whole thing for me. And then I wake, throat hoarse, sticky with fever sweat, to apply ice to my forehead and plaster to the fresh hole in my wall. And I beg of you, someone, please, for the love of all that is holy, just give me the damn answer so i can get on with my life. And not a "use the multi plugin" answer, because THAT IS NO ANSWER, THAT IS ONLY A TAUNT. An actual, complete .asoundrc which has actually worked in practice, with .ctl, mmap, exclusivity, #channels, etc accounted for. The kind which saves me literal hours of very literal frustration. Thanks in advance, -geoff From j4strngs at bitless.net Wed Apr 12 00:01:56 2006 From: j4strngs at bitless.net (John Check) Date: Wed Apr 12 00:02:26 2006 Subject: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR In-Reply-To: <20060411230409.GF13955@hurl.ugcs.caltech.edu> References: <20060411230409.GF13955@hurl.ugcs.caltech.edu> Message-ID: <200604120001.56727.j4strngs@bitless.net> On Tuesday 11 April 2006 07:04 pm, Lance Blisters wrote: > I bought a Layla24 and Cardbus adaptor. Works beatifully with > ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8 > analog channels as device 0 and 8 digital channels as device 1. JACK will > only open one device at a time. So in order to record and play back 16 > channels with Ardour, I apparently need to create a virtual ALSA device > combining the two LAYLA subdevices. > > Which brings me back to a place I always find myself when working with new > sound gear - ALSA LIMBO, a dark claustrophobic space occupied only by > unidentified .asoundrc fragments, paved with device anomolies, mined with > disinformation bomblets, seen through the funhouse mirrors of fruitless > google sessions. Cascades of similar plugin types of indeterminate > direction, each encased in the next like a 12-step turducken, translated > through an inconsistent mix of multiple (equivalent?) syntaxes, with the > smallest deviation producing a cryptic failure. A breadcrumb trail of > trials and errors spirals back further than I can see, and the only sounds > I can hear over the queasy rumblings building in my stomach, is me > repeating to myself that OF COURSE it is possible, I can't be the ONLY > person to try to use all channels with JACK, and if I just dig through > another 10 pages of search results i'll surely find a .asoundrc which > solves the whole thing for me. > > And then I wake, throat hoarse, sticky with fever sweat, to apply ice to my > forehead and plaster to the fresh hole in my wall. And I beg of you, > someone, please, for the love of all that is holy, just give me the damn > answer so i can get on with my life. And not a "use the multi plugin" > answer, because THAT IS NO ANSWER, THAT IS ONLY A TAUNT. An actual, > complete .asoundrc which has actually worked in practice, with .ctl, mmap, > exclusivity, #channels, etc accounted for. The kind which saves me literal > hours of very literal frustration. > > Thanks in advance, > > -geoff I hate when that happens! From rlrevell at joe-job.com Wed Apr 12 01:08:38 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Apr 12 01:18:03 2006 Subject: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR In-Reply-To: <20060411230409.GF13955@hurl.ugcs.caltech.edu> References: <20060411230409.GF13955@hurl.ugcs.caltech.edu> Message-ID: <1144818519.23922.30.camel@mindpipe> On Tue, 2006-04-11 at 16:04 -0700, Lance Blisters wrote: > I bought a Layla24 and Cardbus adaptor. Works beatifully with ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8 analog channels as device 0 and 8 digital channels as device 1. JACK will only open one device at a time. So in order to record and play back 16 channels with Ardour, I apparently need to create a virtual ALSA device combining the two LAYLA subdevices. > Well, you certainly should have asked about it before getting this upset... So both devices are 8 channels full duplex? Lee From rlrevell at joe-job.com Wed Apr 12 01:17:47 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Apr 12 01:18:10 2006 Subject: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR In-Reply-To: <20060411230409.GF13955@hurl.ugcs.caltech.edu> References: <20060411230409.GF13955@hurl.ugcs.caltech.edu> Message-ID: <1144819068.26546.1.camel@mindpipe> On Tue, 2006-04-11 at 16:04 -0700, Lance Blisters wrote: > I bought a Layla24 and Cardbus adaptor. Works beatifully with ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8 analog channels as device 0 and 8 digital channels as device 1. JACK will only open one device at a time. So in order to record and play back 16 channels with Ardour, I apparently need to create a virtual ALSA device combining the two LAYLA subdevices. > Does this work? (based on http://www.sound-man.co.uk/linuxaudio/ice1712multi.html) # .asoundrc for layla # # Create virtual devices out of multiple subdevices # JACK will need MMAP_COMPLEX support to use this. pcm.multi_capture { type multi slaves.a.pcm hw:0,0 slaves.a.channels 8 slaves.b.pcm hw:0,1 slaves.b.channels 8 # First 8 channels of first soundcard (capture) bindings.0.slave a bindings.0.channel 0 bindings.1.slave a bindings.1.channel 1 bindings.2.slave a bindings.2.channel 2 bindings.3.slave a bindings.3.channel 3 bindings.4.slave a bindings.4.channel 4 bindings.5.slave a bindings.5.channel 5 bindings.6.slave a bindings.6.channel 6 bindings.7.slave a bindings.7.channel 7 # First 8 channels of second soundcard (capture) bindings.8.slave b bindings.8.channel 0 bindings.9.slave b bindings.9.channel 1 bindings.10.slave b bindings.10.channel 2 bindings.11.slave b bindings.11.channel 3 bindings.12.slave b bindings.12.channel 4 bindings.13.slave b bindings.13.channel 5 bindings.14.slave b bindings.14.channel 6 bindings.15.slave b bindings.15.channel 7 } ctl.multi_capture { type hw card 0 } pcm.multi_playback { type multi slaves.a.pcm hw:0,0 slaves.a.channels 8 slaves.b.pcm hw:0,1 slaves.b.channels 8 # First 8 channels of first soundcard (playback) bindings.0.slave a bindings.0.channel 0 bindings.1.slave a bindings.1.channel 1 bindings.2.slave a bindings.2.channel 2 bindings.3.slave a bindings.3.channel 3 bindings.4.slave a bindings.4.channel 4 bindings.5.slave a bindings.5.channel 5 bindings.6.slave a bindings.6.channel 6 bindings.7.slave a bindings.7.channel 7 # First 8 channels of second soundcard (playback) bindings.8.slave b bindings.8.channel 0 bindings.9.slave b bindings.9.channel 1 bindings.10.slave b bindings.10.channel 2 bindings.11.slave b bindings.11.channel 3 bindings.12.slave b bindings.12.channel 4 bindings.13.slave b bindings.13.channel 5 bindings.14.slave b bindings.14.channel 6 bindings.15.slave b bindings.15.channel 7 } ctl.multi_playback { type hw card 0 } From geoff at hurl.ugcs.caltech.edu Wed Apr 12 03:03:31 2006 From: geoff at hurl.ugcs.caltech.edu (Lance Blisters) Date: Wed Apr 12 03:03:39 2006 Subject: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR In-Reply-To: <1144819068.26546.1.camel@mindpipe> References: <20060411230409.GF13955@hurl.ugcs.caltech.edu> <1144819068.26546.1.camel@mindpipe> Message-ID: <20060412070331.GA22098@hurl.ugcs.caltech.edu> On Wed, Apr 12, 2006 at 01:17:47AM -0400, Lee Revell wrote: > On Tue, 2006-04-11 at 16:04 -0700, Lance Blisters wrote: > > I bought a Layla24 and Cardbus adaptor. Works beatifully with ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8 analog channels as device 0 and 8 digital channels as device 1. JACK will only open one device at a time. So in order to record and play back 16 channels with Ardour, I apparently need to create a virtual ALSA device combining the two LAYLA subdevices. > > > > Does this work? (based on > http://www.sound-man.co.uk/linuxaudio/ice1712multi.html) > > # .asoundrc for layla > # > # Create virtual devices out of multiple subdevices > # JACK will need MMAP_COMPLEX support to use this. > > pcm.multi_capture { > type multi > slaves.a.pcm hw:0,0 > slaves.a.channels 8 > slaves.b.pcm hw:0,1 The above line produces the following: ALSA lib conf.c:1592:(snd_config_load1)_toplevel_:606:27:Unexpected char ALSA lib conf.c:2837:(snd_config_hook_load)/root/.asoundrc may be old or corrupted consider to remove or fix it Character 27 is either the '1' or the newline. The MMAP_COMPLEX note might be relevant to a dead end i reached earlier. Does anyone know whether planetccrma builds jack with this option? jackd --help doesn't mention. i have version jackd 0.100.6. Thanks for the assistance. -geoff From tito at rumford.de Wed Apr 12 03:00:26 2006 From: tito at rumford.de (Wolfgang Woehl) Date: Wed Apr 12 03:13:42 2006 Subject: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR In-Reply-To: <20060411230409.GF13955@hurl.ugcs.caltech.edu> References: <20060411230409.GF13955@hurl.ugcs.caltech.edu> Message-ID: <200604120900.01585.tito@rumford.de> Lance Blisters : > I bought a Layla24 and Cardbus adaptor. Works beatifully > with ALSA/JACK/ARDOUR up to 8 channels. However, the > soundcard presents the 8 analog channels as device 0 and 8 > digital channels as device 1. JACK will only open one > device at a time. So in order to record and play back 16 > channels with Ardour, I apparently need to create a virtual > ALSA device combining the two LAYLA subdevices. You're probably aware of Giuliano Pochini being the author of ALSA's Echo/Layla drivers. He is on alsa-dev, very helpful and might just know what you need. -- Wolfgang From drobilla at connect.carleton.ca Wed Apr 12 08:40:45 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 12 08:40:57 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: References: <20060408032845.E7A3DF6320C@music.columbia.edu> Message-ID: <1144845645.5827.5.camel@localhost.localdomain> On Tue, 2006-04-11 at 12:10 -0700, Kjetil Svalastog Matheussen wrote: > Paul Davis: > >> As an interface designer, the first thing I look for on an engine's > >> project site is some sort of asynchronous API - I should never concern > >> myself with anything outside referencing the api from my app's one > >> windowing thread. FMOD, gstreamer, and my dead pkaudio project do this > >> very well. I don't ever want to worry about what thread it happens in, > >> what threads it will affect, or what the performance effects of > >> *making* the call will be (as opposed to residual effects). > > > >although i agree that this is the right design for many classes of > >application design, i would like to see how you propose to tackle > >metering and waveform display (the two most difficult examples). > >ardour would be relatively easy to separate into interface+engine > >processes (as opposed to just a lib/lib-client separation) if it were > >not for these issues. moving waveform and metering data back and forth > >between two processes via a wire protocol is very expensive and > >inefficient. > > How about creating the gfx waveform data on the engine and then just > send a pointer to the gfx process, which displays the data using the > MIT-SHM X extension? > > PS. Please don't let this inspire you to reimplement Ardour. :-) Actually Lars Luthman's DSSI Oscilloscope plugin does exactly this. -DR- From paul at linuxaudiosystems.com Wed Apr 12 08:54:35 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Apr 12 08:50:43 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144845645.5827.5.camel@localhost.localdomain> References: <20060408032845.E7A3DF6320C@music.columbia.edu> <1144845645.5827.5.camel@localhost.localdomain> Message-ID: <1144846475.10666.98.camel@localhost.localdomain> On Wed, 2006-04-12 at 08:40 -0400, Dave Robillard wrote: > On Tue, 2006-04-11 at 12:10 -0700, Kjetil Svalastog Matheussen wrote: > > Paul Davis: > > >> As an interface designer, the first thing I look for on an engine's > > >> project site is some sort of asynchronous API - I should never concern > > >> myself with anything outside referencing the api from my app's one > > >> windowing thread. FMOD, gstreamer, and my dead pkaudio project do this > > >> very well. I don't ever want to worry about what thread it happens in, > > >> what threads it will affect, or what the performance effects of > > >> *making* the call will be (as opposed to residual effects). > > > > > >although i agree that this is the right design for many classes of > > >application design, i would like to see how you propose to tackle > > >metering and waveform display (the two most difficult examples). > > >ardour would be relatively easy to separate into interface+engine > > >processes (as opposed to just a lib/lib-client separation) if it were > > >not for these issues. moving waveform and metering data back and forth > > >between two processes via a wire protocol is very expensive and > > >inefficient. > > > > How about creating the gfx waveform data on the engine and then just > > send a pointer to the gfx process, which displays the data using the > > MIT-SHM X extension? > > > > PS. Please don't let this inspire you to reimplement Ardour. :-) > > Actually Lars Luthman's DSSI Oscilloscope plugin does exactly this. nice idea, except that it needs to work across a LAN too, which MIT-SHM doesn't accomplish. anyway, the comments here last week/last weekend convinced me to look at this in a new light. the bandwidth is really much less than i had been imagining. and i stress "imagining" :) --p From larsl at users.sourceforge.net Wed Apr 12 12:34:10 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed Apr 12 12:34:20 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] music engine In-Reply-To: <1144845645.5827.5.camel@localhost.localdomain> References: <20060408032845.E7A3DF6320C@music.columbia.edu> <1144845645.5827.5.camel@localhost.localdomain> Message-ID: <1144859650.10990.5.camel@localhost> On Wed, 2006-04-12 at 08:40 -0400, Dave Robillard wrote: > On Tue, 2006-04-11 at 12:10 -0700, Kjetil Svalastog Matheussen wrote: > > How about creating the gfx waveform data on the engine and then just > > send a pointer to the gfx process, which displays the data using the > > MIT-SHM X extension? > > > > PS. Please don't let this inspire you to reimplement Ardour. :-) > > Actually Lars Luthman's DSSI Oscilloscope plugin does exactly this. Not really - it actually pushes _all_ audio data onto a ringbuffer in normal SysV shared memory, period by period, and does all the triggering and rendering in the GUI. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060412/a02b330a/attachment.bin From b0ef at esben-stien.name Wed Apr 12 15:45:42 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed Apr 12 13:58:02 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> (Dmitry Baikov's message of "Thu, 6 Apr 2006 14:36:34 +0400") References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> Message-ID: <87u08y4ly1.fsf@esben-stien.name> "Dmitry Baikov" writes: > post its latency (2x64) ..and I suppose you mean 48000 sampling rate. I get: 206.765 Actually, it varies between 206.765 and 206.766 FUJITSU SIEMENS D1561 Intel(R) Celeron(R) CPU 2.40GHz linux-2.6.16 -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From fons.adriaensen at skynet.be Wed Apr 12 15:28:22 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Wed Apr 12 15:24:10 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <87u08y4ly1.fsf@esben-stien.name> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <87u08y4ly1.fsf@esben-stien.name> Message-ID: <20060412192822.GD5046@linux-1> On Wed, Apr 12, 2006 at 09:45:42PM +0200, Esben Stien wrote: > Actually, it varies between 206.765 and 206.766 That's about 20 nanoseconds difference, or less than the delay of 10 meters of cable... -- FA Follie! Follie! Delirio vano e' questo! From dsbaikov at gmail.com Wed Apr 12 18:30:50 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Wed Apr 12 18:30:55 2006 Subject: [linux-audio-dev] multiface latency question In-Reply-To: <87u08y4ly1.fsf@esben-stien.name> References: <70a871c80604050014v4cda2ef5v8b99b36caea980c9@mail.gmail.com> <70a871c80604060336g1dcd5036r395a64008853daae@mail.gmail.com> <87u08y4ly1.fsf@esben-stien.name> Message-ID: <70a871c80604121530t5c246f71y3f1e94274314ad39@mail.gmail.com> On 4/12/06, Esben Stien wrote: > > post its latency (2x64) > ..and I suppose you mean 48000 sampling rate. I'm sure it does not matter, jdelay measures samples not seconds. Or hw can have different paths for different sample rates? > 206.765 Thanks. Dmitry. From kjetil at ccrma.stanford.edu Thu Apr 13 20:45:13 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Apr 13 20:45:25 2006 Subject: [linux-audio-dev] [ANN] Snd-ls V0.9.6.2 Message-ID: Download from http://ccrma.stanford.edu/~kjetil/src/ Snd-ls is a distribution of Bill Schottstaedt's sound editor SND. Its target is people that don't know scheme very well, and don't want to spend too much time configuring Snd. It can also serve as a quick introduction to Snd and how it can be set up. The biggest thing about this release of Snd-ls is probably that the rt-player is enabled by default. The rt-player is an alternative player engine for SND that plays soundfiles using the rt-extension and reads data from disk through a buffer. The result is less clicks, and more channels can be played safely at once. Changes 0.9.5.5 -> 0.9.6.2 -------------------------- -Moved the dac size slider into the options menu. -Hide listener on startup. -Removed marks stuff from popup menu. (Incompatible with snd_conffile.scm) -Updated Snd from 8.0/30.3 to 8.0/2.4. Many important fixes, including listener stuff. -Removed playing buttons from pop-up menues. -Added checks for gtk-mnemnomnics so that old key-bindings aren't overwritten. -Many fixes for the rt-player. -Various fixes so that debug printing and warnings/errors are put out to the listener as well as stdout/stderr. -Configured the transform view to show sonograms by default. -Increased standard dac-size from 1024 to 2048. -Added shortcut "l" to turn on/off the listener, and added it to the help menu along with the "c" key for turning on/off controls. -Updated Snd from 7.15 to 8.0. -Enabled rt-player by default. rt-player is an alternative player engine for snd, that plays using the rt-extension and reads data from disk through a ringbuffer. The result is less clicks. From paul at linuxaudiosystems.com Thu Apr 13 20:54:31 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Apr 13 20:50:50 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Snd-ls V0.9.6.2 In-Reply-To: References: Message-ID: <1144976071.10666.149.camel@localhost.localdomain> On Thu, 2006-04-13 at 17:45 -0700, Kjetil S. Matheussen wrote: > The biggest thing about this release of Snd-ls is probably that the > rt-player is enabled by default. The rt-player is an alternative player > engine for SND that plays soundfiles using the rt-extension and reads data > from disk through a buffer. The result is less clicks, and more channels > can be played safely at once. just think, if this had been in place 4 years ago, ardour's editor would have been snd-as-embedded-widget. good? bad? you tell me ;) --p From smithbone at gmail.com Fri Apr 14 03:14:08 2006 From: smithbone at gmail.com (Richard Smith) Date: Fri Apr 14 03:14:16 2006 Subject: [linux-audio-dev] realtime low lat and 2.6.16 Message-ID: <8a0c36780604140014occc9883kcd399785e47a0b70@mail.gmail.com> Whats the recommended realtime low lat setup for 2.6.16? All the docs I read seem to be for much older kernels? Does realtime-lsm still work? I've got a m-audio audiophile 24/96 and I want jackd to run without xruns. I tried the rt16 patches for 2.6.16 but my kernel just hangs on boot. -- Richard A. Smith From fons.adriaensen at alcatelaleniaspace.com Fri Apr 14 04:40:16 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Fri Apr 14 04:40:30 2006 Subject: [linux-audio-dev] libsndfile and WAVEX Message-ID: <20060414084016.GA8144@bth05w.ABSp.alcatel.be> I've gone through the docs a number of times, but can't find a way to read / write the channelmask and guid in a WAVEFORMAT extensible file. Is it possible ? -- FA Follie! Follie! Delirio vano e' questo! From mle+la at mega-nerd.com Fri Apr 14 05:46:38 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri Apr 14 05:46:49 2006 Subject: [linux-audio-dev] libsndfile and WAVEX In-Reply-To: <20060414084016.GA8144@bth05w.ABSp.alcatel.be> References: <20060414084016.GA8144@bth05w.ABSp.alcatel.be> Message-ID: <20060414194638.41b3b0a0.mle+la@mega-nerd.com> Alfons Adriaensen wrote: > I've gone through the docs a number of times, but can't find > a way to read / write the channelmask and guid in a WAVEFORMAT > extensible file. I thought the guid was determined by the data encoding ie once you decide to write PCM data, you have to use a specific guid. > Is it possible ? Not currently. If you want to discuss this further maybe you should bring it up on the libnsndfile-devel list: http://www.mega-nerd.com/libsndfile/lists.html Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I could never learn to use C++, because of the completely overwhelming desire to redesign the language every time I tried to use it, but this is the normal, healthy reaction to C++." -- Erik Naggum From fons.adriaensen at alcatelaleniaspace.com Fri Apr 14 07:44:34 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Fri Apr 14 07:44:42 2006 Subject: [linux-audio-dev] libsndfile and WAVEX In-Reply-To: <20060414194638.41b3b0a0.mle+la@mega-nerd.com> References: <20060414084016.GA8144@bth05w.ABSp.alcatel.be> <20060414194638.41b3b0a0.mle+la@mega-nerd.com> Message-ID: <20060414114434.GC8144@bth05w.ABSp.alcatel.be> On Fri, Apr 14, 2006 at 07:46:38PM +1000, Erik de Castro Lopo wrote: > Alfons Adriaensen wrote: > > > I've gone through the docs a number of times, but can't find > > a way to read / write the channelmask and guid in a WAVEFORMAT > > extensible file. > > I thought the guid was determined by the data encoding ie once > you decide to write PCM data, you have to use a specific guid. You obviously need access to the channelmask when reading or creating multichannel files. As to the GUID, there are e.g. special GUIDs for Ambisonics files, see . BTW I don't understand the relation between the definition of the GUIDs on that page SUBTYPE_AMBISONIC_B_FORMAT_PCM {00000001-0721-11d3-8644-C8C1CA000000} SUBTYPE_AMBISONIC_B_FORMAT_IEEE_FLOAT {00000003-0721-11d3-8644-C8C1CA000000} and the example representation of the first one further down: {0x00000001,0x0000,0x0010, {0x80,0x00, 0x00,0xaa,0x00,0x38, 0x9b, 0x71}} Does it make sense to you ? -- FA Follie! Follie! Delirio vano e' questo! From mle+la at mega-nerd.com Fri Apr 14 08:14:27 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri Apr 14 08:14:36 2006 Subject: [linux-audio-dev] libsndfile and WAVEX In-Reply-To: <20060414114434.GC8144@bth05w.ABSp.alcatel.be> References: <20060414084016.GA8144@bth05w.ABSp.alcatel.be> <20060414194638.41b3b0a0.mle+la@mega-nerd.com> <20060414114434.GC8144@bth05w.ABSp.alcatel.be> Message-ID: <20060414221427.121d3083.mle+la@mega-nerd.com> Alfons Adriaensen wrote: > You obviously need access to the channelmask when reading or creating > multichannel files. > > As to the GUID, there are e.g. special GUIDs for Ambisonics files, > see . > > BTW I don't understand the relation between the definition of > the GUIDs on that page > > SUBTYPE_AMBISONIC_B_FORMAT_PCM {00000001-0721-11d3-8644-C8C1CA000000} > SUBTYPE_AMBISONIC_B_FORMAT_IEEE_FLOAT {00000003-0721-11d3-8644-C8C1CA000000} > > and the example representation of the first one further down: > > {0x00000001,0x0000,0x0010, {0x80,0x00, 0x00,0xaa,0x00,0x38, 0x9b, 0x71}} > > Does it make sense to you ? Sorry, no it doesn't. Thats why I suggested joining the libsndfile-devel list. I didn't implement the WAVEX stuff. The guy who did is on the libsndfile-devel list but not on this one. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -- Alan Kay From fbar at footils.org Fri Apr 14 08:20:35 2006 From: fbar at footils.org (Frank Barknecht) Date: Fri Apr 14 08:20:34 2006 Subject: [linux-audio-dev] realtime low lat and 2.6.16 In-Reply-To: <8a0c36780604140014occc9883kcd399785e47a0b70@mail.gmail.com> References: <8a0c36780604140014occc9883kcd399785e47a0b70@mail.gmail.com> Message-ID: <20060414122035.GA13224@fliwatut.scifi> Hallo, Richard Smith hat gesagt: // Richard Smith wrote: > Whats the recommended realtime low lat setup for 2.6.16? All the docs > I read seem to be for much older kernels? > > Does realtime-lsm still work? I think, yes, but the recommended way with newer kernels is to use the rtlimits-aproach with up to date libpam modules. This is described e.g. at http://ubuntustudio.com/wiki/index.php/Breezy:Rlimits-Aware_PAM > I've got a m-audio audiophile 24/96 and I want jackd to run without xruns. > > I tried the rt16 patches for 2.6.16 but my kernel just hangs on boot. I had (different) problems with the rt-patches for 2.6.16, but even a vanilla kernel 2.6.16 gives very good results, that's why I use that for now. Maybe you should try vanilla first, too. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From list at phasorlab.de Fri Apr 14 08:59:28 2006 From: list at phasorlab.de (Matthias Koenig) Date: Fri Apr 14 08:59:36 2006 Subject: [linux-audio-dev] libsndfile and WAVEX References: <20060414084016.GA8144@bth05w.ABSp.alcatel.be> <20060414194638.41b3b0a0.mle+la@mega-nerd.com> <20060414114434.GC8144@bth05w.ABSp.alcatel.be> Message-ID: <8764lcfh3j.fsf@zebra.localdomain> Alfons Adriaensen writes: > BTW I don't understand the relation between the definition of > the GUIDs on that page > > SUBTYPE_AMBISONIC_B_FORMAT_PCM {00000001-0721-11d3-8644-C8C1CA000000} > SUBTYPE_AMBISONIC_B_FORMAT_IEEE_FLOAT {00000003-0721-11d3-8644-C8C1CA000000} > > and the example representation of the first one further down: > > {0x00000001,0x0000,0x0010, {0x80,0x00, 0x00,0xaa,0x00,0x38, 0x9b, 0x71}} > > Does it make sense to you ? The example representation is for KSDATAFORMAT_SUBTYPE_PCM. Some grepping through MS headers resulted in the following: DEFINE_GUIDSTRUCT("00000001-0000-0010-8000-00aa00389b71", KSDATAFORMAT_SUBTYPE_PCM); #define KSDATAFORMAT_SUBTYPE_PCM DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_PCM) Matthias From smithbone at gmail.com Fri Apr 14 10:15:28 2006 From: smithbone at gmail.com (Richard Smith) Date: Fri Apr 14 10:15:34 2006 Subject: [linux-audio-dev] realtime low lat and 2.6.16 In-Reply-To: <20060414122035.GA13224@fliwatut.scifi> References: <8a0c36780604140014occc9883kcd399785e47a0b70@mail.gmail.com> <20060414122035.GA13224@fliwatut.scifi> Message-ID: <8a0c36780604140715s32fcdc10o62f2a3241f1a4f64@mail.gmail.com> > I think, yes, but the recommended way with newer kernels is to use the > rtlimits-aproach with up to date libpam modules. This is described > e.g. at > http://ubuntustudio.com/wiki/index.php/Breezy:Rlimits-Aware_PAM > Cool thanks I'll give this a read. > > I've got a m-audio audiophile 24/96 and I want jackd to run without xruns. > > > > I tried the rt16 patches for 2.6.16 but my kernel just hangs on boot. > > I had (different) problems with the rt-patches for 2.6.16, but even a > vanilla kernel 2.6.16 gives very good results, that's why I use that > for now. Maybe you should try vanilla first, too. Thats exactly what I did first but I got lots of xruns. However, I wasn't running realtime so perhapas when I get Rlimits setup it will be different. -- Richard A. Smith From fons.adriaensen at alcatelaleniaspace.com Fri Apr 14 10:29:44 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Fri Apr 14 10:29:54 2006 Subject: [linux-audio-dev] libsndfile and WAVEX In-Reply-To: <8764lcfh3j.fsf@zebra.localdomain> References: <20060414084016.GA8144@bth05w.ABSp.alcatel.be> <20060414194638.41b3b0a0.mle+la@mega-nerd.com> <20060414114434.GC8144@bth05w.ABSp.alcatel.be> <8764lcfh3j.fsf@zebra.localdomain> Message-ID: <20060414142944.GD8144@bth05w.ABSp.alcatel.be> On Fri, Apr 14, 2006 at 02:59:28PM +0200, Matthias Koenig wrote: > Alfons Adriaensen writes: > The example representation is for KSDATAFORMAT_SUBTYPE_PCM. > Some grepping through MS headers resulted in the following: > > DEFINE_GUIDSTRUCT("00000001-0000-0010-8000-00aa00389b71", KSDATAFORMAT_SUBTYPE_PCM); > #define KSDATAFORMAT_SUBTYPE_PCM DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_PCM) Thanks ! Suspected something like that but I don't have the MS headers... -- FA Follie! Follie! Delirio vano e' questo! From andersvi at extern.uio.no Fri Apr 14 10:47:13 2006 From: andersvi at extern.uio.no (andersvi@extern.uio.no) Date: Fri Apr 14 10:47:39 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Snd-ls V0.9.6.2 In-Reply-To: <1144976071.10666.149.camel@localhost.localdomain> (Paul Davis's message of "Thu, 13 Apr 2006 20:54:31 -0400") References: <1144976071.10666.149.camel@localhost.localdomain> Message-ID: >>> "P" == Paul Davis writes: P> P> On Thu, 2006-04-13 at 17:45 -0700, Kjetil S. Matheussen wrote: >> The biggest thing about this release of Snd-ls is probably that the >> rt-player is enabled by default. The rt-player is an alternative player >> engine for SND that plays soundfiles using the rt-extension and reads data >> from disk through a buffer. The result is less clicks, and more channels >> can be played safely at once. P> P> just think, if this had been in place 4 years ago, ardour's editor would P> have been snd-as-embedded-widget. good? bad? you tell me ;) It would make for an extremely powerful and flexible audio environment with a fast interface. Might we hope? Talking about fate and hope and such: an import/export of suitable versions of ardours playlists (timed objects) in ardour would be great to interface it cleanly to tools like CM. An "object" would consist of time, source, region, route'gain automation-data, everything making up a regions situation in a mix. From paul at linuxaudiosystems.com Fri Apr 14 11:01:19 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Apr 14 10:57:48 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Snd-ls V0.9.6.2 In-Reply-To: References: <1144976071.10666.149.camel@localhost.localdomain> Message-ID: <1145026880.10666.154.camel@localhost.localdomain> On Fri, 2006-04-14 at 16:47 +0200, andersvi@extern.uio.no wrote: > >>> "P" == Paul Davis writes: > P> > P> On Thu, 2006-04-13 at 17:45 -0700, Kjetil S. Matheussen wrote: > >> The biggest thing about this release of Snd-ls is probably that the > >> rt-player is enabled by default. The rt-player is an alternative player > >> engine for SND that plays soundfiles using the rt-extension and reads data > >> from disk through a buffer. The result is less clicks, and more channels > >> can be played safely at once. > P> > P> just think, if this had been in place 4 years ago, ardour's editor would > P> have been snd-as-embedded-widget. good? bad? you tell me ;) > > It would make for an extremely powerful and flexible audio > environment with a fast interface. Might we hope? i wouldn't spend any time hoping. i spent a month or so back in 2000/2001 trying to use snd as ardour's editor. when it became clear that it couldn't handle much more than about 8-12 tracks of playback, while ardour itself could do 32+, all other considerations were put aside and it was clear we had to develop our own. the other major problem with snd is that it has no concept of regions - its model for audio data is that its a continuous file rather than a playlist. that pretty much ended any debate on the matter. > Talking about fate and hope and such: an import/export of > suitable versions of ardours playlists (timed objects) in ardour > would be great to interface it cleanly to tools like CM. An > "object" would consist of time, source, region, route'gain > automation-data, everything making up a regions situation in a > mix. this is something you can hope for. we already allow per-region export, but the workflow leaves something to be desired. --p From andersvi at extern.uio.no Fri Apr 14 11:42:27 2006 From: andersvi at extern.uio.no (andersvi@extern.uio.no) Date: Fri Apr 14 11:42:59 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Snd-ls V0.9.6.2 In-Reply-To: <1145026880.10666.154.camel@localhost.localdomain> (Paul Davis's message of "Fri, 14 Apr 2006 11:01:19 -0400") References: <1144976071.10666.149.camel@localhost.localdomain> <1145026880.10666.154.camel@localhost.localdomain> Message-ID: >>> "P" == Paul Davis writes: >> Talking about fate and hope and such: an import/export of >> suitable versions of ardours playlists (timed objects) in ardour >> would be great to interface it cleanly to tools like CM. An >> "object" would consist of time, source, region, route'gain >> automation-data, everything making up a regions situation in a >> mix. P> P> this is something you can hope for. we already allow per-region export, P> but the workflow leaves something to be desired. Being able to generate well-formed playlists from external apps (CM) and importing them into existing Ardour sessions would be extremely useful. No.2 would be to export and work on automation-data outside of Ardour, and importing back again. As much scriptability of Ardour's interface (scheme or CL-wise) as possible is very much desired! OSC i/o of ardour, and being able to read files with OSC-bundles to use as playlists (or something to translate to Ardour's .playlist-format) could make flexible and general solutions towards this. From kjetil at ccrma.stanford.edu Fri Apr 14 16:37:17 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Fri Apr 14 16:37:51 2006 Subject: [linux-audio-dev] (no subject) In-Reply-To: <20060414190005.16591.21810.Mailman@cm-mail.stanford.edu> References: <20060414190005.16591.21810.Mailman@cm-mail.stanford.edu> Message-ID: Paul Davis: > > On Fri, 2006-04-14 at 16:47 +0200, andersvi@extern.uio.no wrote: >>>>> "P" == Paul Davis writes: >> P> >> P> On Thu, 2006-04-13 at 17:45 -0700, Kjetil S. Matheussen wrote: >>>> The biggest thing about this release of Snd-ls is probably that the >>>> rt-player is enabled by default. The rt-player is an alternative player >>>> engine for SND that plays soundfiles using the rt-extension and reads data >>>> from disk through a buffer. The result is less clicks, and more channels >>>> can be played safely at once. >> P> >> P> just think, if this had been in place 4 years ago, ardour's editor would >> P> have been snd-as-embedded-widget. good? bad? you tell me ;) >> >> It would make for an extremely powerful and flexible audio >> environment with a fast interface. Might we hope? > > i wouldn't spend any time hoping. i spent a month or so back in > 2000/2001 trying to use snd as ardour's editor. when it became clear > that it couldn't handle much more than about 8-12 tracks of playback, > while ardour itself could do 32+, all other considerations were put > aside and it was clear we had to develop our own. the other major > problem with snd is that it has no concept of regions - its model for > audio data is that its a continuous file rather than a playlist. that > pretty much ended any debate on the matter. > Yeah, that makes sense. However, it would be very nice to have snd as a widget in ardour to edit single soundfiles. If you add some guile functions in ardour to update the graphs in the multitracker waveforms views as well, one could edit in snd (inside ardour somewhere) and immediately see changes in the multitracker view. From fons.adriaensen at skynet.be Fri Apr 14 20:08:57 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Fri Apr 14 20:01:40 2006 Subject: [linux-audio-dev] New release of AMB plugins Message-ID: <20060415000857.GA5104@linux-1> A second release of the Ambisonics plugins is now available. * Added cube (8-speaker) decoder. * Removed conflicting port hints. -- FA Follie! Follie! Delirio vano e' questo! From b0ef at esben-stien.name Sat Apr 15 00:09:06 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Fri Apr 14 22:10:43 2006 Subject: [linux-audio-dev] (no subject) In-Reply-To: (Kjetil S. Matheussen's message of "Fri, 14 Apr 2006 13:37:17 -0700 (PDT)") References: <20060414190005.16591.21810.Mailman@cm-mail.stanford.edu> Message-ID: <871wvzqy3h.fsf@esben-stien.name> "Kjetil S. Matheussen" writes: > snd as a widget in ardour How about doing this with the verse protocol and daemon or in the same spirit?. That way, any editor that supports this protocol, could edit a live region. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From kjetil at ccrma.stanford.edu Sat Apr 15 15:35:43 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Sat Apr 15 15:36:00 2006 Subject: [linux-audio-dev] (no subject) In-Reply-To: <20060415190002.6300.23002.Mailman@cm-mail.stanford.edu> References: <20060415190002.6300.23002.Mailman@cm-mail.stanford.edu> Message-ID: Esben Stien: > > "Kjetil S. Matheussen" writes: > >> snd as a widget in ardour > > How about doing this with the verse protocol and daemon or in the same > spirit?. That way, any editor that supports this protocol, could edit > a live region. > Thats an insanely large project you are proposing. :-) Hacking snd into ardour should only require a days work or something because snd can be compiled as a gtk widget. From hans at fugal.net Sat Apr 15 16:09:16 2006 From: hans at fugal.net (Hans Fugal) Date: Sat Apr 15 16:09:30 2006 Subject: [linux-audio-dev] Summer of Code Message-ID: <20060415200916.GA21956@falcon.fugal.net> Google's Summer of Code is upon us. I have a summer without classes coming up and I can think of nothing better to do (besides studying for qualifying exams) than to hack on a Linux Audio project and get paid for it, benefitting that project with code and money ($500). Is any project, or perhaps the LAD community as a whole, applying for mentorship? http://code.google.com/summerofcode.html Ardour comes to mind as being a good mentor organization candidate. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060415/017cbd6b/attachment-0001.bin From drobilla at connect.carleton.ca Sat Apr 15 16:23:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 15 16:23:35 2006 Subject: [linux-audio-dev] Summer of Code In-Reply-To: <20060415200916.GA21956@falcon.fugal.net> References: <20060415200916.GA21956@falcon.fugal.net> Message-ID: <1145132595.12398.4.camel@DaveLap> On Sat, 2006-04-15 at 14:09 -0600, Hans Fugal wrote: > Google's Summer of Code is upon us. I have a summer without classes > coming up and I can think of nothing better to do (besides studying for > qualifying exams) than to hack on a Linux Audio project and get paid for > it, benefitting that project with code and money ($500). Is any project, > or perhaps the LAD community as a whole, applying for mentorship? > > http://code.google.com/summerofcode.html > > Ardour comes to mind as being a good mentor organization candidate. I would love to get in on the summer of code as well. Maybe a few of us can team up and take on something substantial? (Ardour MIDI?) Maybe one of the music oriented distros would be open to mentorship? -DR- From b0ef at esben-stien.name Sat Apr 15 20:22:24 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Sat Apr 15 18:23:58 2006 Subject: [linux-audio-dev] (no subject) In-Reply-To: (Kjetil S. Matheussen's message of "Sat, 15 Apr 2006 12:35:43 -0700 (PDT)") References: <20060415190002.6300.23002.Mailman@cm-mail.stanford.edu> Message-ID: <87zmimid33.fsf@esben-stien.name> "Kjetil S. Matheussen" writes: > insanely large project [..] :-) Summer of Code;). -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From musical_snake at gmx.de Sun Apr 16 03:43:41 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Sun Apr 16 03:49:15 2006 Subject: [linux-audio-dev] (no subject) In-Reply-To: References: <20060415190002.6300.23002.Mailman@cm-mail.stanford.edu> Message-ID: <4441F5AD.4080702@gmx.de> Kjetil S. Matheussen schrieb: > > > > Hacking snd into ardour should only require a days work or something > because snd can be compiled as a gtk widget. > The reason why i always propose to separate engine and gui into completely independent processes: You can easily integrate it into any other application, regardless of what gui toolkit that one is using. Ralf From musical_snake at gmx.de Sun Apr 16 04:10:51 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Sun Apr 16 04:16:27 2006 Subject: [linux-audio-dev] (no subject) In-Reply-To: <4441F5AD.4080702@gmx.de> References: <20060415190002.6300.23002.Mailman@cm-mail.stanford.edu> <4441F5AD.4080702@gmx.de> Message-ID: <4441FC0B.4060009@gmx.de> Ralf Beck schrieb: > Kjetil S. Matheussen schrieb: > >> >> >> >> Hacking snd into ardour should only require a days work or something >> because snd can be compiled as a gtk widget. >> > The reason why i always propose to separate engine and gui into > completely independent processes: > You can easily integrate it into any other application, regardless of > what gui toolkit that one is using. > > Ralf > > Or, in the case of an external wave editor, just let inetd do the job of launching it. From b0ef at esben-stien.name Sun Apr 16 10:18:27 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Sun Apr 16 08:19:48 2006 Subject: [linux-audio-dev] (no subject) In-Reply-To: <4441F5AD.4080702@gmx.de> (Ralf Beck's message of "Sun, 16 Apr 2006 09:43:41 +0200") References: <20060415190002.6300.23002.Mailman@cm-mail.stanford.edu> <4441F5AD.4080702@gmx.de> Message-ID: <87d5fhhado.fsf@esben-stien.name> Ralf Beck writes: > You can easily integrate it into any other application, regardless > of what gui toolkit that one is using. Yes, absolutely, that too, but I expect my system to be functional about 4 seconds into boot. I work mostly from the terminal tty and I can't depend on any application which core functionality depends on xorg. From anywhere I login, I should be able to control the core with commands or launch a UI/GUI. It also makes it a breeze to troubleshoot. Nothing is more than an address and a command away. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From torbenh at gmx.de Sun Apr 16 17:22:23 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sun Apr 16 17:26:12 2006 Subject: [linux-audio-dev] [ANN] netjack-0.11 Message-ID: <20060416212223.GA23984@mobilat> netjack-0.11 ------------ Warp your jack ports over an IP network. Also have Transport synced between 2 machines. Work is underway in improving the latency for big channel counts, like 24in / 24out. There seems to be a bottleneck in the kernels handling of big UDP Packets. However netjack seems solid with a period size of 128 and a roundtrip latency of 3 periods. (this is at 24/24 float on 100Mbit) The latency does not seem to improve with Gbit. Also featuring: - improved error messages. - some AutoConfig on the slave side. (only period and samplerate) - alsa_in and _out improvements. Have Fun. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From rj at spamatica.se Sun Apr 16 19:37:03 2006 From: rj at spamatica.se (Robert Jonsson) Date: Sun Apr 16 18:36:30 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] netjack-0.11 In-Reply-To: <20060416212223.GA23984@mobilat> References: <20060416212223.GA23984@mobilat> Message-ID: <200604170037.05096.rj@spamatica.se> Awesome! /Robert On Sunday 16 Apr 2006 22:22, torbenh@gmx.de wrote: > netjack-0.11 > ------------ > > Warp your jack ports over an IP network. Also have Transport synced > between 2 machines. > > Work is underway in improving the latency for big channel counts, > like 24in / 24out. There seems to be a bottleneck in the kernels > handling of big UDP Packets. > > However netjack seems solid with a period size of 128 and a roundtrip > latency of 3 periods. (this is at 24/24 float on 100Mbit) The latency > does not seem to improve with Gbit. > > Also featuring: > > - improved error messages. > - some AutoConfig on the slave side. (only period and samplerate) > - alsa_in and _out improvements. > > Have Fun. -- http://spamatica.se/musicsite/ From rlrevell at joe-job.com Mon Apr 17 01:05:29 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Apr 17 01:05:52 2006 Subject: [linux-audio-dev] [ANN] netjack-0.11 In-Reply-To: <20060416212223.GA23984@mobilat> References: <20060416212223.GA23984@mobilat> Message-ID: <1145250331.15151.11.camel@mindpipe> On Sun, 2006-04-16 at 23:22 +0200, torbenh@gmx.de wrote: > > Work is underway in improving the latency for big channel counts, > like 24in / 24out. There seems to be a bottleneck in the kernels > handling of big UDP Packets. Nice, I'm looking forward to the LKML thread! (you do plan to report it right...?) From jens.andreasen at chello.se Mon Apr 17 05:27:04 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Apr 17 05:27:16 2006 Subject: [linux-audio-dev] [ANN] netjack-0.11 In-Reply-To: <1145250331.15151.11.camel@mindpipe> References: <20060416212223.GA23984@mobilat> <1145250331.15151.11.camel@mindpipe> Message-ID: <1145266024.25180.5.camel@c80-216-124-251.cm-upc.chello.se> On Mon, 2006-04-17 at 01:05 -0400, Lee Revell wrote: > On Sun, 2006-04-16 at 23:22 +0200, torbenh@gmx.de wrote: > > > > Work is underway in improving the latency for big channel counts, > > like 24in / 24out. There seems to be a bottleneck in the kernels > > handling of big UDP Packets. > > Nice, I'm looking forward to the LKML thread! > > (you do plan to report it right...?) > Torben, You are not checking the return value of sendto() ... It would be most interesting to know what these are when the application fails. EMSGSIZE EWOULDBLOCK and EAGAIN are some of the possible candidates. http://www.penguin-soft.com/penguin/man/2/send.html -- mvh // Jens M Andreasen From wsynth at gjcp.net Mon Apr 17 07:08:19 2006 From: wsynth at gjcp.net (Gordonjcp) Date: Mon Apr 17 07:10:55 2006 Subject: [linux-audio-dev] Patch storage for simple DSSI plugins? Message-ID: <44437723.6030309@gjcp.net> What's the consensus? Implement patch storage for plugins that don't really have that many controls, or just let the host worry about it? Gordon. From torbenh at gmx.de Mon Apr 17 07:08:36 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Mon Apr 17 07:12:21 2006 Subject: [linux-audio-dev] [ANN] netjack-0.11 In-Reply-To: <1145266024.25180.5.camel@c80-216-124-251.cm-upc.chello.se> References: <20060416212223.GA23984@mobilat> <1145250331.15151.11.camel@mindpipe> <1145266024.25180.5.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060417110836.GA24317@mobilat> On Mon, Apr 17, 2006 at 11:27:04AM +0200, Jens M Andreasen wrote: > On Mon, 2006-04-17 at 01:05 -0400, Lee Revell wrote: > > On Sun, 2006-04-16 at 23:22 +0200, torbenh@gmx.de wrote: > > > > > > Work is underway in improving the latency for big channel counts, > > > like 24in / 24out. There seems to be a bottleneck in the kernels > > > handling of big UDP Packets. > > > > Nice, I'm looking forward to the LKML thread! > > > > (you do plan to report it right...?) > > > > Torben, > > You are not checking the return value of sendto() ... It would be most > interesting to know what these are when the application fails. EMSGSIZE > EWOULDBLOCK and EAGAIN are some of the possible candidates. i dont think its that interesting, return value of EAGAIN means, the packet got dopped, and the sendqueue is full, this generally happens in congestion situations at the dsl modem or something (where its never reported...) EMSGSIZE will not be set. please note, that the application does NOT fail. packet roundtrip time for big UDP packets is too high. So i cant run at -l 1 and have to resort to -l 2 or even -l 3. that means 3 periods of round trip latency. meaning a remote fx processor would have 3 periods of latency added. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From mista.tapas at gmx.net Mon Apr 17 09:39:03 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Apr 17 09:39:13 2006 Subject: [linux-audio-dev] Patch storage for simple DSSI plugins? In-Reply-To: <44437723.6030309@gjcp.net> References: <44437723.6030309@gjcp.net> Message-ID: <20060417153903.76212d96@mango.fruits> On Mon, 17 Apr 2006 12:08:19 +0100 Gordonjcp wrote: > What's the consensus? Implement patch storage for plugins that don't > really have that many controls, or just let the host worry about it? Dunno, if there's concencus, but i'd say, let the host worry about it. There's many plugins where patches aren't really necessary (simple stuff like i.e. my dssi_convolve). Flo -- Palimm Palimm! http://tapas.affenbande.org From larsl at users.sourceforge.net Mon Apr 17 10:14:15 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Mon Apr 17 10:14:24 2006 Subject: [linux-audio-dev] Patch storage for simple DSSI plugins? In-Reply-To: <44437723.6030309@gjcp.net> References: <44437723.6030309@gjcp.net> Message-ID: <1145283255.8370.1.camel@localhost> On Mon, 2006-04-17 at 12:08 +0100, Gordonjcp wrote: > What's the consensus? Implement patch storage for plugins that don't > really have that many controls, or just let the host worry about it? I suppose it depends on whether you want to be able to ship some presets with the plugin and have presets saved in one host available in all others. If not there's no point in implementing DSSI program handling in the plugin. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060417/d63771d7/attachment.bin From asbjs at stud.ntnu.no Tue Apr 18 08:48:58 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Tue Apr 18 08:48:56 2006 Subject: [linux-audio-dev] Open positions in audio research: Ph.D. scholarships, Postdocs, visitors Message-ID: <20060418124858.GA13193@stud.ntnu.no> At Q2S [1] there are currently vacant scholarships for Ph.D. students, and open positions for Postdocs and visiting scholars. The audio group at Q2S has an interest in Linux audio. For our work we have developed software for low latency streaming of audio over IP networks [2], and an encoder/decoder for seventh order Ambisonics in the horizontal plane. We work within audio over IP, sound fields, audio coding, error concealment and related fields [3]. There is also a multimedia group, with which we cooperate closely. A person with in depth knowledge of and experience from Linux audio development and use, ALSA, JACK and related topics might be a welcome addition to the audio group. If you are such a person, and would like to use your talents in an academic research setting, you are encouraged to contact us. Information on the open positions: http://www.q2s.ntnu.no/vacant/dring-en.php http://www.q2s.ntnu.no/vacant/postdoc-en.php The formal deadline for application was march 24th, but later applicants will also be considered. For further informations, these may be contacted: Asbj?rn S?b?, asbjs q2s.ntnu.no Prof. Peter Svensson, svensson iet.ntnu.no With kind regards Asbj?rn S?b? Postdoc, Q2S [1] Centre for Quantifiable Quality of Service in Communication Systems Centre of Excellence Norwegian University of Science and Technology (NTNU) http://www.q2s.ntnu.no [2] http://www.q2s.ntnu.no/~asbjs/ldas/ldas.html Will be presented at LAC in Karlsruhe [3] http://www.q2s.ntnu.no/proaudio.php From dsbaikov at gmail.com Wed Apr 19 09:39:01 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Wed Apr 19 09:39:13 2006 Subject: [linux-audio-dev] [OT] First trip to Europe Message-ID: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> Hello, all! Me and my girlfriend are planning a trip to Europe for a month between May and June. It will be our first trip abroad, so please help if you can with a good advice. Since it's not so easy to get out of here (russia), and I can't visit all that great & numerous openlab's etc., one of the main goals is "community building": I'd like to meet (at least some of ) you, LADs/LAUs, in person. Current plan is (yes, it's huge): Moscow St.Petersurg -- Helsinki Stockholm Berlin Koeln Brussels London Paris Bourdeaux Madrid Barcelona,Figeras Genova Milan? Rome Venice Vienna Prague -- Moscow There are two main questions (lonelyplanet.com helps a bit, but residents can say much more): 1) what is the cheapest way to travel inside europe? Bus? Airplane? If it's by air, how can we buy cheapest tickets? Which company? How much days before the flight? etc. Or may be hitchhiking? 2) how hard is to find cheap place to sleep? AND Where can we meet YOU? Sorry, we don't know exact dates as we are researching on european visa (trip begins from Helsinki, since it seems the easiest way to get into europe). Sincerely, Dmitry. From krampenschiesser at freenet.de Wed Apr 19 13:06:18 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Wed Apr 19 13:06:34 2006 Subject: [linux-audio-dev] [OT] First trip to Europe In-Reply-To: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> References: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> Message-ID: <20060419190618.37fcea7e.krampenschiesser@freenet.de> > 2) how hard is to find cheap place to sleep? You should buy a youth hostelling card, which offers you cheap, but good accommodation in nearly every town in germany france and spain(with breakfeast). Perhaps in other countries, too, but I've not been there yet. I hope there are people who can help you out. In Germany it is the cheapest to travel by train with special cards.(one whole weekend for 50,- for whole germany) Hope this helps. Good luck Scar -- And this is a table ma'am. What in essence it consists of is a horizontal rectilinear plane surface maintained by four vertical columnar supports, which we call legs. The tables in this laboratory, ma'am, are as advanced in design as one will find anywhere in the world. -- Michael Frayn, "The Tin Men" From fbar at footils.org Wed Apr 19 13:56:58 2006 From: fbar at footils.org (Frank Barknecht) Date: Wed Apr 19 13:57:12 2006 Subject: [linux-audio-dev] [OT] First trip to Europe In-Reply-To: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> References: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> Message-ID: <20060419175658.GG11640@fliwatut.scifi> Hallo, Dmitry Baikov hat gesagt: // Dmitry Baikov wrote: > Me and my girlfriend are planning a trip to Europe for a month between > May and June. If you happen to be in Koeln at 18.5.2006, you are invited to a concert I'll give then and there together with a musician/DJ from Latvia. German language details here: http://www.scene-kulturfestival.de/musik-02.html Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From jens.andreasen at chello.se Wed Apr 19 14:01:08 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Apr 19 14:01:17 2006 Subject: [linux-audio-dev] [OT] First trip to Europe In-Reply-To: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> References: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> Message-ID: <1145469668.25180.40.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-04-19 at 17:39 +0400, Dmitry Baikov wrote: > There are two main questions > (lonelyplanet.com helps a bit, but residents can say much more): > http://wikitravel.org/ > 1) what is the cheapest way to travel inside europe? > Bus? Airplane? If it's by air, how can we buy cheapest tickets? Which > company? How much days before the flight? etc. Or may be hitchhiking? > Given the almost unbeliveable long list of places to visit ... Perhaps getting a eurail pass would fit the bill? It may sound a bit steep to pay over 600 Euro for a month, but note that the (cheapest) bus fare from Stockholm to Copenhagen alone will set you back at least 60 Euro. http://www.eurail.com/ Ryan Air (and others) sometimes have insane prices. I managed to get a flight to Rome for less than 30 Euro :-D http://www.ryanair.com/site/RU/?culture=RU > 2) how hard is to find cheap place to sleep? > Dormitory (or better) at around 20 Euro/person should be available almost everywhere. Most backpackers are still in school or at university. To give you some idea, try a hostel booking site like: http://www.hostelbookers.com > AND > > Where can we meet YOU? > > Sorry, we don't know exact dates as we are researching on european > visa (trip begins from Helsinki, since it seems the easiest way to get > into europe). > > > Sincerely, > Dmitry. -- From kouhia at nic.funet.fi Wed Apr 19 15:00:23 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Wed Apr 19 15:01:51 2006 Subject: [linux-audio-dev] Kaiku..ku..kuu.kuuu... Message-ID: Kaiku. It is unfinished. I'm stuck. A lot of help needed! Don't use seriously. Not all important controls are in GUI. http://www.funet.fi/~kouhia/kaiku20060418.tar.gz Kaiku is now GVerb plus multitap, but will improve to different structure which I have already designed. I will complete the reverb code if the problems will be fixed. (1) Need better GUI. Control envelopes on time-axis for a few features. GTK2 and/or OpenGL. We discussed about the great amount of callbacks used in my GTK code years ago but I did learn nothing ;-) (2) Preset system. XML files. (3) How to run a Jack application in an editor as a non-realtime plugin? (4) Kaiku should start as unconnected Jack application. Or connected to Alsa or Jack ports given as command line options. (5) My computer is only barely running Kaiku in realtime, and that after I reduced the multitap delay complexity. I have not taken speed-ups from LADSPA-GVerb. Uh oh. The code has unused old code as well. Some experimental GUI stuff. Ignore them. I only would like to have a Lexicon quality reverb. Designing and coding such a reverb is a huge task, and it won't help if I spend years with basic software engineering tasks which any Joe programmer could complete easily. My private Lexiclone has several algorithms of which only GVerb has been turned to open source within four years. I'm not a reverb designer or DSP engineer either, and I'm not sure do I want be one. I started figuring out the reverb business with zero DSP knowledge, and only because we did not have a quality reverb -- I wanted to change the situation. Could we collect $$$$$ of money and hire Dattorro or any other qualified effect guru to design quality open source effects for us? Blender was purchased for $100,000, right? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From fons.adriaensen at skynet.be Wed Apr 19 16:11:48 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Wed Apr 19 16:04:31 2006 Subject: [linux-audio-dev] [OT] First trip to Europe In-Reply-To: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> References: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> Message-ID: <20060419201148.GA4800@linux-1> On Wed, Apr 19, 2006 at 05:39:01PM +0400, Dmitry Baikov wrote: > Moscow > St.Petersurg > -- > Helsinki > Stockholm > Berlin > Koeln > Brussels > London > Paris > Bourdeaux > Madrid > Barcelona,Figeras > Genova > Milan? > Rome > Venice > Vienna > Prague > -- > Moscow If you'd come to Antwerp (45 km from Brussels and a much nicer and friendlier place), I'd be happy to arrange a B&B in the city center, indicate the places to go and see, and offer a few (Belgian) beers. Both Germany and France have a rather efficient high-speed train system, both also spreading out to Belgium (Brussels and/or Antwerp). These are not the cheapest, but there are special period tickets etc. that you should look out for. There is also number of low- cost airlines operating over most of Europe, but watch out for the extra costs. If you take everything into account (i.e. transport between a city center and the not always very near airport), the HS trains are often cheaper. -- FA Follie! Follie! Delirio vano e' questo! From fons.adriaensen at skynet.be Wed Apr 19 18:12:29 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Wed Apr 19 18:04:54 2006 Subject: [linux-audio-dev] Ladspa rdf Message-ID: <20060419221229.GC4800@linux-1> A maybe silly question: where on a typical system are the rdf descriptions of ladspa plugins supposed to live ? I can't find them ! -- FA Follie! Follie! Delirio vano e' questo! From luisgarrido at users.sourceforge.net Wed Apr 19 18:23:06 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Wed Apr 19 18:23:11 2006 Subject: [linux-audio-dev] Ladspa rdf In-Reply-To: <20060419221229.GC4800@linux-1> References: <20060419221229.GC4800@linux-1> Message-ID: /usr[/local]/share/ladspa/rdf/ Cheers, Luis > A maybe silly question: where on a typical system are the rdf From kschutte at csail.mit.edu Thu Apr 20 00:13:39 2006 From: kschutte at csail.mit.edu (Ken Schutte) Date: Thu Apr 20 00:13:41 2006 Subject: [linux-audio-dev] jack and sampling rates Message-ID: <44470A73.7020508@csail.mit.edu> Hi, I've recently began trying to write a jack-enabled audio app, and have what's maybe a basic question... From what I can tell, jack has a single global sampling rate, and all clients are required to send and recieve at this rate. Is this correct? If so, are there standard tools/libs to do on-the-fly resampling? I'd like to have a client get a downsampled signal without having to implement my own anti-aliasing filter inside it. Even if there's not something to do the resampling for me, it would be neat if one client could do resampling and others that want the data could connect and get it... is it possible? thanks, Ken From dsbaikov at gmail.com Thu Apr 20 02:31:24 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 20 02:31:48 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: First trip to Europe In-Reply-To: <44470447.8050005@bigfoot.com> References: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> <44470447.8050005@bigfoot.com> Message-ID: <70a871c80604192331m2ad6644cj65b579e49e4e77e4@mail.gmail.com> Thank you all for you replies so far. Waiting for more ;) Need some time to analyse all info, but now some quick answers. Jens M Andreasen wrote: > Given the almost unbeliveable long list of places to visit ... :) You know, it's a plan. Flexible one. And for a month. And I don't think we'll travel again in a nearest year or so. Frank, thank you for invitation, but it's nearly impossible for us to be there at 18th of May. On Wednesday 19 April 2006 23:32, Carotinho was like: > Since when Russia is outside Europe?:) Geographically it is inside, but it's not that easy to get visa. It turns out we have to drop UK and Chezh since they are out of Schengen zone and need separate visas. Switzerland is not an option by the same reason. Still trying to figure out the easiest way to get visa. The country we get Schengen visa from should be the first country of our trip. Hope it will be Finland. But it may be France. Fons, thanks for your advice. Replaced Brussels with Antwerp. :) I hope we'll get there. Carotinho wrote: > Ehi, what's the "?" after Milan?:) Sorry, I know each country is very interesting and beautiful and needs a separate visit. But we want to get the "taste of europe" and look for places we'll want to study deeper. Kind regards, Dmitry. From dsbaikov at gmail.com Thu Apr 20 02:47:34 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 20 02:47:40 2006 Subject: [linux-audio-dev] jack and sampling rates In-Reply-To: <44470A73.7020508@csail.mit.edu> References: <44470A73.7020508@csail.mit.edu> Message-ID: <70a871c80604192347rc4ae268u34972836dafe5fbe@mail.gmail.com> http://www.mega-nerd.com/SRC/ Dmitry. From S.W.Harris at ecs.soton.ac.uk Thu Apr 20 03:02:00 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 20 03:02:26 2006 Subject: [linux-audio-dev] Ladspa rdf In-Reply-To: <20060419221229.GC4800@linux-1> References: <20060419221229.GC4800@linux-1> Message-ID: <20060420070200.GB2962@login.ecs.soton.ac.uk> On Thu, Apr 20, 2006 at 12:12:29 +0200, fons adriaensen wrote: > A maybe silly question: where on a typical system are the rdf > descriptions of ladspa plugins supposed to live ? > > I can't find them ! As the previous poster said, or in LADSPA_RDF_PATH. - Steve From fbar at footils.org Thu Apr 20 05:43:49 2006 From: fbar at footils.org (Frank Barknecht) Date: Thu Apr 20 05:44:01 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: First trip to Europe In-Reply-To: <70a871c80604192331m2ad6644cj65b579e49e4e77e4@mail.gmail.com> References: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> <44470447.8050005@bigfoot.com> <70a871c80604192331m2ad6644cj65b579e49e4e77e4@mail.gmail.com> Message-ID: <20060420094349.GB16889@fliwatut.scifi> Hallo, Dmitry Baikov hat gesagt: // Dmitry Baikov wrote: > Thank you all for you replies so far. Waiting for more ;) One additional advice: I guess you are aware, that the Soccer/Football world championship is happening in Germany in from June 9 to July 9. Depending on your preferences you may want to avoid Germany during that period, as probably most cheaper places to sleep will be very crowded. Also Germany will be a police state during that time, at least more so than usual. OTOH there also will be lots of helping hands for international travellers on the streets, trained in speaking many tongues. At least that's what was promised. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From pw_lists at slinkp.com Thu Apr 20 09:57:14 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 09:57:30 2006 Subject: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: References: <1140401605.16545.22.camel@localhost.localdomain> Message-ID: <20060420135714.GB9579@slinkp.com> I can understand not wanting to maintain it any more, but where'd the download go?? http://gazuga.net/files --> 404 -- Paul Winkler http://www.slinkp.com From ben at glw.com Thu Apr 20 11:01:32 2006 From: ben at glw.com (Ben Loftis) Date: Thu Apr 20 10:47:17 2006 Subject: [linux-audio-dev] NAB trade show In-Reply-To: <20060420135738.C542511913FE@music.columbia.edu> References: <20060420135738.C542511913FE@music.columbia.edu> Message-ID: <200604201001.32116.ben@glw.com> I am going to be at the NAB show in Las Vegas this week. Any other LAD's planning to be there? -Ben Loftis From pw_lists at slinkp.com Thu Apr 20 11:37:59 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 11:38:26 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <200604201704.45866.cave.dnb@tiscali.fr> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> Message-ID: <20060420153759.GC9579@slinkp.com> On Thu, Apr 20, 2006 at 05:04:45PM +0200, Nigel Henry wrote: > On Thursday 20 April 2006 15:57, Paul Winkler wrote: > > I can understand not wanting to maintain it any more, > > but where'd the download go?? > > http://gazuga.net/files --> 404 > > Hi Paul. I'd downloaded the tar.gz while it was still there. If you want it > I'll send it. > Nigel. Thanks, but it's not just me... the recently-mentioned proaudio overlay for gentoo included a specimen ebuild, which no longer works due to the 404 :-( Anybody care to host the tarball? -- Paul Winkler http://www.slinkp.com From pw_lists at slinkp.com Thu Apr 20 12:07:38 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 12:07:56 2006 Subject: [linux-audio-dev] RDF for CAPS plugins Message-ID: <20060420160738.GE9579@slinkp.com> Hiya, I'm having a hard time finding the plugins I want when using Ardour, particularly since the majority of plugins I have installed don't provide categories via RDF. So, hoping this is useful to others, attached is a minimal RDF for the CAPS suite, which I use a lot. This was generated by a quick python script, also attached; I just hand-edited the output to change the plugin types from UnknownPlugin. Wasn't sure what to do with the pan plugin. I also haven't bothered to figure out what to do with all the stuff about ports, and ardour doesn't seem to need it anyway, so this version of the script doesn't handle that. (Hey Steve, what's all that port info in your rdfs used for?) -- Paul Winkler http://www.slinkp.com -------------- next part -------------- A non-text attachment was scrubbed... Name: caps.rdf Type: application/rdf+xml Size: 8741 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060420/47ce5dfc/caps.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ladspa_rdf_gen.py Type: text/x-python Size: 2258 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060420/47ce5dfc/ladspa_rdf_gen.py From jstutters at jeremah.co.uk Thu Apr 20 12:19:30 2006 From: jstutters at jeremah.co.uk (Jonny Stutters) Date: Thu Apr 20 12:19:49 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <20060420153759.GC9579@slinkp.com> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> <20060420153759.GC9579@slinkp.com> Message-ID: <4447B492.2060003@jeremah.co.uk> Paul Winkler wrote: > On Thu, Apr 20, 2006 at 05:04:45PM +0200, Nigel Henry wrote: >> On Thursday 20 April 2006 15:57, Paul Winkler wrote: >>> I can understand not wanting to maintain it any more, >>> but where'd the download go?? >>> http://gazuga.net/files --> 404 >> Hi Paul. I'd downloaded the tar.gz while it was still there. If you want it >> I'll send it. >> Nigel. > > Thanks, but it's not just me... > the recently-mentioned proaudio overlay for gentoo included > a specimen ebuild, which no longer works due to the 404 :-( > > Anybody care to host the tarball? I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my disk) to: http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz I'm happy to host for the foreseeable future. If anyone's got a more recent copy let me know and I'll get that up as well. -- Jonny Music - http://jeremah.co.uk News - http://voxpolis.com From pw_lists at slinkp.com Thu Apr 20 12:30:34 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 12:33:04 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <4447B492.2060003@jeremah.co.uk> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> <20060420153759.GC9579@slinkp.com> <4447B492.2060003@jeremah.co.uk> Message-ID: <20060420163034.GF9579@slinkp.com> On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > disk) to: > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > I'm happy to host for the foreseeable future. If anyone's got a more > recent copy let me know and I'll get that up as well. Great! I found a copy of 0.5.1 on my drive. Email me privately if you want it. -- Paul Winkler http://www.slinkp.com From S.W.Harris at ecs.soton.ac.uk Thu Apr 20 13:10:35 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 20 13:10:56 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060420160738.GE9579@slinkp.com> References: <20060420160738.GE9579@slinkp.com> Message-ID: <20060420171035.GA32641@login.ecs.soton.ac.uk> On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul Winkler wrote: > I also haven't bothered to figure out what to do with all the stuff > about ports, and ardour doesn't seem to need it anyway, so this version > of the script doesn't handle that. (Hey Steve, what's all that port > info in your rdfs used for?) Not much, in theory you can use it to make dropdown type boxes for integer enumeration selectors, but I dont know if anyone does. - Steve From rzewnickie at rfa.org Thu Apr 20 13:20:07 2006 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Thu Apr 20 13:20:29 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <20060420163034.GF9579@slinkp.com> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> <20060420153759.GC9579@slinkp.com> <4447B492.2060003@jeremah.co.uk> <20060420163034.GF9579@slinkp.com> Message-ID: <20060420172007.GB3825@rfa.org> On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: > On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > > disk) to: > > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > > > I'm happy to host for the foreseeable future. If anyone's got a more > > recent copy let me know and I'll get that up as well. > > Great! > I found a copy of 0.5.1 on my drive. Email me privately if you want it. umm ... the download just worked for me ... That said, I agreed a while back to maintain the project after Pete announced his own death and the accompanying death of specimen. While Pete resurfaced as a zombie and promptly went over to the dark side, I have not yet found time to resurrect specimen (mainly due to my job and preparations for LAC06). I fully intend to have a new home for specimen shortly after the conference. In the meantime, there is a copy of 0.5.1 available here: http://zhevny.com/specimen/files/ tarball, rpm and src rpm are there. I will maintain this location as the home of specimen files, so feel free to point the ebuilds there. My sincere apologies for not taking steps sooner. -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network@rfa.org. From pw_lists at slinkp.com Thu Apr 20 13:21:12 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 13:22:13 2006 Subject: [linux-audio-dev] RDF for CMT, and slightly improved script In-Reply-To: <20060420160738.GE9579@slinkp.com> References: <20060420160738.GE9579@slinkp.com> Message-ID: <20060420172112.GH9579@slinkp.com> And here's some quick RDF for the CMT plugins, which greatly reduces the number of "Unknown" plugins on my system. Plus a slightly improved script (it takes the plugin filename as an argument now). For a couple of plugins I invented a "SynthesizerPlugin" and "SurroundPlugin", which are (not surprisingly) not recognized by Ardour. Is there a list somewhere of valid ladpsa RDF plugin types? I had a look around the lrdf project page on sourceforge and didn't find anything. -- Paul Winkler http://www.slinkp.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ladspa_rdf_gen.py Type: text/x-python Size: 2410 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060420/bd81453e/ladspa_rdf_gen-0001.py -------------- next part -------------- A non-text attachment was scrubbed... Name: cmt-plugins.rdf Type: application/rdf+xml Size: 21515 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060420/bd81453e/cmt-plugins-0001.bin From pw_lists at slinkp.com Thu Apr 20 13:25:52 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 13:26:31 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <20060420172007.GB3825@rfa.org> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> <20060420153759.GC9579@slinkp.com> <4447B492.2060003@jeremah.co.uk> <20060420163034.GF9579@slinkp.com> <20060420172007.GB3825@rfa.org> Message-ID: <20060420172552.GI9579@slinkp.com> On Thu, Apr 20, 2006 at 01:20:07PM -0400, Eric Dantan Rzewnicki wrote: > On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: > > On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > > > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > > > disk) to: > > > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > > > > > I'm happy to host for the foreseeable future. If anyone's got a more > > > recent copy let me know and I'll get that up as well. > > > > Great! > > I found a copy of 0.5.1 on my drive. Email me privately if you want it. > > > umm ... the download just worked for me ... ummm ... where? afaict it has been wiped off the face of gazuga.net. > That said, I agreed a while back to maintain the project after Pete > announced his own death and the accompanying death of specimen. While > Pete resurfaced as a zombie and promptly went over to the dark side, I > have not yet found time to resurrect specimen (mainly due to my job and > preparations for LAC06). > > I fully intend to have a new home for specimen shortly after the > conference. In the meantime, there is a copy of 0.5.1 available here: > http://zhevny.com/specimen/files/ > > tarball, rpm and src rpm are there. > > I will maintain this location as the home of specimen files, so > feel free to point the ebuilds there. Wonderful, thanks! -- Paul Winkler http://www.slinkp.com From pw_lists at slinkp.com Thu Apr 20 13:28:36 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 13:29:51 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060420171035.GA32641@login.ecs.soton.ac.uk> References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> Message-ID: <20060420172836.GL9579@slinkp.com> On Thu, Apr 20, 2006 at 06:10:35PM +0100, Steve Harris wrote: > On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul Winkler wrote: > > I also haven't bothered to figure out what to do with all the stuff > > about ports, and ardour doesn't seem to need it anyway, so this version > > of the script doesn't handle that. (Hey Steve, what's all that port > > info in your rdfs used for?) > > Not much, in theory you can use it to make dropdown type boxes for > integer enumeration selectors, but I dont know if anyone does. Ah, I vaguely recall discussion of that now. Too bad. Better auto-generated UIs for some plugins would be a wonderful thing. -- Paul Winkler http://www.slinkp.com From pedro.lopez.cabanillas at gmail.com Thu Apr 20 13:30:54 2006 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Thu Apr 20 13:31:27 2006 Subject: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <20060420135738.C542511913FE@music.columbia.edu> References: <20060420135738.C542511913FE@music.columbia.edu> Message-ID: <200604201930.54269.pedro.lopez.cabanillas@gmail.com> On Thursday, 20 de April de 2006 09:57:14 -0400, Paul Winkler wrote: > > I can understand not wanting to maintain it any more, > but where'd the download go?? > http://gazuga.net/files ?--> 404 Here are the last files: http://gazuga.net/specimen/files/ And here some old ones: http://gazuga.net/specimen/oldfiles/ There is a pointer from the 'downloads' page: http://gazuga.net/specimen/downloads.php Or I'm not understanding your question? Regards, Pedro From taybin at earthlink.net Thu Apr 20 13:34:13 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Apr 20 13:34:20 2006 Subject: [linux-audio-dev] RDF for CMT, and slightly improved script Message-ID: <2065465.1145554453997.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> I thought SWH had already provided an RDF file for the CMT plugins. Does yours have more detail? Taybin -----Original Message----- >From: Paul Winkler >Sent: Apr 20, 2006 1:21 PM >To: The Linux Audio Developers' Mailing List >Subject: [linux-audio-dev] RDF for CMT, and slightly improved script > >And here's some quick RDF for the CMT plugins, which greatly >reduces the number of "Unknown" plugins on my system. > >Plus a slightly improved script (it takes the plugin filename as an >argument now). > >For a couple of plugins I invented a "SynthesizerPlugin" and >"SurroundPlugin", which are (not surprisingly) not recognized by Ardour. > >Is there a list somewhere of valid ladpsa RDF plugin types? I had a >look around the lrdf project page on sourceforge and didn't find >anything. > >-- > >Paul Winkler >http://www.slinkp.com From pw_lists at slinkp.com Thu Apr 20 13:49:19 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 13:49:36 2006 Subject: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <200604201930.54269.pedro.lopez.cabanillas@gmail.com> References: <20060420135738.C542511913FE@music.columbia.edu> <200604201930.54269.pedro.lopez.cabanillas@gmail.com> Message-ID: <20060420174919.GN9579@slinkp.com> On Thu, Apr 20, 2006 at 07:30:54PM +0200, Pedro Lopez-Cabanillas wrote: > On Thursday, 20 de April de 2006 09:57:14 -0400, Paul Winkler wrote: > > > > I can understand not wanting to maintain it any more, > > but where'd the download go?? > > http://gazuga.net/files ?--> 404 > > Here are the last files: > http://gazuga.net/specimen/files/ > > And here some old ones: > http://gazuga.net/specimen/oldfiles/ > > There is a pointer from the 'downloads' page: > http://gazuga.net/specimen/downloads.php > > Or I'm not understanding your question? Aha. I didn't happen to find any links to gazuga.net/specimen, only to either the gazuga.net front page (which no longer mentions specimen) or stale links to stuff under gazuga.net/files which is 404. Never mind. Sorry to disturb your eternal slumber, RIP. -- Paul Winkler http://www.slinkp.com From pw_lists at slinkp.com Thu Apr 20 13:53:22 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 13:53:35 2006 Subject: [linux-audio-dev] RDF for CMT, and slightly improved script In-Reply-To: <2065465.1145554453997.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> References: <2065465.1145554453997.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Message-ID: <20060420175322.GO9579@slinkp.com> On Thu, Apr 20, 2006 at 01:34:13PM -0400, Taybin Rutkin wrote: > I thought SWH had already provided an RDF file for the CMT plugins. Does yours have more detail? Interesting... no such thing comes with cmt 1.15. Where'd you see that? Detail - no. Mine is almost nothing but categorization. You're not thinking of steve's swh plugins, are you? That one comes with rdf aplenty. -- Paul Winkler http://www.slinkp.com From rzewnickie at rfa.org Thu Apr 20 14:34:49 2006 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Thu Apr 20 14:35:18 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <20060420172552.GI9579@slinkp.com> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> <20060420153759.GC9579@slinkp.com> <4447B492.2060003@jeremah.co.uk> <20060420163034.GF9579@slinkp.com> <20060420172007.GB3825@rfa.org> <20060420172552.GI9579@slinkp.com> Message-ID: <20060420183449.GC3825@rfa.org> On Thu, Apr 20, 2006 at 01:25:52PM -0400, Paul Winkler wrote: > On Thu, Apr 20, 2006 at 01:20:07PM -0400, Eric Dantan Rzewnicki wrote: > > On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: > > > On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > > > > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > > > > disk) to: > > > > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > > > > > > > I'm happy to host for the foreseeable future. If anyone's got a more > > > > recent copy let me know and I'll get that up as well. > > > > > > Great! > > > I found a copy of 0.5.1 on my drive. Email me privately if you want it. > > > > > > umm ... the download just worked for me ... > > ummm ... where? > afaict it has been wiped off the face of gazuga.net. http://gazuga.net/specimen/files/ works for me ... can't imagine what would make it not work for you. But, anyway ... specimen has begun moving (if only slowly) to its new home. Maybe this is some sort of bizarre zombie communication system that indirectly says "Give that Eric person a kick so I can get this stuff from my past life off my server." -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network@rfa.org. From pshirkey at boosthardware.com Thu Apr 20 15:30:12 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Thu Apr 20 15:30:57 2006 Subject: [linux-audio-dev] LADSPA Repository Message-ID: <4447E144.3000900@boosthardware.com> Hi, It is widely felt that the LADSPA plugins are becoming difficult for average users to manage due to the number of available plugins and the many different packages available. There is also a problem that developers face when managing different plugins as UniqueIds are not assigned by a central authority so it is possible that there can be double ups. I am volunteering my time to code a new web portal with the express purpose of providing a single place to get all known LADSPA plugins and packages. It will be hosted at ladspa.linuxaudio.org. it will also serve as a central automated authority for assigning UniqueIds. I would like to use this thread to discuss the finer details of the functionality of the site and how to make a package of all Plugins which will also be hosted on the site. The site will be run with a MYSQL DB. I intend to code it in AJAX style with a PHP+MYSQL backend. It will be a fully automated web portal and administrative interface. Here are the features: --------------- - Add new plugin/s via batch or manual upload/insert - Automated assigning of UniqueIds - Create complete package tarball automatically - Administrative interface for managing plugins and developer profiles etc... - User friendly frontend with accessibility: css, java, php, html, xml ---------------- I will appreciate your indepth analysis of the best methods to allow the above features for the portal. At this stage the most important points to discuss are how to manage the plugins efficiently and with minimal overhead and assigning UniqueIds automatically. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From larsl at users.sourceforge.net Thu Apr 20 15:48:18 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Thu Apr 20 15:48:25 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <4447E144.3000900@boosthardware.com> References: <4447E144.3000900@boosthardware.com> Message-ID: <1145562498.8827.15.camel@localhost> On Fri, 2006-04-21 at 02:30 +0700, Patrick Shirkey wrote: > It is widely felt that the LADSPA plugins are becoming difficult for > average users to manage due to the number of available plugins and the > many different packages available. > > There is also a problem that developers face when managing different > plugins as UniqueIds are not assigned by a central authority so it is > possible that there can be double ups. > > I am volunteering my time to code a new web portal with the express > purpose of providing a single place to get all known LADSPA plugins and > packages. It will be hosted at ladspa.linuxaudio.org. it will also serve > as a central automated authority for assigning UniqueIds. > > I would like to use this thread to discuss the finer details of the > functionality of the site and how to make a package of all Plugins which > will also be hosted on the site. The site will be run with a MYSQL DB. I > intend to code it in AJAX style with a PHP+MYSQL backend. > > It will be a fully automated web portal and administrative interface. > > Here are the features: > --------------- > - Add new plugin/s via batch or manual upload/insert > - Automated assigning of UniqueIds > - Create complete package tarball automatically > > - Administrative interface for managing plugins and developer profiles > etc... > - User friendly frontend with accessibility: css, java, php, html, xml > ---------------- > > I will appreciate your indepth analysis of the best methods to allow the > above features for the portal. At this stage the most important points > to discuss are how to manage the plugins efficiently and with minimal > overhead and assigning UniqueIds automatically. How about a machine-friendly interface for searching and downloading plugin tarballs (or references to distribution packages) so one could write a tool like CPAN for LADSPAs? An automated way to download and install plugins would be really useful if it could be integrated into software like Om, Ardour, JACK-rack etc. Scenario: you try to load a new Om patch that you downloaded from the net, you get the message "You don't have the 'foo' plugin, do you want to install it?", click Yes, and a few seconds (or minutes) later the plugin is installed and the patch is loaded. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060420/ed2136c8/attachment.bin From rlrevell at joe-job.com Thu Apr 20 16:01:17 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Apr 20 16:01:23 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <1145562498.8827.15.camel@localhost> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> Message-ID: <1145563277.5412.17.camel@mindpipe> On Thu, 2006-04-20 at 21:48 +0200, Lars Luthman wrote: > How about a machine-friendly interface for searching and downloading > plugin tarballs (or references to distribution packages) so one could > write a tool like CPAN for LADSPAs? Wouldn't this have the same problem of poor integration with the distro's package management that CPAN has? How about just getting the distros to package all the useful plugins? Lee From pedro.lopez.cabanillas at gmail.com Thu Apr 20 16:01:30 2006 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Thu Apr 20 16:02:02 2006 Subject: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <20060420193103.058E611A45BD@music.columbia.edu> References: <20060420193103.058E611A45BD@music.columbia.edu> Message-ID: <200604202201.31006.pedro.lopez.cabanillas@gmail.com> On Thursday, 20 de April de 2006 13:49:19 -0400, Paul Winkler wrote: > > Sorry to disturb your eternal slumber, RIP. You are burying the wrong guy. It was Pete Bessman who lived fast, died young, and left a good-looking corpse behind. Regards, Pedro From larsl at users.sourceforge.net Thu Apr 20 16:08:55 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Thu Apr 20 16:09:01 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <1145563277.5412.17.camel@mindpipe> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> <1145563277.5412.17.camel@mindpipe> Message-ID: <1145563735.8827.21.camel@localhost> On Thu, 2006-04-20 at 16:01 -0400, Lee Revell wrote: > On Thu, 2006-04-20 at 21:48 +0200, Lars Luthman wrote: > > How about a machine-friendly interface for searching and downloading > > plugin tarballs (or references to distribution packages) so one could > > write a tool like CPAN for LADSPAs? > > Wouldn't this have the same problem of poor integration with the > distro's package management that CPAN has? How about just getting the > distros to package all the useful plugins? Thus the references to distribution packages. You could query this hypothetical LADSPA database for the name of the Mandriva package that contains the "chief executive oscillator" plugin (caps) or the name of the Gentoo ebuild for the Mvclpf-4 plugin (mcp-plugins) or, as a fallback, the URL to a source tarball for a plugin. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060420/685a0bc1/attachment.bin From pw_lists at slinkp.com Thu Apr 20 16:16:02 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 16:16:19 2006 Subject: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <200604202201.31006.pedro.lopez.cabanillas@gmail.com> References: <20060420193103.058E611A45BD@music.columbia.edu> <200604202201.31006.pedro.lopez.cabanillas@gmail.com> Message-ID: <20060420201602.GA26945@slinkp.com> On Thu, Apr 20, 2006 at 10:01:30PM +0200, Pedro Lopez-Cabanillas wrote: > On Thursday, 20 de April de 2006 13:49:19 -0400, Paul Winkler wrote: > > > > Sorry to disturb your eternal slumber, RIP. > > You are burying the wrong guy. It was Pete Bessman who lived fast, died young, > and left a good-looking corpse behind. > > Regards, > Pedro Apologies. I take it you're not dead then? -- Paul Winkler http://www.slinkp.com From tim at quitte.de Thu Apr 20 16:51:20 2006 From: tim at quitte.de (Tim Goetze) Date: Thu Apr 20 16:53:59 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060420172836.GL9579@slinkp.com> References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> Message-ID: [Paul Winkler] >On Thu, Apr 20, 2006 at 06:10:35PM +0100, Steve Harris wrote: >> On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul Winkler wrote: >> > I also haven't bothered to figure out what to do with all the stuff >> > about ports, and ardour doesn't seem to need it anyway, so this version >> > of the script doesn't handle that. (Hey Steve, what's all that port >> > info in your rdfs used for?) >> >> Not much, in theory you can use it to make dropdown type boxes for >> integer enumeration selectors, but I dont know if anyone does. > >Ah, I vaguely recall discussion of that now. > >Too bad. Better auto-generated UIs for some plugins would be a wonderful >thing. The 0.3.0 CAPS release actually comes with an rdf file supposed to label the enumerated int ports (the Cabinet model switches and the SweepVF filter modes). I haven't tried it myself but as it was provided by someone who's using CAPS mainly in ardour I supposed it should work -- or does it not? Re: caps.rdf in general -- Paul, your permission assumed I'll recycle some of your python code, to be run when making the CAPS 'dist' target. A better caps.rdf will thus be in 0.3.1 (coming to a theatre near you sometime this year). Steve, are the dc:creator, dc:rights, dc:title tags necessary? Paul's caps.rdf simply copies the data found in caps.so -- is it possible to simply eliminate this redundancy? Cheers, Tim From pw_lists at slinkp.com Thu Apr 20 18:28:48 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 18:29:03 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> Message-ID: <20060420222847.GB26945@slinkp.com> On Thu, Apr 20, 2006 at 10:51:20PM +0200, Tim Goetze wrote: > The 0.3.0 CAPS release actually comes with an rdf file supposed to > label the enumerated int ports (the Cabinet model switches and the > SweepVF filter modes). Argh! I already had 0.3.0, but apparently the gentoo ebuild fails to install the rdf file. I'll file a gentoo bug. I merged yours with mine and yep, it works - now I get both categorization and useful dropdown widgets on those four plugins. Yay! btw, the guy that wrote yours didn't apparently understand how the categories work. I had it mostly right by copying other files, but I just now stumbled on where the taxonomy is actually defined, it's at: /usr/share/ladspa/rdf/ladspa.rdfs ... which apparently comes with liblrdf. > Re: caps.rdf in general -- > > Paul, your permission assumed I'll recycle some of your python code, > to be run when making the CAPS 'dist' target. A better caps.rdf will > thus be in 0.3.1 (coming to a theatre near you sometime this year). Of course. It should be possible to stub out the rdf for enumerated parameters by looking at the "ports:" output of analyseplugin. That might be handy. > Steve, are the dc:creator, dc:rights, dc:title tags necessary? Paul's > caps.rdf simply copies the data found in caps.so -- is it possible to > simply eliminate this redundancy? dc (dublin core) metadata is generally optional. I just put those in without thinking because it was easy to parse out. I like having at least the title, it makes the rdf much more human-readable. -- Paul Winkler http://www.slinkp.com From tim at quitte.de Thu Apr 20 19:17:52 2006 From: tim at quitte.de (Tim Goetze) Date: Thu Apr 20 19:20:55 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060420222847.GB26945@slinkp.com> References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> <20060420222847.GB26945@slinkp.com> Message-ID: [Paul Winkler] >On Thu, Apr 20, 2006 at 10:51:20PM +0200, Tim Goetze wrote: >> The 0.3.0 CAPS release actually comes with an rdf file supposed to >> label the enumerated int ports (the Cabinet model switches and the >> SweepVF filter modes). > >Argh! I already had 0.3.0, but apparently the gentoo ebuild fails to >install the rdf file. I'll file a gentoo bug. rdf-install is a separate make target, that makes it easy to overlook I guess. >I merged yours with mine and yep, it works - now I get both >categorization and useful dropdown widgets on those four plugins. >Yay! Good. The proposed 0.3.1 caps.rdf will more or less be the same merge. >btw, the guy that wrote yours didn't apparently understand >how the categories work. I had it mostly right by copying >other files, but I just now stumbled on where the taxonomy is >actually defined, it's at: > >/usr/share/ladspa/rdf/ladspa.rdfs > >... which apparently comes with liblrdf. Or here: http://plugin.org.uk/lrdf/examples/ladspa.rdfs One thing I don't understand about this lrdf business is how you type (or generate) a line that reads when http://ladspa.org/ontology is (and has been for some time) a 404. In any event, I'll make sure the plugin types are properly assigned. >It should be possible to stub out the rdf for enumerated parameters by >looking at the "ports:" output of analyseplugin. That might be handy. There's some old code I keep around that runs ladspa plugins under python control (that's how the port info, cpu usage and impulse/frequency response figures for caps.pdf are generated). It comes with full python access to the port definitions, so it should be rather easy to generate the rdf port info along with it. >> Steve, are the dc:creator, dc:rights, dc:title tags necessary? Paul's >> caps.rdf simply copies the data found in caps.so -- is it possible to >> simply eliminate this redundancy? > >dc (dublin core) metadata is generally optional. >I just put those in without thinking because it was easy to parse out. >I like having at least the title, it makes the rdf much more >human-readable. True. But this should be valid xml/rdf too: Alas, humanely commented code has always been a rare commodity ... :)) Cheers, Tim From kjetil at ccrma.stanford.edu Thu Apr 20 20:12:06 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Apr 20 20:12:13 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060420232055.B3FED11B0345@music.columbia.edu> References: <20060420232055.B3FED11B0345@music.columbia.edu> Message-ID: Tim Goetze: > Alas, humanely commented code has always been a rare commodity ... :)) Nope, code that needs to be commented is bad code. (most of my code is, by the way) From taybin at earthlink.net Thu Apr 20 20:12:53 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Apr 20 20:13:27 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> <20060420222847.GB26945@slinkp.com> Message-ID: <9B130EC2-C3C8-4DED-84C9-EA9A834A78FF@earthlink.net> On Apr 20, 2006, at 7:17 PM, Tim Goetze wrote: > One thing I don't understand about this lrdf business is how you type > (or generate) a line that reads > > ladspa:hasLabel="Time"> > > when http://ladspa.org/ontology is (and has been for some time) a 404. The URI doesn't have to resolve. It's more a promise that it's a unique name because presumably, you own the domain name. Taybin From pw_lists at slinkp.com Thu Apr 20 21:05:35 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 20 21:05:56 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <9B130EC2-C3C8-4DED-84C9-EA9A834A78FF@earthlink.net> References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> <20060420222847.GB26945@slinkp.com> <9B130EC2-C3C8-4DED-84C9-EA9A834A78FF@earthlink.net> Message-ID: <20060421010535.GA27988@slinkp.com> On Thu, Apr 20, 2006 at 08:12:53PM -0400, Taybin Rutkin wrote: > On Apr 20, 2006, at 7:17 PM, Tim Goetze wrote: > > >One thing I don't understand about this lrdf business is how you type > >(or generate) a line that reads > > > > >ladspa:hasLabel="Time"> > > > >when http://ladspa.org/ontology is (and has been for some time) a 404. > > The URI doesn't have to resolve. It's more a promise that it's a > unique name because presumably, you own the domain name. Yep, that's something that took me a long time to accept about XML. URIs are used as namespaces all over the place, and they very often don't resolve to anything. You get used to it eventually :-P OTOH, it's pretty obvious why this is the case. Imagine if it *did* have to resolve to something. What would that mean? it only works when the server's up? (and DNS, and the end user's internet connection, and and and...) That would suck so bad. -- Paul Winkler http://www.slinkp.com From taybin at earthlink.net Thu Apr 20 23:22:23 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Apr 20 23:22:51 2006 Subject: [linux-audio-dev] Summer of Code In-Reply-To: <1145132595.12398.4.camel@DaveLap> References: <20060415200916.GA21956@falcon.fugal.net> <1145132595.12398.4.camel@DaveLap> Message-ID: <8057D943-FBE9-40F0-8792-89E245656BD5@earthlink.net> On Apr 15, 2006, at 4:23 PM, Dave Robillard wrote: > On Sat, 2006-04-15 at 14:09 -0600, Hans Fugal wrote: >> Google's Summer of Code is upon us. I have a summer without classes >> coming up and I can think of nothing better to do (besides >> studying for >> qualifying exams) than to hack on a Linux Audio project and get >> paid for >> it, benefitting that project with code and money ($500). Is any >> project, >> or perhaps the LAD community as a whole, applying for mentorship? >> >> http://code.google.com/summerofcode.html >> >> Ardour comes to mind as being a good mentor organization candidate. > > I would love to get in on the summer of code as well. Maybe a few > of us > can team up and take on something substantial? (Ardour MIDI?) Ardour has been accepted as a mentoring project. Teams are not allowed though. See http://ardour.org/summerofcode2006 for project ideas, or come up with your own. Taybin From taybin at earthlink.net Thu Apr 20 23:23:51 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Apr 20 23:24:29 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <4447E144.3000900@boosthardware.com> References: <4447E144.3000900@boosthardware.com> Message-ID: On Apr 20, 2006, at 3:30 PM, Patrick Shirkey wrote: > > I am volunteering my time to code a new web portal with the express > purpose of providing a single place to get all known LADSPA plugins > and packages. It will be hosted at ladspa.linuxaudio.org. it will > also serve as a central automated authority for assigning UniqueIds. I recommend http://drupal.org as a good codebase to start off of. Taybin From taybin at earthlink.net Thu Apr 20 23:26:27 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Apr 20 23:26:42 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060421010535.GA27988@slinkp.com> References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> <20060420222847.GB26945@slinkp.com> <9B130EC2-C3C8-4DED-84C9-EA9A834A78FF@earthlink.net> <20060421010535.GA27988@slinkp.com> Message-ID: On Apr 20, 2006, at 9:05 PM, Paul Winkler wrote: > OTOH, it's pretty obvious why this is the case. Imagine if it *did* > have > to resolve to something. What would that mean? it only works when the > server's up? (and DNS, and the end user's internet connection, and and > and...) That would suck so bad. I wonder why people include the protocol though? Using a java style reverse DNS would have worked just fine: org.ladspa.ontology would have made sense too. Taybin From asbjs at stud.ntnu.no Fri Apr 21 02:58:13 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Fri Apr 21 02:58:32 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <1145563277.5412.17.camel@mindpipe> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> <1145563277.5412.17.camel@mindpipe> Message-ID: <20060421065813.GA29098@stud.ntnu.no> On Thu, Apr 20, 2006 at 04:01:17PM -0400, Lee Revell wrote: > On Thu, 2006-04-20 at 21:48 +0200, Lars Luthman wrote: > > How about a machine-friendly interface for searching and downloading > > plugin tarballs (or references to distribution packages) so one could > > write a tool like CPAN for LADSPAs? > > Wouldn't this have the same problem of poor integration with the > distro's package management that CPAN has? How about just getting the > distros to package all the useful plugins? Amen! Asbj?rn From Jan.Weil at web.de Fri Apr 21 03:14:46 2006 From: Jan.Weil at web.de (Jan Weil) Date: Fri Apr 21 03:14:54 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <1145562498.8827.15.camel@localhost> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> Message-ID: <1145603686.4773.5.camel@localhost.localdomain> Am Donnerstag, den 20.04.2006, 21:48 +0200 schrieb Lars Luthman: > How about a machine-friendly interface for searching and downloading > plugin tarballs (or references to distribution packages) so one could > write a tool like CPAN for LADSPAs? An automated way to download and > install plugins would be really useful if it could be integrated into > software like Om, Ardour, JACK-rack etc. Scenario: you try to load a new > Om patch that you downloaded from the net, you get the message "You > don't have the 'foo' plugin, do you want to install it?", click Yes, and > a few seconds (or minutes) later the plugin is installed and the patch > is loaded. AFAIK most plugins don't have any dependencies. Is there anything wrong with distributing them in binary form as a convenience? Just drop them somewhere in your LADSPA_PATH and you're done. That's what plugins are meant for, no? From chris.cannam at ferventsoftware.com Fri Apr 21 04:51:32 2006 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Apr 21 04:54:47 2006 Subject: [linux-audio-dev] RDF for CAPS plugins Message-ID: <938019494-1145609677-cardhu_blackberry.rim.net-19597-@engine20.bwc.produk.on.blackberry> Paul Winkler: > OTOH, it's pretty obvious why this is the case. > Imagine if it *did* have to resolve to something. > What would that mean? That's a slightly perplexing detail even with the situation as it is. What if the URI *does* resolve as a URL? Would a host that looked up the URL and did something with the results (doesn't matter what, but let's imagine that the host defines the thing it will do and does it consistently) be committing a fundamental error? Chris From larsl at users.sourceforge.net Fri Apr 21 05:53:12 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Fri Apr 21 05:53:19 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <20060420172007.GB3825@rfa.org> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> <20060420153759.GC9579@slinkp.com> <4447B492.2060003@jeremah.co.uk> <20060420163034.GF9579@slinkp.com> <20060420172007.GB3825@rfa.org> Message-ID: <1145613192.8855.10.camel@localhost> On Thu, 2006-04-20 at 13:20 -0400, Eric Dantan Rzewnicki wrote: > On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: > > On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > > > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > > > disk) to: > > > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > > > > > I'm happy to host for the foreseeable future. If anyone's got a more > > > recent copy let me know and I'll get that up as well. > > > > Great! > > I found a copy of 0.5.1 on my drive. Email me privately if you want it. > umm ... the download just worked for me ... > > That said, I agreed a while back to maintain the project after Pete > announced his own death and the accompanying death of specimen. While > Pete resurfaced as a zombie and promptly went over to the dark side, I > have not yet found time to resurrect specimen (mainly due to my job and > preparations for LAC06). Great to hear that you are going to maintain it. When you start looking into it, could you also have a look at the LASH and JACK MIDI patches for it? It would be very nice to have those in the official releases. The JACK MIDI patch is here (it adds a JACK MIDI input port that can be used at the same time as the ALSA-seq port): http://www.student.nada.kth.se/~d00-llu/code_patches/specimen-jackmidi-051205.diff Dave Robillard's LASH patch is here: http://www.scs.carleton.ca/~drobilla/files/specimen-lash.patch I think both applied to 0.5.1 and the last CVS version I tested. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060421/ca701572/attachment.bin From S.W.Harris at ecs.soton.ac.uk Fri Apr 21 07:21:06 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 21 07:21:37 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060420222847.GB26945@slinkp.com> References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> <20060420222847.GB26945@slinkp.com> Message-ID: <20060421112106.GB6885@login.ecs.soton.ac.uk> On Thu, Apr 20, 2006 at 06:28:48 -0400, Paul Winkler wrote: > > Steve, are the dc:creator, dc:rights, dc:title tags necessary? Paul's > > caps.rdf simply copies the data found in caps.so -- is it possible to > > simply eliminate this redundancy? > > dc (dublin core) metadata is generally optional. > I just put those in without thinking because it was easy to parse out. > I like having at least the title, it makes the rdf much more > human-readable. Parsing it out is a non-issue, its ignored unless you ask about it, and I agree. I mostly included stuff like that becasue the way LADSPA embeds data in the .so is wierd/wrong/underspecifed/anoying [delete as applicable]. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 21 07:28:18 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 21 07:29:01 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> <20060420222847.GB26945@slinkp.com> <9B130EC2-C3C8-4DED-84C9-EA9A834A78FF@earthlink.net> <20060421010535.GA27988@slinkp.com> Message-ID: <20060421112818.GC6885@login.ecs.soton.ac.uk> On Thu, Apr 20, 2006 at 11:26:27 -0400, Taybin Rutkin wrote: > On Apr 20, 2006, at 9:05 PM, Paul Winkler wrote: > > >OTOH, it's pretty obvious why this is the case. Imagine if it *did* > >have > >to resolve to something. What would that mean? it only works when the > >server's up? (and DNS, and the end user's internet connection, and and > >and...) That would suck so bad. > > I wonder why people include the protocol though? Using a java style > reverse DNS would have worked just fine: > > org.ladspa.ontology would have made sense too. Heh, that's a whole long argument. In brief: I should have put a copy of the ontology there (I meant to, just never got round to it), and that means that if/when a human finds a ladspa rdf file in the wild, they can type it in the namespace and find a copy of the ontology (with human readable notes in it) that explains what it is. If you use a tag: URI, or something else unresolvable then you dont have the option to look it up, ever. But, if you use HTTP then you can put something there, should you want to. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 21 07:29:53 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 21 07:30:54 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <938019494-1145609677-cardhu_blackberry.rim.net-19597-@engine20.bwc.produk.on.blackberry> References: <938019494-1145609677-cardhu_blackberry.rim.net-19597-@engine20.bwc.produk.on.blackberry> Message-ID: <20060421112953.GD6885@login.ecs.soton.ac.uk> On Fri, Apr 21, 2006 at 08:51:32 +0000, Chris Cannam wrote: > Paul Winkler: > > OTOH, it's pretty obvious why this is the case. > > Imagine if it *did* have to resolve to something. > > What would that mean? > > That's a slightly perplexing detail even with the > situation as it is. What if the URI *does* resolve as > a URL? Would a host that looked up the URL and did > something with the results (doesn't matter what, but > let's imagine that the host defines the thing it will do > and does it consistently) be committing a fundamental error? There is no particular reason for a machine to ever resolve that URI, it's just an identifier, but a human might well want to. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 21 07:39:00 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 21 07:39:22 2006 Subject: [linux-audio-dev] RDF for CMT, and slightly improved script In-Reply-To: <20060420172112.GH9579@slinkp.com> References: <20060420160738.GE9579@slinkp.com> <20060420172112.GH9579@slinkp.com> Message-ID: <20060421113900.GE6885@login.ecs.soton.ac.uk> On Thu, Apr 20, 2006 at 01:21:12 -0400, Paul Winkler wrote: > And here's some quick RDF for the CMT plugins, which greatly > reduces the number of "Unknown" plugins on my system. > > Plus a slightly improved script (it takes the plugin filename as an > argument now). > > For a couple of plugins I invented a "SynthesizerPlugin" and > "SurroundPlugin", which are (not surprisingly) not recognized by Ardour. > > Is there a list somewhere of valid ladpsa RDF plugin types? I had a > look around the lrdf project page on sourceforge and didn't find > anything. The list of default types is in the ontology file (ladspa.rdfs), but you can just declare new ones in a file ships with the plugins, as in: eg. in swh-aux.rdf I declare SpectralPlugin and NotchPlugin, which I needed, but aren't in ladspa.rdfs. The nearest to Synthesiser is Generator, which is far from a good name. The list of types was just hacked out by yours truely one afternoon, and its both overspecified in some ways, and underspecified in others. It could do with an overhaul. - Steve From pcoccoli at gmail.com Fri Apr 21 13:25:37 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Fri Apr 21 13:25:43 2006 Subject: [linux-audio-dev] [OT] gtkmm question Message-ID: <8d27a0610604211025x406bf990tddc9b49efcdabc7d@mail.gmail.com> Does anyone know how to set the value of a CheckButton or slider ({H|V}Scale) WITHOUT causing it to emit a signal (i.e. call the connected callback)? For the CheckButton, the set_value() method causes signal_toggled to be emitted (that's what I don't want to happen). I looked at the reference docs but I don't see anything in there. There must be way, I'm just too dense to figure it out... From patrickkidd.lists at gmail.com Fri Apr 21 14:34:32 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Fri Apr 21 14:34:42 2006 Subject: [linux-audio-dev] music engine In-Reply-To: <664bf2b80604111037x61814286t118894f156dc72d6@mail.gmail.com> References: <664bf2b80604060514w2979b330y6435eef532912ef7@mail.gmail.com> <20060406162513.GA16158@riyal.ugcs.caltech.edu> <664bf2b80604101222s53edc2f4ie246b2c46c917201@mail.gmail.com> <1144769363.11377.2.camel@localhost.localdomain> <664bf2b80604111037x61814286t118894f156dc72d6@mail.gmail.com> Message-ID: <664bf2b80604211134s3bc186bas4eeeef829c393fa5@mail.gmail.com> After some searching I found that supercollider is what I was looking for, and a whole lot more. I posted a message similar to this one to sc-users and sc-dev and put together a python OSC lib for supercollider, which now meets my requirements. I also recently posted a setup script for pysclang, which makes supercollider a lot more interesting from python. Go check it out if you are intersted. there are independent test scripts that will get you sound right away, and its python, so its easy to read. scosc: https://svn.patrickkidd.com/ On 4/11/06, Patrick Stinson wrote: > So I suppose ew should all be moving towards OSC for our communication > protocols? That means I could be spewing OSC through my pipes: > > pksampler | pkaudiod | pkvumeter > > On 4/11/06, Alberto Botti wrote: > > Il giorno lun, 10/04/2006 alle 11.22 -0800, Patrick Stinson ha scritto: > > > I'm running OS X, and would like to keep my compile-time dependencies > > > down. Is it possible to get gdam-server running w/o gtk+? libxml is > > > not too bad, but gtk+ requires quite a bit of stuff. > > > > GDAM needs GTK+ 1.2, not the more recent GTK+ 2.0. Even the non-gui > > server code needs GTK (the object system was split from GTK into GLib in > > GTK 2.0) > > > > > > > -- > Patrick Kidd Stinson > http://www.patrickkidd.com/ > http://pkaudio.sourceforge.net/ > http://pksampler.sourceforge.net/ > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From torbenh at gmx.de Sat Apr 22 04:35:06 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sat Apr 22 04:38:44 2006 Subject: [linux-audio-dev] (i have problems with my Network link) Need testers for the performance of 24ch netjack connections Message-ID: <20060422083506.GA10762@mobilat> hi... roger i am CCing you because a) i think the problems are via-rhines fault in 2.6.16 b) this software reproducibly triggers something have not seen before i need people who test the new fragmentation code in netjack-0.12. i think i am seeing kernel problems, because there are patches going on for the via-rhine driver. it looks like the huge packet load triggers some sort of bug in the via-rhine network driver. Because after using netjack for some seconds, the link is broken. (this is reproducible with 2.6.16) "ifconfig eth0 down; ifconfig eth0 up" fixes it again. i dont think that the results i am getting are reliable. So i am asking you to test it. please check out http://netjack.sf.net/netjack-0.12test1.tar.bz2 compile as usual with: bash# scons jack_source_dir= then on the master with normal jackd running: bash# jacknet_client -p -P 24 -C 24 on the bash# jackd -R -d net -C 24 -P 24 please note that -r and -p on jackd -d net are no more needed and autodetected. i would also be interested in OSX results of the old netjack-0.11 for OSX compilation add "with-alsa=0" -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From tim at quitte.de Sat Apr 22 05:29:04 2006 From: tim at quitte.de (Tim Goetze) Date: Sat Apr 22 05:31:47 2006 Subject: [linux-audio-dev] RDF for CAPS plugins In-Reply-To: <20060421112818.GC6885@login.ecs.soton.ac.uk> References: <20060420160738.GE9579@slinkp.com> <20060420171035.GA32641@login.ecs.soton.ac.uk> <20060420172836.GL9579@slinkp.com> <20060420222847.GB26945@slinkp.com> <9B130EC2-C3C8-4DED-84C9-EA9A834A78FF@earthlink.net> <20060421010535.GA27988@slinkp.com> <20060421112818.GC6885@login.ecs.soton.ac.uk> Message-ID: [Steve Harris] >On Thu, Apr 20, 2006 at 11:26:27 -0400, Taybin Rutkin wrote: >> I wonder why people include the protocol though? Using a java style >> reverse DNS would have worked just fine: >> >> org.ladspa.ontology would have made sense too. > >Heh, that's a whole long argument. In brief: I should have put a copy of >the ontology there (I meant to, just never got round to it), and that >means that if/when a human finds a ladspa rdf file in the wild, they can >type it in the namespace and find a copy of the ontology (with human >readable notes in it) that explains what it is. Which na?ve me was expecting to find. A LADSPA ontology ... I love the idea. >If you use a tag: URI, or something else unresolvable then you dont have >the option to look it up, ever. But, if you use HTTP then you can put >something there, should you want to. Please don't take it off your list of things to do. Cheers, Tim From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 05:53:58 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 05:54:25 2006 Subject: [linux-audio-dev] LADSPA 2 Message-ID: <20060422095358.GD715@login.ecs.soton.ac.uk> Almost two years ago at the LA conference a bunch of us agreed that something need to be done to improve LADSPA, and on the approximate direction it should take. Anyway, I finally got round to making a sketch plugin and .h file: http://plugin.org.uk/ladspa2/ The .ladspa2 plugin is a "bundle", ie. a directory with all the data the plugin needs in it. This idea is nicked from OPENSTEP. I'm not 100% convinced it's a good idea, but I think it makes sense for plugins. The dsp core (amp.c) is just a LADSPA 1.1 plugin with all the fixed data fields taken out, and a URI field added, to allow for working identification. I also dropped the runAdding method, as I dont think it is used enough to justify the effort of supporting it. The plugin is untested, but it compiles and nm reports sane contents for it. The data is in the amp.ttl file (it's in Turtle http://www.dajobe.org/2004/01/turtle/ an easy to hand-write RDF syntax). We could mandate a particular syntax for the spec. There's a shell script (show-data.sh) which, if you have raptor and rasqal installed will do something similar to what analyseplugin does for LADSPA 1.x, but it's very crude. Overall I think this is a much better approach than LADSPA 1.x, it has usable identifiers, a clear route for extensions without compatibility problems and each plugin is quite a lot simpler. - Steve From rzewnickie at rfa.org Sat Apr 22 06:08:16 2006 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Sat Apr 22 06:08:26 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen In-Reply-To: <1145613192.8855.10.camel@localhost> References: <1140401605.16545.22.camel@localhost.localdomain> <20060420135714.GB9579@slinkp.com> <200604201704.45866.cave.dnb@tiscali.fr> <20060420153759.GC9579@slinkp.com> <4447B492.2060003@jeremah.co.uk> <20060420163034.GF9579@slinkp.com> <20060420172007.GB3825@rfa.org> <1145613192.8855.10.camel@localhost> Message-ID: <20060422100816.GB11567@rfa.org> On Fri, Apr 21, 2006 at 11:53:12AM +0200, Lars Luthman wrote: > On Thu, 2006-04-20 at 13:20 -0400, Eric Dantan Rzewnicki wrote: > > On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: > > > On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > > > > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > > > > disk) to: > > > > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > > > I'm happy to host for the foreseeable future. If anyone's got a more > > > > recent copy let me know and I'll get that up as well. > > > Great! > > > I found a copy of 0.5.1 on my drive. Email me privately if you want it. > > umm ... the download just worked for me ... > > That said, I agreed a while back to maintain the project after Pete > > announced his own death and the accompanying death of specimen. While > > Pete resurfaced as a zombie and promptly went over to the dark side, I > > have not yet found time to resurrect specimen (mainly due to my job and > > preparations for LAC06). > Great to hear that you are going to maintain it. When you start looking > into it, could you also have a look at the LASH and JACK MIDI patches > for it? It would be very nice to have those in the official releases. > > The JACK MIDI patch is here (it adds a JACK MIDI input port that can be > used at the same time as the ALSA-seq port): > http://www.student.nada.kth.se/~d00-llu/code_patches/specimen-jackmidi-051205.diff > > Dave Robillard's LASH patch is here: > http://www.scs.carleton.ca/~drobilla/files/specimen-lash.patch > > I think both applied to 0.5.1 and the last CVS version I tested. Those are 2 things I'm interested in myself. So, yes I think there's a good chance of that functionality being added. I've grabbed copies of the patches. I'll look into them after LAC. -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network@rfa.org. From larsl at users.sourceforge.net Sat Apr 22 06:19:42 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat Apr 22 06:19:48 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422095358.GD715@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> Message-ID: <1145701182.8827.6.camel@localhost> On Sat, 2006-04-22 at 10:53 +0100, Steve Harris wrote: > Almost two years ago at the LA conference a bunch of us agreed that > something need to be done to improve LADSPA, and on the approximate > direction it should take. > > Anyway, I finally got round to making a sketch plugin and .h file: > http://plugin.org.uk/ladspa2/ Nice. The header and the plugin code really looks a lot cleaner without all the metadata embedded in it. > The data is in the amp.ttl file (it's in Turtle > http://www.dajobe.org/2004/01/turtle/ an easy to hand-write RDF syntax). > We could mandate a particular syntax for the spec. It looks a lot nicer than the XML syntax. > Overall I think this is a much better approach than LADSPA 1.x, it has > usable identifiers, a clear route for extensions without compatibility > problems and each plugin is quite a lot simpler. What type of extensions are you talking about here, and what is the clear route? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060422/b5fffaf0/attachment.bin From v2 at iki.fi Sat Apr 22 07:44:22 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Sat Apr 22 07:44:49 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422095358.GD715@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> Message-ID: <1145706262.7378.28.camel@puppeli> On Sat, 2006-04-22 at 10:53 +0100, Steve Harris wrote: > Almost two years ago at the LA conference a bunch of us agreed that > something need to be done to improve LADSPA, and on the approximate > direction it should take. > > Anyway, I finally got round to making a sketch plugin and .h file: > http://plugin.org.uk/ladspa2/ Great! The .ttl file syntax looks really good. I have a few suggestions, though: - GUI support. A standardized, well defined way for plugins to supply a graphical user interface of it's own. - Port units should be defined in a way that plugin hosts know what these units are. The label is not good enough for hosts. Instead of: ladspa:units "dB" We could have: ladspa:units#db rdfs:label "dB" (thanks for the syntax Steve. I hope I understood correctly) If hosts understand which units are used it gives the them a possibility to create better GUIs for the plugins. For example, if a parameter is in dB, the host can provide a widget more suitable for gain entry. But this would offer even greater benefits than widget selection: hosts could give users the possibility to give time values relative to beats/bars. (Without any need for the plugin to know about the tempo). Think delays synchronized with the song tempo, for example. The plugin could also give hints if a parameter should/could be given in beats/bars or absolute time. -- Sampo Savolainen From paulgfx at yahoo.com Sat Apr 22 07:51:38 2006 From: paulgfx at yahoo.com (Paul) Date: Sat Apr 22 07:51:51 2006 Subject: [linux-audio-dev] HyperMammut - I released a new software for processing sounds and images Message-ID: <20060422115138.66742.qmail@web52203.mail.yahoo.com> Hi. I released today an experimental software that allows you to process the sound/image as a single FFT (and other) transforms. Also, the program can transform sound to images and vice-versa. Because of this, you can apply a blurring or swirling effect to sound, or revereberation/flange effect to images ;-) Many effects sounds/looks very strange (in my opinion theese are the strangest sounds I ever heard - hard to describe in words - better listen them). You can download the alpha-stage source code from http://sourceforge.net/projects/hypermammut and I recomand you to see/listen some examples at http://hypermammut.sourceforge.net A related software to this is Mammut ( http://www.notam02.no/notam02/prod-prg-mammuthelp.html ), but this programs aims to be modular and to do more :) Paul. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From t_w_ at freenet.de Sat Apr 22 08:26:57 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Sat Apr 22 08:27:26 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422095358.GD715@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> Message-ID: <20060422122657.GA27302@charly.SWORD> On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris wrote: > Almost two years ago at the LA conference a bunch of us agreed that > something need to be done to improve LADSPA, and on the approximate > direction it should take. I'm not competent to comment on header files or implementation details. But via Om, I'm a LADSPA power user and would like to bring up some issues ;) Distribution / finding plugins: I would like to have an app, where I can put checkmarks to all plugins and they will be fetched and installed (buidling from source / binaries as option). But just a way to get from the host not finding a plugin to the name of the collection it's in would be nice already (so an app like Om can not only say plugin-x not found, but also point to the package). Stability: There are some plugins that will die if fed with values out of their range (and this happens easily in a modular system). Maybe some mechanism to protect against this could be build into the framework? Control/audio rate: Having several variations of the same plugin to allow varying audio/ control rate port setups makes for unnecessary long plugin lists and requires the user to delete and insert a different one, should he find out some port should be audio, not control rate. Just look at the sine oscillator(s) ... The rate of a port should be switchable (at leat in all cases where we have both versions now). Port grouping: Hosts should be able to see, wether 2 ports are independent, or happen to be a stereo pair (or any multi-channel setup). Also a way to specify that things like frequency and amount ports of an EQ form pairs might be nice. Should be helpful for generative plugin GUIs. Port Roles: Ports could have roles assigned to them, like signal_input, sidechain, latency or bpm (the last for transport awareness and to make it possible hosts assign values to it automaticaly). Referencing: There needs to be a safe way to reference plugins and their ports. Portnames make for human readable patch files, but this doesn't work with i18n, when Attack becomes Einschwingzeit ;) Hints: Maybe I just didn't see it, but shouldn't there be a hint for lists? Like for plugins that have modes/presets? Presets: Cross-host preset loading/saving. Help / Discription: A way to bring up a short discription of a plugin and what the ports are about. MIDI/OSC Don't know if the new LADSPAs should be able to handle MIDI/OSC, but there should be plugins that do it ;) GUI lib: There could be 1 or 2 (GTK, QT) libs for generative plugin GUIs, for hosts not having to reinvent the wheel and for consistency. --- Thorsten Wilms From fons.adriaensen at skynet.be Sat Apr 22 08:56:35 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Apr 22 08:49:02 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422122657.GA27302@charly.SWORD> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> Message-ID: <20060422125635.GA4962@linux-1> On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote: > Distribution / finding plugins: > Stability: > Control/audio rate: > Port grouping: > Port Roles: > Referencing: > Hints: > Presets: > Help / Discription: > MIDI/OSC > GUI lib: To which I'd add: Polyphony/Multiple channels: Plugin instances should be able to discover that they are part of a group sharing control parameters. In many cases the calculation of internal parameters from user supplied ones and their interpolation takes more CPU than the rest of the code. That work should be performed once in poly setups. The new syntax lools a lot cleaner than the existing system, to the point that I'd support it :-) -- FA Follie! Follie! Delirio vano e' questo! From larsl at users.sourceforge.net Sat Apr 22 09:01:26 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat Apr 22 09:01:38 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422125635.GA4962@linux-1> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422125635.GA4962@linux-1> Message-ID: <1145710886.8827.15.camel@localhost> On Sat, 2006-04-22 at 14:56 +0200, fons adriaensen wrote: > On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote: > > > Distribution / finding plugins: > > Stability: > > Control/audio rate: > > Port grouping: > > Port Roles: > > Referencing: > > Hints: > > Presets: > > Help / Discription: > > MIDI/OSC > > GUI lib: > > To which I'd add: > > Polyphony/Multiple channels: > > Plugin instances should be able to discover that they are > part of a group sharing control parameters. In many cases > the calculation of internal parameters from user supplied > ones and their interpolation takes more CPU than the rest > of the code. That work should be performed once in poly > setups. I'm not sure that all of this belongs in LADSPA (the Simple Plugin Architecture). DSSI has support for presets, MIDI in, GUIs and some support for polyphony (you can run several plugin instances as a polyphony group with a single call to run_multiple() which lets you do common calculations once). About referencing: isn't the port index the common way to identify LADSPA ports? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060422/9137fb97/attachment.bin From t_w_ at freenet.de Sat Apr 22 09:14:28 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Sat Apr 22 09:14:50 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145710886.8827.15.camel@localhost> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422125635.GA4962@linux-1> <1145710886.8827.15.camel@localhost> Message-ID: <20060422131428.GB27302@charly.SWORD> On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman wrote: > > I'm not sure that all of this belongs in LADSPA (the Simple Plugin > Architecture). DSSI has support for presets, MIDI in, GUIs and some > support for polyphony (you can run several plugin instances as a > polyphony group with a single call to run_multiple() which lets you do > common calculations once). I was about generated GUIs, not plugin specific ones. What's the reason that Om can treat DSSIs only as monophonic nodes again? > About referencing: isn't the port index the common way to identify > LADSPA ports? Might be. A human readable, not to be translated english name per port would be nice, though. --- Thorsten Wilms From fons.adriaensen at skynet.be Sat Apr 22 09:22:57 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Apr 22 09:16:23 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145710886.8827.15.camel@localhost> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422125635.GA4962@linux-1> <1145710886.8827.15.camel@localhost> Message-ID: <20060422132257.GB4962@linux-1> On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman wrote: > ... > support for polyphony (you can run several plugin instances as a > polyphony group with a single call to run_multiple() which lets you do > common calculations once). That's not the point. Even in that case each plugin instance does all the calculations, while they should be able to share some. -- FA Follie! Follie! Delirio vano e' questo! From larsl at users.sourceforge.net Sat Apr 22 09:25:43 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat Apr 22 09:25:50 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422131428.GB27302@charly.SWORD> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422125635.GA4962@linux-1> <1145710886.8827.15.camel@localhost> <20060422131428.GB27302@charly.SWORD> Message-ID: <1145712343.8827.23.camel@localhost> On Sat, 2006-04-22 at 15:14 +0200, Thorsten Wilms wrote: > On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman wrote: > > > > I'm not sure that all of this belongs in LADSPA (the Simple Plugin > > Architecture). DSSI has support for presets, MIDI in, GUIs and some > > support for polyphony (you can run several plugin instances as a > > polyphony group with a single call to run_multiple() which lets you do > > common calculations once). > > I was about generated GUIs, not plugin specific ones. I meant generated GUIs too - I've seen at least one generic (as in works for any plugin) DSSI GUI somewhere, although I don't remember where at the moment. > What's the reason that Om can treat DSSIs only as monophonic nodes > again? As far as I know there isn't a hard reason. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060422/1c40449e/attachment.bin From indigo at bitglue.com Sat Apr 22 11:41:16 2006 From: indigo at bitglue.com (Phil Frost) Date: Sat Apr 22 11:41:29 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422095358.GD715@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> Message-ID: <20060422154116.GA25421@unununium.org> On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris wrote: > Almost two years ago at the LA conference a bunch of us agreed that > something need to be done to improve LADSPA, and on the approximate > direction it should take. > > [...] In my experience developing modular synths, it would be a huge benefit to performance if modules had the option of including source code in the bundle. This is especially useful if the module can provide a function that calculates the outputs one sample at a time. I reckon most modules which do not do any frequency domain calculations can do this. The reason it's so great is because it allows the host to inline those functions and call on a C compiler to optimize them together. For some simple functions, constant folding can make a huge difference. Perhaps more importantly, the sample buffer between the modules can be eliminated. When each module does something simple, say a low order IIR, an oscilator, or a multiplier, the load and store is much slower than the calculation that happens between them. If the result can be left in a register for the next module to process, the system becomes much more efficient. When the process functions are inlined, there is not even the overhead of a call. Also, included source is simply convienent if one wishes to tinker with the module, or run it on a different platform. Perhaps the compiled version should have a platform-unique name within the bundle, and be marked with a hash of the source, so that it can be rebuilt when needed, preferably with some shared ladspa build tool. Lastly, I'm not saying bundles-as-directories is a bad idea, but an alternative to an openstep bundle is an ar archive. It works like tar, only it is designed for nonsequential access of members. ".a" static libraries and ".deb" debian packages are really just ar archives. From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 12:10:34 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 12:10:53 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145706262.7378.28.camel@puppeli> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <1145706262.7378.28.camel@puppeli> Message-ID: <20060422161034.GB12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 02:44:22PM +0300, Sampo Savolainen wrote: > > Anyway, I finally got round to making a sketch plugin and .h file: > > http://plugin.org.uk/ladspa2/ > > Great! > > The .ttl file syntax looks really good. Yes, it's nice to write, unlike RDF/XML, which is a PITA. There aren't as many RDF librries tha can read it, but the majority (including raptor) can. > I have a few suggestions, though: > > - GUI support. A standardized, well defined way for plugins > to supply a graphical user interface of it's own. I would advocate the DSSI protocol, and placing the executable in the bundle. > - Port units should be defined in a way that plugin hosts know > what these units are. The label is not good enough for hosts. > > Instead of: > ladspa:units "dB" > > We could have: > ladspa:units#db > rdfs:label "dB" > (thanks for the syntax Steve. I hope I understood correctly) I think you have, to be perfectly clear, I think you mean (in longhand): In the plugin file ladspa:unit units:db . and then in the schema file: units:db rdfs:label "dB" . ie. label the plugins with a URI (symbol) and then annotate the symbol with its name globally. I thought about doing that in the example, but I though maybe the extra level of indirection would put people off. It would let the hosts do more intelligent things with control ports though, like you suggested. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 12:30:51 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 12:31:11 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422122657.GA27302@charly.SWORD> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> Message-ID: <20060422163051.GC12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote: > I'm not competent to comment on header files or implementation details. > But via Om, I'm a LADSPA power user and would like to bring up > some issues ;) *gulp* ;) > Distribution / finding plugins: > I would like to have an app, where I can put checkmarks to all plugins > and they will be fetched and installed (buidling from source / binaries > as option). > But just a way to get from the host not finding a plugin to the name > of the collection it's in would be nice already (so an app like Om can > not only say plugin-x not found, but also point to the package). So... that is one thing that using RDF/web tech /can/ give you. eg. the URI for the example plugin is http://plugin.org.uk/swh-plugins/amp/ if you dereference that (ie. click on it ;) you will see some docs, but if you use HTTP content negotiation and ask for it in Trutle you will get the RDF description back, which /could/ have a machine readable bit telling you where to get the package. In combination with bundles that gives you the possibility to install individual plugins. It's a little bit sci-fi, but hopeful you can see that it's not too far off. > Stability: > There are some plugins that will die if fed with values out of their > range (and this happens easily in a modular system). Maybe some mechanism > to protect against this could be build into the framework? It would be 100% opposed to that. Plugins that crash when given odd values are buggy (spec says they mustn't), and should be fixed. Use demolition, report bugs. > Control/audio rate: > Having several variations of the same plugin to allow varying audio/ > control rate port setups makes for unnecessary long plugin lists and > requires the user to delete and insert a different one, should he find > out some port should be audio, not control rate. Just look at the > sine oscillator(s) ... > The rate of a port should be switchable (at leat in all cases where > we have both versions now). I might consider that for the future, but not for 2.0. I think its important to get a more capable platform, before adding features. > Port grouping: > Hosts should be able to see, wether 2 ports are independent, or happen > to be a stereo pair (or any multi-channel setup). > Also a way to specify that things like frequency and amount ports of > an EQ form pairs might be nice. Should be helpful for generative plugin > GUIs. This has been propsed using labels, eg "OSC 1/frequency" and "OSC 1/amplitude", that's an informal part of the spec IIRC. You could encode it in RDF if you wanted to: [ # port defintion ladspa:index 1 ; ladspa:label "frequency" ; ladspa:inGroup ] , [ ladspa:index 1 ; ladspa:label "frequency" ; ladspa:inGroup ] . ladspa:label "OSC 1" . But I dint think it offers much more. > Port Roles: > Ports could have roles assigned to them, like signal_input, sidechain, > latency or bpm (the last for transport awareness and to make it possible > hosts assign values to it automaticaly). Ugh. Maybe sometime in the future. That sounds hard to use. c.f. 2.0 plans. > Referencing: > There needs to be a safe way to reference plugins and their ports. > Portnames make for human readable patch files, but this doesn't > work with i18n, when Attack becomes Einschwingzeit ;) Plugins have URIs! And ports have uniqe identifying numbers within the plugin. We could assign URIs to ports too, but I think thats going too far. > Hints: > Maybe I just didn't see it, but shouldn't there be a hint for lists? > Like for plugins that have modes/presets? Yes, there is, but I didnt show it in that example as the simple amp doesnt need it. It looks like: # ... inside port defn ladspa:scalePoint [ ladspa:label "sine" ; ladspa:value 0.0 . ], [ ladspa:label "square" ; ladspa:value 1.0 . ], [ ladspa:label "saw" ; ladspa:value 2.0 . ] > Presets: > Cross-host preset loading/saving. Right, there are some obvious ways to do it. Later. > Help / Discription: > A way to bring up a short discription of a plugin and what the > ports are about. Just dereference the plugin URI as text/html or text/plain. > MIDI/OSC > Don't know if the new LADSPAs should be able to handle MIDI/OSC, > but there should be plugins that do it ;) DSSI. If this gets momentum retorfitting LADSPA 2 to DSSI will be easy. It was designed with that in mind. > GUI lib: > There could be 1 or 2 (GTK, QT) libs for generative plugin GUIs, > for hosts not having to reinvent the wheel and for consistency. Nope. Too hard, use the DSSI protocol. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 12:33:25 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 12:33:43 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422125635.GA4962@linux-1> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422125635.GA4962@linux-1> Message-ID: <20060422163325.GD12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 02:56:35PM +0200, fons adriaensen wrote: > Polyphony/Multiple channels: > > Plugin instances should be able to discover that they are > part of a group sharing control parameters. In many cases > the calculation of internal parameters from user supplied > ones and their interpolation takes more CPU than the rest > of the code. That work should be performed once in poly > setups. Agreed. But I'd like to spec out a 2.0 that is no more capable than 1.1 first, then think about extensions seperatly. That sounds quite complex, and I think its the sort of the DSSI addresses, as it has instancing and polyphony control - at some level. > The new syntax lools a lot cleaner than the existing system, > to the point that I'd support it :-) Wow, praise indeed :) - Steve From drobilla at connect.carleton.ca Sat Apr 22 12:37:09 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 12:37:16 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422131428.GB27302@charly.SWORD> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422125635.GA4962@linux-1> <1145710886.8827.15.camel@localhost> <20060422131428.GB27302@charly.SWORD> Message-ID: <1145723829.2358.1.camel@DaveLap> On Sat, 2006-04-22 at 15:14 +0200, Thorsten Wilms wrote: > On Sat, Apr 22, 2006 at 03:01:26PM +0200, Lars Luthman wrote: > > > > I'm not sure that all of this belongs in LADSPA (the Simple Plugin > > Architecture). DSSI has support for presets, MIDI in, GUIs and some > > support for polyphony (you can run several plugin instances as a > > polyphony group with a single call to run_multiple() which lets you do > > common calculations once). > > I was about generated GUIs, not plugin specific ones. > What's the reason that Om can treat DSSIs only as monophonic nodes > again? >From the host perspective, DSSI plugins /are/ monophonic. There is no access to the individual voices, they're mixed down in the plugin. If LADSPA2 is to be polyphonic, it MUST not be like this. The host needs access to individual voices. -DR- From drobilla at connect.carleton.ca Sat Apr 22 12:43:54 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 12:44:06 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422154116.GA25421@unununium.org> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422154116.GA25421@unununium.org> Message-ID: <1145724234.2358.6.camel@DaveLap> On Sat, 2006-04-22 at 11:41 -0400, Phil Frost wrote: > On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris wrote: > > Almost two years ago at the LA conference a bunch of us agreed that > > something need to be done to improve LADSPA, and on the approximate > > direction it should take. > > > > [...] > > In my experience developing modular synths, it would be a huge benefit > to performance if modules had the option of including source code in the > bundle. This is especially useful if the module can provide a function > that calculates the outputs one sample at a time. I reckon most modules > which do not do any frequency domain calculations can do this. It would definitely be a really, really cool thing if we could do this. LADSPA plugins would be useful in so many more domains if "hosts" could get at the code... The downside is that we would have to mandate a standard build system and FS layout of some variety. I'm generally not for such dictatorial things, but in this case I think it's justified. Having some sort of standard build system/directory layout/etc (ie a completely standardized plugin package inc. source code) would allow a good LADSPA repository site to be easily built as well - something else I think is sorely needed. The current "system" of LADSPA distribution definitely sucks. -DR- From jack.oquin at gmail.com Sat Apr 22 12:46:28 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Sat Apr 22 12:46:34 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145701182.8827.6.camel@localhost> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <1145701182.8827.6.camel@localhost> Message-ID: On 4/22/06, Lars Luthman wrote: > On Sat, 2006-04-22 at 10:53 +0100, Steve Harris wrote: > > Almost two years ago at the LA conference a bunch of us agreed that > > something need to be done to improve LADSPA, and on the approximate > > direction it should take. > > > > Anyway, I finally got round to making a sketch plugin and .h file: > > http://plugin.org.uk/ladspa2/ > > Nice. The header and the plugin code really looks a lot cleaner without > all the metadata embedded in it. Agreed. I really like getting all that XML out of the C sources. Much cleaner and more accessible. A minor suggestion: how about moving that SYMBOL_EXPORT definition into ladspa-2.h, presumably with a LADSPA_ prefix? #ifdef WIN32 #define SYMBOL_EXPORT __declspec(dllexport) #else #define SYMBOL_EXPORT #endif -- joq From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 12:47:49 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 12:48:17 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422154116.GA25421@unununium.org> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422154116.GA25421@unununium.org> Message-ID: <20060422164749.GE12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 11:41:16AM -0400, Phil Frost wrote: > On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris wrote: > > Almost two years ago at the LA conference a bunch of us agreed that > > something need to be done to improve LADSPA, and on the approximate > > direction it should take. > > > > [...] > > In my experience developing modular synths, it would be a huge benefit > to performance if modules had the option of including source code in the > bundle. This is especially useful if the module can provide a function > that calculates the outputs one sample at a time. I reckon most modules > which do not do any frequency domain calculations can do this. That's too big a departure from LADSPA 1.x for me to consider right now. > Lastly, I'm not saying bundles-as-directories is a bad idea, but an > alternative to an openstep bundle is an ar archive. It works like tar, > only it is designed for nonsequential access of members. ".a" static > libraries and ".deb" debian packages are really just ar archives. Yes, also jar/xpi zip files are possible. I've nothing against them, but they mean more work for plugin and host authors, and its slightly more work for curious users to find out what's in a plugin. The advantage being that its a single file to pass around. I did give it some thought, and came to the comclusion that directories were /slightly/ better overall. My mind is not set in concrete though. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 12:55:56 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 12:56:21 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: References: <20060422095358.GD715@login.ecs.soton.ac.uk> <1145701182.8827.6.camel@localhost> Message-ID: <20060422165556.GF12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 11:46:28AM -0500, Jack O'Quin wrote: > > Nice. The header and the plugin code really looks a lot cleaner without > > all the metadata embedded in it. > > Agreed. I really like getting all that XML out of the C sources. Much > cleaner and more accessible. The XML+C thing was a Steve-brand hack, not part of the spec, I dont think anyone else was doing it. The metadata was generally static C char *'s, but that was very limiting, and led to a lot of tedious cut-and-paste code, compatibility dead-ends and i18n excitement. > A minor suggestion: how about moving that SYMBOL_EXPORT definition > into ladspa-2.h, presumably with a LADSPA_ prefix? > > #ifdef WIN32 > #define SYMBOL_EXPORT __declspec(dllexport) > #else > #define SYMBOL_EXPORT > #endif Not a bad idea, I could go for that. - Steve From drobilla at connect.carleton.ca Sat Apr 22 13:06:26 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 13:06:33 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422163051.GC12135@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> Message-ID: <1145725586.2358.14.camel@DaveLap> On Sat, 2006-04-22 at 17:30 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote: > > Referencing: > > There needs to be a safe way to reference plugins and their ports. > > Portnames make for human readable patch files, but this doesn't > > work with i18n, when Attack becomes Einschwingzeit ;) > > Plugins have URIs! And ports have uniqe identifying numbers within the > plugin. We could assign URIs to ports too, but I think thats going too > far. I'm not going to suggest ID numbers go away, but I do think ports should have a uniquely identifying string label. Primary reason being OSC control, and using plugins in language bindings (ie python) - both things that are getting much more prevalent now than when LADSPA first arrived. Noone wants to set the frequency of an oscillator with the OSC message "/set oscillator/4 440" when they could "/set oscillator/freq 440". Or plugin.port(4).set_value(440) when it could be plugin.port("frequency").set_value(440). Code (or OSC messages) using plugin indexes as IDs is completely unreadable. This is actually very important to me, I would very much like unique port string ID's for the above reasons unless there's a good reason there can't be. -DR- From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 13:10:45 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 13:11:14 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422131428.GB27302@charly.SWORD> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422125635.GA4962@linux-1> <1145710886.8827.15.camel@localhost> <20060422131428.GB27302@charly.SWORD> Message-ID: <20060422171045.GG12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 03:14:28PM +0200, Thorsten Wilms wrote: > > About referencing: isn't the port index the common way to identify > > LADSPA ports? > > Might be. A human readable, not to be translated english name per > port would be nice, though. I dont see enough value to justify making plugin authors come up with a neutral string that will never be displayed to users. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 13:25:11 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 13:25:35 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145725586.2358.14.camel@DaveLap> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> Message-ID: <20060422172511.GH12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 01:06:26PM -0400, Dave Robillard wrote: > On Sat, 2006-04-22 at 17:30 +0100, Steve Harris wrote: > > On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote: > > > Referencing: > > > There needs to be a safe way to reference plugins and their ports. > > > Portnames make for human readable patch files, but this doesn't > > > work with i18n, when Attack becomes Einschwingzeit ;) > > > > Plugins have URIs! And ports have uniqe identifying numbers within the > > plugin. We could assign URIs to ports too, but I think thats going too > > far. > > I'm not going to suggest ID numbers go away, but I do think ports should > have a uniquely identifying string label. Primary reason being OSC > control, and using plugins in language bindings (ie python) - both > things that are getting much more prevalent now than when LADSPA first > arrived. OK, that's an argument I could buy. i'm still not completly convinced, but it does make some sense. > Noone wants to set the frequency of an oscillator with the OSC message > "/set oscillator/4 440" when they could "/set oscillator/freq 440". Or > plugin.port(4).set_value(440) when it could be > plugin.port("frequency").set_value(440). Code (or OSC messages) using > plugin indexes as IDs is completely unreadable. > > This is actually very important to me, I would very much like unique > port string ID's for the above reasons unless there's a good reason > there can't be. I guess you mean unique in plugin scope? It would also have to have some restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some kind of lowest common denominator between symbols for various languages would make sense. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 13:30:30 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 13:30:47 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145701182.8827.6.camel@localhost> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <1145701182.8827.6.camel@localhost> Message-ID: <20060422173029.GI12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 12:19:42PM +0200, Lars Luthman wrote: > > Overall I think this is a much better approach than LADSPA 1.x, it has > > usable identifiers, a clear route for extensions without compatibility > > problems and each plugin is quite a lot simpler. > > What type of extensions are you talking about here, and what is the > clear route? Extensions to the metadata, eg. port groups, new kinds of port (assuming they can still be float *s), additional hints etc. The clear route is the RDF namespacing mechanism, if someone wants to try a new extension they can just start using it under thier own namespace, then it can be added to the core spec if it's popular. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 13:44:18 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 13:44:43 2006 Subject: [linux-audio-dev] LADSPA 2 metadata generator Message-ID: <20060422174417.GJ12135@login.ecs.soton.ac.uk> Only really a toy, but: Aparently, ages ago I made an online LADSPA 2 RDF metadata editor: http://plugin.org.uk/md-creator/ (http://www.music.columbia.edu/pipermail/linux-audio-dev/2004-October/010011.html) It's very similar to the stuff I knocked up last night, though its not exactly the same (the namespace is different, and it uses ladspa: for everything, not DC where it should). It generates and reads longhand-only Turtle (AKA NTriples). I might fix it up to match the current strawman at some point, but I dont think it's important. - Steve From drobilla at connect.carleton.ca Sat Apr 22 13:47:40 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 13:47:53 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422172511.GH12135@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> Message-ID: <1145728060.2358.36.camel@DaveLap> On Sat, 2006-04-22 at 18:25 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 01:06:26PM -0400, Dave Robillard wrote: > > On Sat, 2006-04-22 at 17:30 +0100, Steve Harris wrote: > > > On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote: > > > > Referencing: > > > > There needs to be a safe way to reference plugins and their ports. > > > > Portnames make for human readable patch files, but this doesn't > > > > work with i18n, when Attack becomes Einschwingzeit ;) > > > > > > Plugins have URIs! And ports have uniqe identifying numbers within the > > > plugin. We could assign URIs to ports too, but I think thats going too > > > far. > > > > I'm not going to suggest ID numbers go away, but I do think ports should > > have a uniquely identifying string label. Primary reason being OSC > > control, and using plugins in language bindings (ie python) - both > > things that are getting much more prevalent now than when LADSPA first > > arrived. > > OK, that's an argument I could buy. i'm still not completly convinced, but > it does make some sense. It's not useful from the perspective of writing a LADSPA host in C, but I think the above two (actual real world) examples of where port ID's are user exposed are justification enough. > I guess you mean unique in plugin scope? It would also have to have some > restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some > kind of lowest common denominator between symbols for various languages > would make sense. Yeah, just unique to the plugin. (Though I guess that would imply the port could have a URI like pluginuri/porturi but whatever). I think the regexp you mentioned there is fine, though I think we should add one separator character other than underscore for various reasons. ":" maybe? As a side effect of this, what is now "label" should become "description" and implicitly be Nice Human Readable Text, not ugly_c_looking_identifiers (and units definitely need to be seperated). "Description" is metadata though, so I guess it doesn't belong in the C file. -DR- From krampenschiesser at freenet.de Sat Apr 22 13:50:22 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Sat Apr 22 13:50:32 2006 Subject: [linux-audio-dev] HyperMammut - I released a new software for processing sounds and images In-Reply-To: <20060422115138.66742.qmail@web52203.mail.yahoo.com> References: <20060422115138.66742.qmail@web52203.mail.yahoo.com> Message-ID: <20060422195022.51961799.krampenschiesser@freenet.de> I've listened to the examples, they sound interesting :P Can i process in realtime? That would be a great feature :) Scar From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 14:12:40 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 14:13:02 2006 Subject: [linux-audio-dev] LADSPA 2 decision points Message-ID: <20060422181240.GK12135@login.ecs.soton.ac.uk> We haven't heard from a number of key people yet, but I think the overall impression is positive so far. There are a number of decisions that need to be made if it's going to go ahead. Either things that I didn't consider, or where I made arbitrary choices: A) Dropping runAdding: personally I dont think runAdding is worthwhile. How many hosts take advantage of it? Its something LADSPA 1.1 can do and 2.0 wouldn't be able to though. B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than RDF/XML. We could mandate Turtle for all LADSPA metadata. C) Port scales: these weren't really in LADSPA 1.x, but they were in lrdf, so adding them is a bit arguable. I think they're clearly beneficial though, and they are getting close to critcal mass recently. D) Port shortnames: for OSC, Pd etc. access. I dont have a strong feeling on that. It /is/ an extension, but retrofitting it will mean OSC servers etc. will have to support both accessor methods. E) Bundles: no-one screamed when I suggested it, but its a bit different to LADSPA 1's /lib directory. Hosts would be required to allow the plugin link to libraries in the bundle if they need to (this is why OPENSTEP did it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which is a bit more work, but makes moving plugins between machines easier. Oh, and the plugins needs to have the path of its bundle passed to it when its instantiated, which isn't in the API right now. F) Host OS specific macros in ladspa-2.h that Jack O'Q suggested. It seems like a reasonable idea to me. No need to punish users of inferiour OSs more than they are allready ;) - Steve From larsl at users.sourceforge.net Sat Apr 22 14:19:44 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat Apr 22 14:19:52 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422181240.GK12135@login.ecs.soton.ac.uk> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> Message-ID: <1145729984.8827.27.camel@localhost> On Sat, 2006-04-22 at 19:12 +0100, Steve Harris wrote: > E) Bundles: no-one screamed when I suggested it, but its a bit different to > LADSPA 1's /lib directory. Hosts would be required to allow the plugin > link to libraries in the bundle if they need to (this is why OPENSTEP did > it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which > is a bit more work, but makes moving plugins between machines easier. I don't really see the point in storing shared libraries in the bundle. If you are using your own copy of a library already, why not just link it statically? I'm not saying that bundles are bad though. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060422/8da81d13/attachment.bin From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 14:20:50 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 14:21:22 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145728060.2358.36.camel@DaveLap> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> Message-ID: <20060422182050.GL12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 01:47:40PM -0400, Dave Robillard wrote: > > I guess you mean unique in plugin scope? It would also have to have some > > restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some > > kind of lowest common denominator between symbols for various languages > > would make sense. > > Yeah, just unique to the plugin. (Though I guess that would imply the > port could have a URI like pluginuri/porturi but whatever). You could do pluginUri#portShortName, it's a fairly common convention (eg. in HTML). But youre only allowed a small set of characters after the #. > I think the regexp you mentioned there is fine, though I think we should > add one separator character other than underscore for various reasons. > ":" maybe? I'd rather not, I'm not sure its legal in Pd (they get bitten by the port name thing too), and its not in C. Pure selfinterest, but My LADSPA code is about 50% generated from XML, and I use short names internally for C symbols. > As a side effect of this, what is now "label" should become > "description" and implicitly be Nice Human Readable Text, not > ugly_c_looking_identifiers (and units definitely need to be seperated). > "Description" is metadata though, so I guess it doesn't belong in the C > file. The C now only contains the function pointers, a vector of float pointers and a URI char *. All this stuff belongs outside. - Steve From drobilla at connect.carleton.ca Sat Apr 22 14:22:09 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 14:23:10 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422181240.GK12135@login.ecs.soton.ac.uk> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> Message-ID: <1145730130.2358.42.camel@DaveLap> On Sat, 2006-04-22 at 19:12 +0100, Steve Harris wrote: > We haven't heard from a number of key people yet, but I think the overall > impression is positive so far. There are a number of decisions that need > to be made if it's going to go ahead. Either things that I didn't > consider, or where I made arbitrary choices: > > A) Dropping runAdding: personally I dont think runAdding is worthwhile. How > many hosts take advantage of it? Its something LADSPA 1.1 can do and 2.0 > wouldn't be able to though. > > B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than > RDF/XML. We could mandate Turtle for all LADSPA metadata. Personally I think it's ugly and strange and arbitrary and just weird all around, but whatever. I don't really care. :) > E) Bundles: no-one screamed when I suggested it, but its a bit different to > LADSPA 1's /lib directory. Hosts would be required to allow the plugin > link to libraries in the bundle if they need to (this is why OPENSTEP did > it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which > is a bit more work, but makes moving plugins between machines easier. Oh, > and the plugins needs to have the path of its bundle passed to it when its > instantiated, which isn't in the API right now. I like the bundle idea, but I thik we need to have a long hard think about this WRT distro package management systems and FHS compliance. We do need some way of allowing plugins to load libraries though, but is it really necessary to do the DLL Hell thing to allow it? -DR- From drobilla at connect.carleton.ca Sat Apr 22 14:47:33 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 14:47:42 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422182050.GL12135@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> Message-ID: <1145731653.2358.60.camel@DaveLap> On Sat, 2006-04-22 at 19:20 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 01:47:40PM -0400, Dave Robillard wrote: > > > I guess you mean unique in plugin scope? It would also have to have some > > > restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some > > > kind of lowest common denominator between symbols for various languages > > > would make sense. > > > > Yeah, just unique to the plugin. (Though I guess that would imply the > > port could have a URI like pluginuri/porturi but whatever). > > You could do pluginUri#portShortName, it's a fairly common convention (eg. > in HTML). But youre only allowed a small set of characters after the #. > > > I think the regexp you mentioned there is fine, though I think we should > > add one separator character other than underscore for various reasons. > > ":" maybe? > > I'd rather not, I'm not sure its legal in Pd (they get bitten by the port > name thing too), and its not in C. Pure selfinterest, but My LADSPA code > is about 50% generated from XML, and I use short names internally for C > symbols. Well, at least one kind of separator character is required (for big plugins). If it can't be ":", then I don't know what, but there needs to be something. Maybe "."? If you want to keep it as a valid C identifier I guess we're pretty much screwed, aside from defining __ to be interpreted as a sort of heirarchialish separator. master_amp:vol master_amp.vol master_amp__vol "." is definitely prettiest... is there anything other than "__" we can use that's as safe? > > As a side effect of this, what is now "label" should become > > "description" and implicitly be Nice Human Readable Text, not > > ugly_c_looking_identifiers (and units definitely need to be seperated). > > "Description" is metadata though, so I guess it doesn't belong in the C > > file. > > The C now only contains the function pointers, a vector of float pointers > and a URI char *. All this stuff belongs outside. I'm fully in support of putting any and all metadata outside the C file, but the unique identifier isn't metadata, it should be in the code. A trivial OSC controlled plugin host (which would make a good bundled example client for the SDK) would need it. -DR- From thockin at hockin.org Sat Apr 22 14:56:06 2006 From: thockin at hockin.org (thockin@hockin.org) Date: Sat Apr 22 14:56:19 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <1145730130.2358.42.camel@DaveLap> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> Message-ID: <20060422185606.GA23263@hockin.org> On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote: > > B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than > > RDF/XML. We could mandate Turtle for all LADSPA metadata. > > Personally I think it's ugly and strange and arbitrary and just weird > all around, but whatever. I don't really care. :) I've not made time for audio software much this past year, so discount me if you will, but I agree. I just don't see the point of metadata outside the plugin. I just don't get it. From drobilla at connect.carleton.ca Sat Apr 22 15:05:18 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 15:05:26 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422185606.GA23263@hockin.org> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> Message-ID: <1145732718.2358.64.camel@DaveLap> On Sat, 2006-04-22 at 11:56 -0700, thockin@hockin.org wrote: > On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote: > > > B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than > > > RDF/XML. We could mandate Turtle for all LADSPA metadata. > > > > Personally I think it's ugly and strange and arbitrary and just weird > > all around, but whatever. I don't really care. :) > > I've not made time for audio software much this past year, so discount me > if you will, but I agree. I just don't see the point of metadata outside > the plugin. I just don't get it. nonono :) I think metadata outside the plugin is without a doubt the right way to go. I meant I'm just not a huge fan of the particular syntax of this Turtle stuff (as opposed to normal well-formed XML). Mostly because it means we need special tools and who knows what libraries to deal with it. -DR- From thockin at hockin.org Sat Apr 22 15:34:04 2006 From: thockin at hockin.org (thockin@hockin.org) Date: Sat Apr 22 15:34:11 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <1145732718.2358.64.camel@DaveLap> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> Message-ID: <20060422193404.GA26251@hockin.org> On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote: > On Sat, 2006-04-22 at 11:56 -0700, thockin@hockin.org wrote: > > On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote: > > > > B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than > > > > RDF/XML. We could mandate Turtle for all LADSPA metadata. > > > > > > Personally I think it's ugly and strange and arbitrary and just weird > > > all around, but whatever. I don't really care. :) > > > > I've not made time for audio software much this past year, so discount me > > if you will, but I agree. I just don't see the point of metadata outside > > the plugin. I just don't get it. > > nonono :) I think metadata outside the plugin is without a doubt the > right way to go. I meant I'm just not a huge fan of the particular > syntax of this Turtle stuff (as opposed to normal well-formed XML). > Mostly because it means we need special tools and who knows what > libraries to deal with it. That's fine. I still don't get the point of seperating the two. From drobilla at connect.carleton.ca Sat Apr 22 15:36:33 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 15:36:41 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422193404.GA26251@hockin.org> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> <20060422193404.GA26251@hockin.org> Message-ID: <1145734593.2358.69.camel@DaveLap> On Sat, 2006-04-22 at 12:34 -0700, thockin@hockin.org wrote: > On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote: > > On Sat, 2006-04-22 at 11:56 -0700, thockin@hockin.org wrote: > > > On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote: > > > > > B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than > > > > > RDF/XML. We could mandate Turtle for all LADSPA metadata. > > > > > > > > Personally I think it's ugly and strange and arbitrary and just weird > > > > all around, but whatever. I don't really care. :) > > > > > > I've not made time for audio software much this past year, so discount me > > > if you will, but I agree. I just don't see the point of metadata outside > > > the plugin. I just don't get it. > > > > nonono :) I think metadata outside the plugin is without a doubt the > > right way to go. I meant I'm just not a huge fan of the particular > > syntax of this Turtle stuff (as opposed to normal well-formed XML). > > Mostly because it means we need special tools and who knows what > > libraries to deal with it. > > That's fine. I still don't get the point of seperating the two. Search the archives for any and all threads about adding this or that trivial thing to LADSPA. Note how all ended with nothing done, and the LADSPA situation hasn't gotten any better in the past 5 years. Guess why? We can't break the ABI every time someone might find a new piece of metadata handy. -DR- From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 16:10:08 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 16:10:28 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145731653.2358.60.camel@DaveLap> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> Message-ID: <20060422201008.GM12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 02:47:33PM -0400, Dave Robillard wrote: > > You could do pluginUri#portShortName, it's a fairly common convention (eg. > > in HTML). But youre only allowed a small set of characters after the #. > > > > > I think the regexp you mentioned there is fine, though I think we should > > > add one separator character other than underscore for various reasons. > > > ":" maybe? > > > > I'd rather not, I'm not sure its legal in Pd (they get bitten by the port > > name thing too), and its not in C. Pure selfinterest, but My LADSPA code > > is about 50% generated from XML, and I use short names internally for C > > symbols. > > Well, at least one kind of separator character is required (for big > plugins). If it can't be ":", then I don't know what, but there needs > to be something. Maybe "."? If you want to keep it as a valid C > identifier I guess we're pretty much screwed, aside from defining __ to > be interpreted as a sort of heirarchialish separator. I'm missing the need for heirachicalness. : is probably not safe in OSC either. > I'm fully in support of putting any and all metadata outside the C file, > but the unique identifier isn't metadata, it should be in the code. A > trivial OSC controlled plugin host (which would make a good bundled > example client for the SDK) would need it. It's only /a/ unique identifier. We can't loose the index number as thats the efficent way you access the LADSPA_Data pointers. Only one can be canonical. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 16:11:17 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 16:12:14 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <1145729984.8827.27.camel@localhost> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145729984.8827.27.camel@localhost> Message-ID: <20060422201117.GN12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 08:19:44PM +0200, Lars Luthman wrote: > On Sat, 2006-04-22 at 19:12 +0100, Steve Harris wrote: > > E) Bundles: no-one screamed when I suggested it, but its a bit different to > > LADSPA 1's /lib directory. Hosts would be required to allow the plugin > > link to libraries in the bundle if they need to (this is why OPENSTEP did > > it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which > > is a bit more work, but makes moving plugins between machines easier. > > I don't really see the point in storing shared libraries in the bundle. > If you are using your own copy of a library already, why not just link > it statically? Its for when theres a system installed version of the library, but you want to provide one incase there isn't. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 16:21:18 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 16:21:39 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422193404.GA26251@hockin.org> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> <20060422193404.GA26251@hockin.org> Message-ID: <20060422202118.GO12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 12:34:04PM -0700, thockin@hockin.org wrote: > > nonono :) I think metadata outside the plugin is without a doubt the > > right way to go. I meant I'm just not a huge fan of the particular > > syntax of this Turtle stuff (as opposed to normal well-formed XML). > > Mostly because it means we need special tools and who knows what > > libraries to deal with it. > > That's fine. I still don't get the point of seperating the two. We've done this disccusion to death, but anyway... if you have the constant data inside the plugin binary then: 1) you have to load and link the binary to find anything about it 2) you have to have lots of tedious, but quite complex code everytime you provide data (look how much pointless boilerplate code there is in a ladspa .c just to make the port structures) 3) you risk binary incompatibility everytime you add to the static data (think of the defaults problem in LADSPA 1) 4) you have a wierd licence situation around reusing the data 5) I18N is a pain 6) extensions have to change the binary, or be external anyway and so on. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 16:24:46 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 16:25:05 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422201117.GN12135@login.ecs.soton.ac.uk> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145729984.8827.27.camel@localhost> <20060422201117.GN12135@login.ecs.soton.ac.uk> Message-ID: <20060422202446.GP12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 09:11:17PM +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 08:19:44PM +0200, Lars Luthman wrote: > > On Sat, 2006-04-22 at 19:12 +0100, Steve Harris wrote: > > > E) Bundles: no-one screamed when I suggested it, but its a bit different to > > > LADSPA 1's /lib directory. Hosts would be required to allow the plugin > > > link to libraries in the bundle if they need to (this is why OPENSTEP did > > > it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which > > > is a bit more work, but makes moving plugins between machines easier. > > > > I don't really see the point in storing shared libraries in the bundle. > > If you are using your own copy of a library already, why not just link > > it statically? > > Its for when theres a system installed version of the library, but you > want to provide one incase there isn't. Err... and this is so that you can provide plugins individually for download, eg. for the case where someone downloads a patch that requires one plugin you dont have, and otherwise it would have onerous requirements. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 16:26:30 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 16:26:49 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <1145730130.2358.42.camel@DaveLap> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> Message-ID: <20060422202630.GQ12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 02:22:09PM -0400, Dave Robillard wrote: > > B) RDF syntax: RDF/Turtle seems a lot more popular in these parts than > > RDF/XML. We could mandate Turtle for all LADSPA metadata. > > Personally I think it's ugly and strange and arbitrary and just weird > all around, but whatever. I don't really care. :) *shrug* less of the evils. I'm kinda fond of Turtle, its not XML, but its easy for humans to read and write. > > E) Bundles: no-one screamed when I suggested it, but its a bit different to > > LADSPA 1's /lib directory. Hosts would be required to allow the plugin > > link to libraries in the bundle if they need to (this is why OPENSTEP did > > it, I guess its done by setting LD_LIBRARY_PATH, but I dont know), which > > is a bit more work, but makes moving plugins between machines easier. Oh, > > and the plugins needs to have the path of its bundle passed to it when its > > instantiated, which isn't in the API right now. > > I like the bundle idea, but I thik we need to have a long hard think > about this WRT distro package management systems and FHS compliance. We > do need some way of allowing plugins to load libraries though, but is it > really necessary to do the DLL Hell thing to allow it? It's not really DLL Hell, but yes, it needs thought. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 22 16:32:39 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 22 16:32:59 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <1145732718.2358.64.camel@DaveLap> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> Message-ID: <20060422203239.GR12135@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote: > nonono :) I think metadata outside the plugin is without a doubt the > right way to go. I meant I'm just not a huge fan of the particular > syntax of this Turtle stuff (as opposed to normal well-formed XML). > Mostly because it means we need special tools and who knows what > libraries to deal with it. you cant usefully read RDF/XML with just an XML parser anyway. It's quite a lot of work to transform from the XML tree to the RDF graph. But yes, Turtle support is less widespeard than RDF/XML, but there are still Free/Open parsers for every language I can think of (C(++), perl, java, python, ruby, javascript, etc.) - Steve From drobilla at connect.carleton.ca Sat Apr 22 16:48:28 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 16:49:03 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422201008.GM12135@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> Message-ID: <1145738908.2358.92.camel@DaveLap> On Sat, 2006-04-22 at 21:10 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 02:47:33PM -0400, Dave Robillard wrote: > > > You could do pluginUri#portShortName, it's a fairly common convention (eg. > > > in HTML). But youre only allowed a small set of characters after the #. > > > > > > > I think the regexp you mentioned there is fine, though I think we should > > > > add one separator character other than underscore for various reasons. > > > > ":" maybe? > > > > > > I'd rather not, I'm not sure its legal in Pd (they get bitten by the port > > > name thing too), and its not in C. Pure selfinterest, but My LADSPA code > > > is about 50% generated from XML, and I use short names internally for C > > > symbols. > > > > Well, at least one kind of separator character is required (for big > > plugins). If it can't be ":", then I don't know what, but there needs > > to be something. Maybe "."? If you want to keep it as a valid C > > identifier I guess we're pretty much screwed, aside from defining __ to > > be interpreted as a sort of heirarchialish separator. > > I'm missing the need for heirachicalness. : is probably not safe in OSC > either. voice_1_osc_1_volume voice_2_osc_3_volume Or metaplugins (which ability to load libraries will surely spawn). subplug_1_param1 subplug_2_param4 ... ugh voice_1.osc_1.volume ... oh so much nicer. There already exists a few DSSI plugins with ports like this. Surely there's got to be /one/ more sensible character we can add? (It needs to be valid as a jack port name as well) > > I'm fully in support of putting any and all metadata outside the C file, > > but the unique identifier isn't metadata, it should be in the code. A > > trivial OSC controlled plugin host (which would make a good bundled > > example client for the SDK) would need it. > > It's only /a/ unique identifier. We can't loose the index number as thats > the efficent way you access the LADSPA_Data pointers. Only one can be > canonical. I think the above case of a trivial C host requiring it is justification enough to have it in the code. Think about an engine/client split system (where the engine might be something that doesn't have the resources to load metadata and parse RDF etc, eg a DSP). The metadata would be client-side, but the plugin engine-side, so the engine needs access to the label in order to provide the nicer (eg) OSC namespace. Not having it in the code makes a device like this impossible (think Nord Modular or Plugzilla). That'd be a shame ;) -DR- From drobilla at connect.carleton.ca Sat Apr 22 16:54:02 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 16:54:10 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422203239.GR12135@login.ecs.soton.ac.uk> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> <20060422203239.GR12135@login.ecs.soton.ac.uk> Message-ID: <1145739243.2358.98.camel@DaveLap> On Sat, 2006-04-22 at 21:32 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote: > > nonono :) I think metadata outside the plugin is without a doubt the > > right way to go. I meant I'm just not a huge fan of the particular > > syntax of this Turtle stuff (as opposed to normal well-formed XML). > > Mostly because it means we need special tools and who knows what > > libraries to deal with it. > > you cant usefully read RDF/XML with just an XML parser anyway. It's quite > a lot of work to transform from the XML tree to the RDF graph. > > But yes, Turtle support is less widespeard than RDF/XML, but there are > still Free/Open parsers for every language I can think of (C(++), perl, > java, python, ruby, javascript, etc.) As long as it's part of the SDK (and the SDK doesn't have ridiculous requirements), I say it's fine. Speaking of SDK, the LADSPA2 SDK should include the above, and a (strict as possible) demolition equivalent - not to mention example plugins that are actually correct :) -DR- From pshirkey at boosthardware.com Sat Apr 22 16:56:45 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Apr 22 16:57:30 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <1145603686.4773.5.camel@localhost.localdomain> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> <1145603686.4773.5.camel@localhost.localdomain> Message-ID: <444A988D.5050604@boosthardware.com> Hi, Thanks for the feedback so far. Here are the main concerns for me at this point: - Can we force a central repository on developers. Would developers support a Firefox style plugin portal? The site will fail if it requires manual updating by the site maintainer. The onus would have to be on each developer to update and add to the repository as they create or update their code. - Could we automate the xml schema to remove that hassle for developers? This would allow changes to be made to the schema without requiring manual updates for every plugin. - I think the most effective way to manage and package the repository would be if each plugin was catalogued independantly. This would allow for a single package to be created using one install procedure. We could even go further and provide a daemon/app that could install/update plugins as they are added to the repository. I appreciate your thoughts. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From drobilla at connect.carleton.ca Sat Apr 22 17:21:36 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 17:21:59 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <444A988D.5050604@boosthardware.com> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> <1145603686.4773.5.camel@localhost.localdomain> <444A988D.5050604@boosthardware.com> Message-ID: <1145740896.2358.113.camel@DaveLap> On Sun, 2006-04-23 at 03:56 +0700, Patrick Shirkey wrote: > Hi, > > Thanks for the feedback so far. > > Here are the main concerns for me at this point: > > - Can we force a central repository on developers. Would developers > support a Firefox style plugin portal? The site will fail if it requires > manual updating by the site maintainer. The onus would have to be on > each developer to update and add to the repository as they create or > update their code. > > - Could we automate the xml schema to remove that hassle for developers? > This would allow changes to be made to the schema without requiring > manual updates for every plugin. I think this is something that should be a primary concern addressed with LADSPA2. There really aren't /that/ many LADSPA plugins around, I think making LADSPA2 plugins suitable for a repository like this and just porting plugins is a better plan than having an overly complicated repository that tries to work around LADSPA1's unsuitability for it. Plugins having URI's and some sort of standard package format (that Steve has already proposed) is all that's needed. I personally promise to port the lesser known unmaintained plugins to LADSPA2 if it will solve the Big Maintainer-Based Package Problem (which causes considerable grief in Om land) and make a repository like this possible. That said, I think an approach like Arch might be best here - with a standard package format, a plugin "repository" could just be a directory on a server somewhere and apps could resolve (resolvable) URIs to grab any plugins they need. Devs could handle their own package "repositories" rather than be forced to deal with a centralized site, as I'm sure some of the bigger names would probably rather do. A central site would still be a good thing though, on the user end of things. -DR- From luisgarrido at users.sourceforge.net Sat Apr 22 17:43:07 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Sat Apr 22 17:43:12 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145738908.2358.92.camel@DaveLap> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> Message-ID: It is good (tm) to define broad standards that encompass a variety of situations. But usually broad means also thin, which results in it being less helpful for each specific situation it pretends to be applied to. And no matter how broad you try to make it, I bet someone comes up with a feature that is absolutely essential for his/her purposes that the standard should cover but fails to. How broad do we want it? Wouldn't it be a good idea to survey what people are doing with LADSPA and what are they missing in it? Personally, I don't need any more modular synths, thanks. I miss the most in LADSPA: - Sensible GUIs. - Tempo awareness. Cheers, Luis From drobilla at connect.carleton.ca Sat Apr 22 18:31:29 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 18:31:38 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> Message-ID: <1145745089.2358.148.camel@DaveLap> On Sat, 2006-04-22 at 23:43 +0200, Luis Garrido wrote: > It is good (tm) to define broad standards that encompass a variety of > situations. But usually broad means also thin, which results in it > being less helpful for each specific situation it pretends to be > applied to. > > And no matter how broad you try to make it, I bet someone comes up > with a feature that is absolutely essential for his/her purposes that > the standard should cover but fails to. > > How broad do we want it? Wouldn't it be a good idea to survey what > people are doing with LADSPA and what are they missing in it? > > Personally, I don't need any more modular synths, thanks. I'm going to assume this is a shot at me for rather obvious reasons. Since you must know, my thoughts are mostly with Ardour, which will soon be OSC controlled. You may have noticed that Ardour isn't a modular synth. Fancy that. > I miss the most in LADSPA: > - Sensible GUIs. *sigh* someone just had to do it, didn't they? We don't need another inifinitely long GUI toolkit pissing match thread that is guaranteed to lead absolutely nowhere, thanks. LAD_S_PA2 is not going to have GUIs. http://dssi.sf.net. Enjoy. Now can we please have a productive discussion about fixing very real problems with LADSPA without /that/ *&%$% topic ruining everything, yet again, thanks? -DR- From luisgarrido at users.sourceforge.net Sat Apr 22 19:10:34 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Sat Apr 22 19:10:40 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145745089.2358.148.camel@DaveLap> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <1145745089.2358.148.camel@DaveLap> Message-ID: > I'm going to assume this is a shot at me for rather obvious reasons. No, I was more thinking in Phil Frost's contribution to this discussion (contribution that I find very interesting and pertinent, but as a musician I am not interested in LADSPA becoming another low level LEGO api to build modular synths, there are already some good solutions to that problem). > *sigh* someone just had to do it, didn't they? GUIs appeared in the thread long before my post. > LAD_S_PA2 is not going to have GUIs. http://dssi.sf.net. Enjoy. I am well aware of that. Thanks for the pointer, anyway. http://flam.sf.net But still there are some parts of LADSPA that have to provide information for effective (auto)building of GUIs. > Now can we please have a productive discussion about fixing very real > problems with LADSPA without /that/ *&%$% topic ruining everything, yet > again, thanks? My apologies for bothering you. I will just return silently to my playground and let the real men do the real stuff. Peace, Luis From drobilla at connect.carleton.ca Sat Apr 22 19:35:42 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 22 19:35:53 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: References: <20060422095358.GD715@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <1145745089.2358.148.camel@DaveLap> Message-ID: <1145748942.2358.166.camel@DaveLap> On Sun, 2006-04-23 at 01:10 +0200, Luis Garrido wrote: > > I'm going to assume this is a shot at me for rather obvious reasons. > > No, I was more thinking in Phil Frost's contribution to this > discussion (contribution that I find very interesting and pertinent, > but as a musician I am not interested in LADSPA becoming another low > level LEGO api to build modular synths, there are already some good > solutions to that problem). My apologies then. I've become accustomed to knee-jerk anti modular reactions whenever I use anything remotely modular as an example for something. :) Frankly I don't understand the phenomenon at all, your comments are a perfect example. The source code idea would mostly be beneficial for building stand-alone static (ie non modular) synths. The UI for /creating/ them would be modular probably, since that's really the only really reasonable UI for doing so, but it wouldn't /have/ to be. Yet, you say the word "modular" and the idea is automatically cast aside by everyone. You make the exact same point without saying the magic M word, and my, what an interesting idea! I Don't Get It(TM), but whatever. I suppose it's like math, non math people see one Sigma and their brains just turn off immediately. I just make sure not to say the magic M word wherever possible to avoid it. ;) [/digression] > > *sigh* someone just had to do it, didn't they? > > GUIs appeared in the thread long before my post. > > > LAD_S_PA2 is not going to have GUIs. http://dssi.sf.net. Enjoy. > > I am well aware of that. Thanks for the pointer, anyway. > > http://flam.sf.net > > But still there are some parts of LADSPA that have to provide > information for effective (auto)building of GUIs. I am of the opinion that auto generated UIs is not the way to go in general, but regardless that's the beauty of external metadata. You can experiment with whatever added data you like, if it works well people will start using it and it might become part of the standard eventually. LADSPA has long been hindered by the draconian pre-defined nature of C ABIs. With rigorously seperated metadata we'll finally be able to experiment with things like this without breaking things and LADSPA can evolve... -DR- From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 02:53:19 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 02:53:42 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145738908.2358.92.camel@DaveLap> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> Message-ID: <20060423065318.GB398@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard wrote: > > > Well, at least one kind of separator character is required (for big > > > plugins). If it can't be ":", then I don't know what, but there needs > > > to be something. Maybe "."? If you want to keep it as a valid C > > > identifier I guess we're pretty much screwed, aside from defining __ to > > > be interpreted as a sort of heirarchialish separator. > > > > I'm missing the need for heirachicalness. : is probably not safe in OSC > > either. > > voice_1_osc_1_volume > voice_2_osc_3_volume That looks fine to me... > Or metaplugins (which ability to load libraries will surely spawn). > > subplug_1_param1 > subplug_2_param4 > > ... ugh > > voice_1.osc_1.volume Hum, that looks suspiciously like its expressing some semantics that don't exist to me, and could potentially conflict with the port name (UI) semantics "Osc 1/Frequency" etc. > ... oh so much nicer. There already exists a few DSSI plugins with > ports like this. Surely there's got to be /one/ more sensible character > we can add? (It needs to be valid as a jack port name as well) But you're not talking about anything hard, its just a symbol name, used to refer to the port, sometimes... I'm starting to go off this idea, noone else has spoken in defense of it, and it raises some issues. > > > I'm fully in support of putting any and all metadata outside the C file, > > > but the unique identifier isn't metadata, it should be in the code. A > > > trivial OSC controlled plugin host (which would make a good bundled > > > example client for the SDK) would need it. > > > > It's only /a/ unique identifier. We can't loose the index number as thats > > the efficent way you access the LADSPA_Data pointers. Only one can be > > canonical. > > I think the above case of a trivial C host requiring it is justification > enough to have it in the code. Think about an engine/client split > system (where the engine might be something that doesn't have the > resources to load metadata and parse RDF etc, eg a DSP). The metadata > would be client-side, but the plugin engine-side, so the engine needs > access to the label in order to provide the nicer (eg) OSC namespace. It would use the index numbers. DSP chips and trivial C hosts are not going to strcmp() to match ports up. You can't run a LADSPA2 plugin without some part of the system being able to parse some data anyway, because you dont know what the ports are for. It's OK, the host CPU can do it, and pass the information to the DSP chip. - Steve From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 02:56:16 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 02:56:41 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: References: <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> Message-ID: <20060423065616.GC398@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 11:43:07 +0200, Luis Garrido wrote: > I miss the most in LADSPA: > - Sensible GUIs. > - Tempo awareness. I should have been clear before, but I'm not interested in adding more features to LADSPA, right now. I want to replace the cruft-filled C ABI metadata system with something generic. Ideally I would like LADSPA 2.0 to be exactly as capable as LADSPA 1.1. There are some things that need ABI changes, but lets minime that. Once LADSPA 2.0 has been finalised, extensions can be tried, and eventaully added without changing 2.0. - Steve From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 03:08:13 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 03:08:35 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <1145739243.2358.98.camel@DaveLap> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> <20060422203239.GR12135@login.ecs.soton.ac.uk> <1145739243.2358.98.camel@DaveLap> Message-ID: <20060423070813.GD398@login.ecs.soton.ac.uk> On Sat, Apr 22, 2006 at 04:54:02 -0400, Dave Robillard wrote: > On Sat, 2006-04-22 at 21:32 +0100, Steve Harris wrote: > > On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote: > > > nonono :) I think metadata outside the plugin is without a doubt the > > > right way to go. I meant I'm just not a huge fan of the particular > > > syntax of this Turtle stuff (as opposed to normal well-formed XML). > > > Mostly because it means we need special tools and who knows what > > > libraries to deal with it. > > > > you cant usefully read RDF/XML with just an XML parser anyway. It's quite > > a lot of work to transform from the XML tree to the RDF graph. > > > > But yes, Turtle support is less widespeard than RDF/XML, but there are > > still Free/Open parsers for every language I can think of (C(++), perl, > > java, python, ruby, javascript, etc.) > > As long as it's part of the SDK (and the SDK doesn't have ridiculous > requirements), I say it's fine. I think a C header, RDF Schema, and bit a of example code is sufficient. That's all the LADSPA 1.1 SDK is. If I was writing the example code, I'd link to rasqal (http://librdf.org/rasqal/) which can query RDF/Turtle files from disk efficiently. Of course if people want to bundle up some tools and helper functions for convienince then that's great, I dont think we want an SDK library though. > Speaking of SDK, the LADSPA2 SDK should include the above, and a (strict > as possible) demolition equivalent - not to mention example plugins that > are actually correct :) Yeah, that would help :-/ - Steve From musical_snake at gmx.de Sun Apr 23 03:12:25 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Sun Apr 23 03:20:27 2006 Subject: [linux-audio-dev] LACPA In-Reply-To: <20060422095358.GD715@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> Message-ID: <444B28D9.1060005@gmx.de> Since people seem to see the necessity for some more functionality within plugins, i want to present LACPA (Linux Audio Cluster Plugin Api), which was intended to be the plugin api of the linux audio cluster (which i never finished due to the lack of time). Its main features: * usable for midi/audio plugins (one plugin could be a host for other plugins as well) * sampleaccurate timeinfo for sequencers, tempo-synched effects/instruments, video * fixed size audiobuffers (good for use with networks and frequency domain effects) * extensible while keeping binary downward compatability * no dependencies between host's and plugin's gui (plugins guis are supposed to run in their own process) BTW, by adding a control type "message", the realtime message part of LACPA could be easily added to LADSPA without breaking existing hosts . Ralf -------------- next part -------------- #ifndef LACPA #define LACPA #ifdef __cplusplus extern "C" { #endif /* return value for all functions */ #define LACPA_NOT_PROCESSED 0 #define LACPA_PROCESSED 1 typedef float LACPA_FRAME; /* audio type -1.0 .. +1.0 */ typedef float LACPA_CONTROL; /* control type 0.0 .. 1.0 */ /* opaque plugin type */ typedef void * LACPA_PLUGIN; /* initialise is called by host immediately after loading the library: PARAMETERS: plug2host: callback for plug -> host non-realtime messages */ int (*initialise)(int (*plug2host)(LACPA_PLUGIN plug, int msg, void *arg, void *ret)); /* create a new plugin instance Note: a plugin is initially suspended and has its editor closed */ LACPA_PLUGIN (*create)(void); /* delete a plugin instance PARAMETERS: plug : plugin instance returne by create() */ int (*delete)(LACPA_PLUGIN plug); /* callback to be used by the plugin to send a non-realtime message to the host. Must be supplied by the host in initialise(). PARAMETERS: plug: plugin instance returned by create() msgtype: non-realtime plug -> host message type arg: pointer to message specific arguments ret: pointer for returning values int (*plug2host)(LACPA_PLUGIN plug, int msgtype, void *arg, void *ret); Following plug -> host messages are currently defined: LACPA_EDIT_OFF: arg = NULL, ret = NULL: editor window has been closed LACPA_IO_CHANGE: arg = NULL, ret = NULL: plugin changed its inputs or outputs In response to this the host is supposed to suspend the plugin and reread the i/o configuration */ #define LACPA_EDIT_OFF 1 #define LACPA_IO_CHANGE 2 /* non-realtime host to plugin messages PARAMETERS: plug: plugin instance returned by create() msgtype: non-realtime host -> plugin message type arg: message specific arguments ret: returned values */ int (*host2plug)(LACPA_PLUGIN instance, int msgtype, void *arg, void *ret); /* Following plug -> host messages are currently defined: LACPA_VENDOR_SPECIFIC: used for vendor specific messages LACPA_PROCESS_START: arg = NULL, ret = NULL: process will be called from now LACPA_PROCESS_STOP: arg = NULL, ret = NULL: process will not be called from now LACPA_PLUGIN_NAME: arg = NULL, ret = char * = name of plugin LACPA_PLUGIN_CATEGORY: arg = NULL, ret = char * = name of plugin category LACPA_PLUGIN_VENDOR: arg = NULL, ret = char * = name of plugin vendor LACPA_SAMPLERATE: arr = int samplerate, ret = NULL: set the samplerate (called while suspended) LACPA_BUFFERSIZE: arg = int buffersize, ret = NULL: set the buffersize (called while suspended) LACPA_NUM_PARAMETERS: arg = NULL, ret = int = number of controls LACPA_CONTROL_VALUE: arg = struct control, ret = char * = human readable of the value (e.g. "-20") LACPA_CONTROL_UNIT: arg = int index, ret = char * = human readable unit of value (e.g. "dB") LACPA_CONTROL_NAME: arg = int index, ret = char * = name of control (e.g. "Gain") LACPA_NUM_INPUTS: arg = NULL, ret = int = number of inputs LACPA_NUM_OUTPUTS: arg = NULL, ret = int = number of outputs LACPA_INPUT_NAME: arg = int index, ret = char * = name of audio channel (e.g. "left input") LACPA_OUTPUT_NAME: arg = int index, ret = char * = name of audio channel (e.g. "left output") LACPA_TICKS_PER_BEAT: arg int tpb: set the ticks per beat (sequencer resolution) LACPA_SMPTE_TYPE: arg int smpte: set the SMPTE type (see below) LACPA_LATENCY: arg = NULL, ret = int latency: get plugin latency in samples LACPA_EDITOR_ON: arg = NULL, ret = NULL: instruct plugin to open its editor window LACPA_EDITOR_OFF: arg = NULL, ret = NULL: instruct plugin to close its editor window */ #define LACPA_VENDOR_SPECIFIC 0 #define LACPA_PROCESS_START 1 #define LACPA_PROCESS_STOP 2 #define LACPA_PLUGIN_NAME 3 #define LACPA_PLUGIN_CATEGORY 4 #define LACPA_PLUGIN_VENDOR 5 #define LACPA_SAMPLERATE 6 #define LACPA_BUFFERSIZE 7 #define LACPA_NUM_CONTROLS 8 #define LACPA_CONTROL_NAME 9 #define LACPA_CONTROL_UNIT 10 #define LACPA_CONTROL_VALUE_STRING 11 #define LACPA_NUM_INPUTS 12 #define LACPA_NUM_OUTPUTS 13 #define LACPA_INPUT_NAME 14 #define LACPA_OUTPUT_NAME 15 #define LACPA_TICKS_PER_BEAT 16 #define LACPA_SMPTE_TYPE 17 #define LACPA_LATENCY 18 #define LACPA_EDITOR_ON 19 #define LACPA_EDITOR_OFF 20 /* SMPTE types */ #define LACPA_SMPTE_24 1 #define LACPA_SMPTE_25 2 #define LACPA_SMPTE_30 3 #define LACPA_SMPTE_29d 4 #define LACPA_SMPTE_30d 5 /* realtime processing routine PARAMETERS: plug: plugin instance returned by create() inmsg: pointer to linked list of realtime messages for plugin outmsg: pointer to pointer to linked list for realtime messages produced by plugin in: pointer to array of pointers to input buffers out: pointer to array of pointers to output buffers */ struct lacpa_rt_msg; typedef struct lacpa_rt_msg *LACPA_MSG; int (*process)(LACPA_PLUGIN plug, LACPA_MSG *inmsg, LACPA_MSG **outmsg, LACPA_FRAME **in, LACPA_FRAME **out); /* realtime messages to be sent to/from plugin through process(): LACPA_MIDI: 1-3 byte midi messages LACPA_SYSEX: Midi sysex message LACPA_CTRL: control, range 0.0 - 1.0 LACPA_BBT: Timeinfo in Beats/Bar/Ticks LACPA_SMPTE: Timeinfo in SMPTE FRAMES -- more to be added as needed */ #define LACPA_MIDI 0 #define LACPA_SYSEX 1 #define LACPA_CTRL 2 #define LACPA_BBT 3 #define LACPA_SMPTE 4 struct lacpa_midi { int port; char data[4]; }; struct lacpa_sysex { int port; char *sysex; }; struct lacpa_ctrl { int index; LACPA_CONTROL value; }; struct lacpa_tempo { float tempo; }; struct lacpa_bbt { int bar; int beat; int tick; }; struct lacpa_smpte { int hour; int minute; int second; int frame; }; struct lacpa_rt_msg { LACPA_MSG next; /* next message in list */ int type; /* type of realtime message */ int frame; /* frame number within current process buffer */ union { struct lacpa_midi m; struct lacpa_sysex x; struct lacpa_ctrl p; struct lacpa_tempo t; struct lacpa_bbt b; struct lacpa_smpte s; } lacpa_msg; }; #ifdef __cplusplus } #endif #endif /* LACPA */ From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 04:29:47 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 04:30:24 2006 Subject: [linux-audio-dev] LADSPA 2 example plugin changes Message-ID: <20060423082947.GE398@login.ecs.soton.ac.uk> http://plugin.org.uk/ladspa2/ First of all, I realised I was being cheeky by adding a feature I wanted (units), while refusing to consider anyone elses! So, I removed the units property from the Amp plugin. I'm happy to consider it a testcase and I will make a schema for it and start using it when/if LADSPA2 gets OKd by the community. I made 2 actual ABI changes: The path of the directory/bundle is passed to instantiate(). This is neccessary to make it actually useful. It could have been passed to other methods, but that seemed most appropriate. For some potential features, like Fons' polyphonic control ports, it's hard for the plugin to detect wether the host is using the feature or not. I added an array of URIs to instantiate() that lets the host tell the plugin what hints etc. it supports. The plugin can then refuse to instantiate or fall back if it doesn't like the featureset. I also added some (silly) scale points to the Amp plugin, just to show how it's done, and I added translations to some of the strings, to show how that's done. - Steve From mista.tapas at gmx.net Sun Apr 23 07:10:55 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Apr 23 07:11:05 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060422095358.GD715@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> Message-ID: <20060423131055.2a366786@mango.fruits> On Sat, 22 Apr 2006 10:53:58 +0100 Steve Harris wrote: > Almost two years ago at the LA conference a bunch of us agreed that > something need to be done to improve LADSPA, and on the approximate > direction it should take. > > Anyway, I finally got round to making a sketch plugin and .h file: > http://plugin.org.uk/ladspa2/ Hi, thanks for taking the initiative on this! I would like to see a way for the host to pass its native buffer size to the plugin though. I know, this is really kind of contrary to how LADSPA is supposed to work (i.e. the run () function should be able to handle an arbitrary number of frames), but it has some serious advantages for fft-based algorithms. And i think it should be possible to merge the two approaches somewhat. A hint which the plugin could set that it needs power of two periodsizes for optimal operation would be nice, too. The host should be free to ignore this and the plugin should still work (doing what it sees fit. i.e. use non power of two fft window sizes or use double buffering again), but at least the host could notify the user that this plugin might work suboptimal. The approach of chopping up the period into smaller chunks (i.e. to update control data at non period boundaries) would still be available, but the plugin should be able to rely on the chunks being i.e. in this form: ---> time |128 |128 | | | | | | | | | | Native buffer size being 128 frames [upper row] and the lower row is how it is chopped up [as an example]. We see that all chopped up chunks add up to the native period size. This enables an fft based plugin to collect data over a whole period and do its stuff once for all these samples, without the need for extra double buffering which is a problem with current ladspa and dssi. There would be an additional requirement put on the host: It has to use a fixed underlying buffersize [optimally a power of two] even if it's not bound to do this by the hardware/soundinterface it uses. I.e. a host that does the processing freewheeling. What do you think? Flo -- Palimm Palimm! http://tapas.affenbande.org From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 08:39:52 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 08:40:13 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060423131055.2a366786@mango.fruits> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060423131055.2a366786@mango.fruits> Message-ID: <20060423123952.GA5628@login.ecs.soton.ac.uk> On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian Schmidt wrote: > thanks for taking the initiative on this! I would like to see a way for > the host to pass its native buffer size to the plugin though. I know, > this is really kind of contrary to how LADSPA is supposed to work (i.e. > the run () function should be able to handle an arbitrary number of > frames), but it has some serious advantages for fft-based algorithms. > And i think it should be possible to merge the two approaches somewhat. Thats a new feature. It'll have to wait til after 2.0 as far as I'm concerned. - Steve From mista.tapas at gmx.net Sun Apr 23 11:04:18 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Apr 23 11:04:35 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060423123952.GA5628@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060423131055.2a366786@mango.fruits> <20060423123952.GA5628@login.ecs.soton.ac.uk> Message-ID: <20060423170418.00303c6d@mango.fruits> On Sun, 23 Apr 2006 13:39:52 +0100 Steve Harris wrote: > On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian Schmidt wrote: > > thanks for taking the initiative on this! I would like to see a way for > > the host to pass its native buffer size to the plugin though. I know, > > this is really kind of contrary to how LADSPA is supposed to work (i.e. > > the run () function should be able to handle an arbitrary number of > > frames), but it has some serious advantages for fft-based algorithms. > > And i think it should be possible to merge the two approaches somewhat. > > Thats a new feature. It'll have to wait til after 2.0 as far as I'm > concerned. I tend to disagree as it is kinda orthogonal to the other proposed changes. What time other than a major version change is better to add such a feature? Aw hell, i'll try to get this into DSSI 2 then ;) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From larsl at users.sourceforge.net Sun Apr 23 11:16:11 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Apr 23 11:16:28 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060423170418.00303c6d@mango.fruits> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060423131055.2a366786@mango.fruits> <20060423123952.GA5628@login.ecs.soton.ac.uk> <20060423170418.00303c6d@mango.fruits> Message-ID: <1145805371.8841.8.camel@localhost> On Sun, 2006-04-23 at 17:04 +0200, Florian Schmidt wrote: > On Sun, 23 Apr 2006 13:39:52 +0100 > Steve Harris wrote: > > > On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian Schmidt wrote: > > > thanks for taking the initiative on this! I would like to see a way for > > > the host to pass its native buffer size to the plugin though. I know, > > > this is really kind of contrary to how LADSPA is supposed to work (i.e. > > > the run () function should be able to handle an arbitrary number of > > > frames), but it has some serious advantages for fft-based algorithms. > > > And i think it should be possible to merge the two approaches somewhat. > > > > Thats a new feature. It'll have to wait til after 2.0 as far as I'm > > concerned. > > I tend to disagree as it is kinda orthogonal to the other proposed > changes. What time other than a major version change is better to add > such a feature? > > Aw hell, i'll try to get this into DSSI 2 then ;) Couldn't it be done as an extension using the "features" parameter to the instantiation function? If the host supports fixed buffer sizes it can pass "FIXEDSIZE" or something in the features array, and the plugin can add some sort of flag in the TTL file that says that it wants to be called with a fixed buffer size. No need to add it explicitly in the LADSPA2 specification. Then, when the plugin sees that the host has the "FIXEDSIZE" feature, it will know that the buffer size will always be the same. Hosts that don't support this extension will ignore the flag in the TTL file and will not pass the "FIXEDSIZE" feature to the instantiation function, and the plugin can then either return NULL from that function, or switch automatically to less efficient code that does not need a fixed buffer size. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060423/f6d8ea8f/attachment-0001.bin From drobilla at connect.carleton.ca Sun Apr 23 11:25:59 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 23 11:17:55 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060423065318.GB398@login.ecs.soton.ac.uk> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060422122657.GA27302@charly.SWORD> <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> Message-ID: <1145805959.2493.22.camel@DaveLap> On Sun, 2006-04-23 at 07:53 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard wrote: > > > > Well, at least one kind of separator character is required (for big > > > > plugins). If it can't be ":", then I don't know what, but there needs > > > > to be something. Maybe "."? If you want to keep it as a valid C > > > > identifier I guess we're pretty much screwed, aside from defining __ to > > > > be interpreted as a sort of heirarchialish separator. > > > > > > I'm missing the need for heirachicalness. : is probably not safe in OSC > > > either. > > > > voice_1_osc_1_volume > > voice_2_osc_3_volume > > That looks fine to me... > > > Or metaplugins (which ability to load libraries will surely spawn). > > > > subplug_1_param1 > > subplug_2_param4 > > > > ... ugh > > > > voice_1.osc_1.volume > > Hum, that looks suspiciously like its expressing some semantics that don't > exist to me, and could potentially conflict with the port name (UI) > semantics "Osc 1/Frequency" etc. > > > ... oh so much nicer. There already exists a few DSSI plugins with > > ports like this. Surely there's got to be /one/ more sensible character > > we can add? (It needs to be valid as a jack port name as well) > > But you're not talking about anything hard, its just a symbol name, used > to refer to the port, sometimes... I'm starting to go off this idea, noone > else has spoken in defense of it, and it raises some issues. *shrug* All I want is one character that would be useful for organizing port names in a much nicer looking fashion. I can live without if it's really a big deal and there's no safe character, it'd just make for much nicer looking port names on complicated plugins is all. Dropped. > > > > I'm fully in support of putting any and all metadata outside the C file, > > > > but the unique identifier isn't metadata, it should be in the code. A > > > > trivial OSC controlled plugin host (which would make a good bundled > > > > example client for the SDK) would need it. > > > > > > It's only /a/ unique identifier. We can't loose the index number as thats > > > the efficent way you access the LADSPA_Data pointers. Only one can be > > > canonical. > > > > I think the above case of a trivial C host requiring it is justification > > enough to have it in the code. Think about an engine/client split > > system (where the engine might be something that doesn't have the > > resources to load metadata and parse RDF etc, eg a DSP). The metadata > > would be client-side, but the plugin engine-side, so the engine needs > > access to the label in order to provide the nicer (eg) OSC namespace. > > It would use the index numbers. DSP chips and trivial C hosts are not going > to strcmp() to match ports up. You can't run a LADSPA2 plugin without some > part of the system being able to parse some data anyway, because you dont > know what the ports are for. It's OK, the host CPU can do it, and pass the > information to the DSP chip. It wouldn't use the index numbers if it wants to provide the sensible OSC namespace (as for strcmp you can do the symbol thing w/ (perfect) hashing to make it fast). Ditto for a language providing a sensible API. The label is not metadata, it is a unique identifier. But anyway, why can't it go in the code? I want to keep the C part minimal as well, but this is a unique identifier, the sole thing that actually does belong in the code. I need this to create an app/device like the above. What's the better reason it's a bad idea? Plugins have a unique string ID, and I need ports to as well. If any LADSPA devs are opposed (or not) to giving each port a unique label in the code, feel free weigh in... -DR- From drobilla at connect.carleton.ca Sun Apr 23 11:44:03 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 23 11:31:29 2006 Subject: [linux-audio-dev] LADSPA 2 example plugin changes In-Reply-To: <20060423082947.GE398@login.ecs.soton.ac.uk> References: <20060423082947.GE398@login.ecs.soton.ac.uk> Message-ID: <1145807043.2493.32.camel@DaveLap> On Sun, 2006-04-23 at 09:29 +0100, Steve Harris wrote: > http://plugin.org.uk/ladspa2/ > > First of all, I realised I was being cheeky by adding a feature I wanted > (units), while refusing to consider anyone elses! So, I removed the units > property from the Amp plugin. I'm happy to consider it a testcase and I > will make a schema for it and start using it when/if LADSPA2 gets OKd by > the community. > > I made 2 actual ABI changes: > > The path of the directory/bundle is passed to instantiate(). This is > neccessary to make it actually useful. It could have been passed to other > methods, but that seemed most appropriate. "The BundlePath parameter is a string of the path to the plugin's .ladspa2 bundle directory, it SHOULD not include the trailing /." Might as well s/SHOULD/MUST/ so the plugin doesn't have to deal with it. If it's just SHOULD there's not much point in wasting space mentioning it. Just an initial thought: how about adding a similar parameter for a host-provided-things directory? This in combination with the HostFeatures would allow a host to provide almost anything to plugins, like a realtime memory allocator lib, some kind of shared memory scheme for a GUI extension, etc. etc. Much more extensible without having to break the ABI. Thoughts? > For some potential features, like Fons' polyphonic control ports, it's hard > for the plugin to detect wether the host is using the feature or not. I > added an array of URIs to instantiate() that lets the host tell the plugin > what hints etc. it supports. The plugin can then refuse to instantiate or > fall back if it doesn't like the featureset. I think this is an awesome idea, FWIW. -DR- From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 13:59:43 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 14:00:03 2006 Subject: [linux-audio-dev] LADSPA 2 example plugin changes In-Reply-To: <1145807043.2493.32.camel@DaveLap> References: <20060423082947.GE398@login.ecs.soton.ac.uk> <1145807043.2493.32.camel@DaveLap> Message-ID: <20060423175943.GB5628@login.ecs.soton.ac.uk> On Sun, Apr 23, 2006 at 11:44:03 -0400, Dave Robillard wrote: > > The path of the directory/bundle is passed to instantiate(). This is > > neccessary to make it actually useful. It could have been passed to other > > methods, but that seemed most appropriate. > > "The BundlePath parameter is a string of the path to the plugin's > .ladspa2 bundle directory, it SHOULD not include the trailing /." > > Might as well s/SHOULD/MUST/ so the plugin doesn't have to deal with it. > If it's just SHOULD there's not much point in wasting space mentioning > it. Perhaps, well it's not critical, appending /filename will always work under Linux, its just a bit untidy. I used SHOULD incase the host has some trouble removing it for some reason, but I can think why it would have. So yes, MUST would be OK by me. > Just an initial thought: how about adding a similar parameter for a > host-provided-things directory? This in combination with the > HostFeatures would allow a host to provide almost anything to plugins, > like a realtime memory allocator lib, some kind of shared memory scheme > for a GUI extension, etc. etc. Much more extensible without having to > break the ABI. Thoughts? Hmmm... providing a lib that way is a bit late, setting LD_LIBRARY_PATH is more convienient. Given that we dont have anything to put there currently I don't feel really motivated. - Steve From drobilla at connect.carleton.ca Sun Apr 23 15:24:02 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 23 14:16:30 2006 Subject: [linux-audio-dev] LADSPA 2 example plugin changes In-Reply-To: <20060423175943.GB5628@login.ecs.soton.ac.uk> References: <20060423082947.GE398@login.ecs.soton.ac.uk> <1145807043.2493.32.camel@DaveLap> <20060423175943.GB5628@login.ecs.soton.ac.uk> Message-ID: <1145820242.2493.50.camel@DaveLap> On Sun, 2006-04-23 at 18:59 +0100, Steve Harris wrote: > On Sun, Apr 23, 2006 at 11:44:03 -0400, Dave Robillard wrote: > > > The path of the directory/bundle is passed to instantiate(). This is > > > neccessary to make it actually useful. It could have been passed to other > > > methods, but that seemed most appropriate. > > > > "The BundlePath parameter is a string of the path to the plugin's > > .ladspa2 bundle directory, it SHOULD not include the trailing /." > > > > Might as well s/SHOULD/MUST/ so the plugin doesn't have to deal with it. > > If it's just SHOULD there's not much point in wasting space mentioning > > it. > > Perhaps, well it's not critical, appending /filename will always work > under Linux, its just a bit untidy. I used SHOULD incase the host has some > trouble removing it for some reason, but I can think why it would have. > So yes, MUST would be OK by me. Yeah, anything that lessens what plugins have to deal with is the Right Thing. > > Just an initial thought: how about adding a similar parameter for a > > host-provided-things directory? This in combination with the > > HostFeatures would allow a host to provide almost anything to plugins, > > like a realtime memory allocator lib, some kind of shared memory scheme > > for a GUI extension, etc. etc. Much more extensible without having to > > break the ABI. Thoughts? > > Hmmm... providing a lib that way is a bit late, setting LD_LIBRARY_PATH is > more convienient. Given that we dont have anything to put there currently > I don't feel really motivated. So things like this could be provided just by setting a HostFeatures flag that implies a certain library is linked and available for use? That works. (I'm not particularly attached to the idea either way, just a thought. It allows the host to provide things to the plugin in general which could be a good thing considering the change is so minimal). -DR- From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 14:23:15 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 14:23:39 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145805959.2493.22.camel@DaveLap> References: <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> Message-ID: <20060423182315.GC5628@login.ecs.soton.ac.uk> On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote: > But anyway, why can't it go in the code? I want to keep the C part > minimal as well, but this is a unique identifier, the sole thing that > actually does belong in the code. I need this to create an app/device > like the above. What's the better reason it's a bad idea? Plugins have > a unique string ID, and I need ports to as well. Theres no advantage to it being in the code, it means allocating an array of strings, which means repeating the same code in every plugin. Also, you can't get the strings unless you load and link the plugin, which is one of the things were trying to get away from. - Steve From drobilla at connect.carleton.ca Sun Apr 23 15:45:05 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 23 14:32:17 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060423182315.GC5628@login.ecs.soton.ac.uk> References: <20060422163051.GC12135@login.ecs.soton.ac.uk> <1145725586.2358.14.camel@DaveLap> <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> Message-ID: <1145821505.2493.59.camel@DaveLap> On Sun, 2006-04-23 at 19:23 +0100, Steve Harris wrote: > On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote: > > But anyway, why can't it go in the code? I want to keep the C part > > minimal as well, but this is a unique identifier, the sole thing that > > actually does belong in the code. I need this to create an app/device > > like the above. What's the better reason it's a bad idea? Plugins have > > a unique string ID, and I need ports to as well. > > Theres no advantage to it being in the code, it means allocating an array > of strings, which means repeating the same code in every plugin. Also, you > can't get the strings unless you load and link the plugin, which is one of > the things were trying to get away from. The advantage is the mentioned use case which your suggestion destroys. The array can be static anyway, there's not really any "code" added. Are you proposing to put the port index numbers in the metadata as well? Otherwise you couldn't get at them without loading and linking the plugin. So the plugin URI should exclusively go in the metadata file as well? Why is that in the code? -DR- From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 14:39:52 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 14:40:15 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145821505.2493.59.camel@DaveLap> References: <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> Message-ID: <20060423183952.GD5628@login.ecs.soton.ac.uk> On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave Robillard wrote: > On Sun, 2006-04-23 at 19:23 +0100, Steve Harris wrote: > > On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote: > > > But anyway, why can't it go in the code? I want to keep the C part > > > minimal as well, but this is a unique identifier, the sole thing that > > > actually does belong in the code. I need this to create an app/device > > > like the above. What's the better reason it's a bad idea? Plugins have > > > a unique string ID, and I need ports to as well. > > > > Theres no advantage to it being in the code, it means allocating an array > > of strings, which means repeating the same code in every plugin. Also, you > > can't get the strings unless you load and link the plugin, which is one of > > the things were trying to get away from. > > The advantage is the mentioned use case which your suggestion destroys. > The array can be static anyway, there's not really any "code" added. I don't see how it affects the usecase. You /always/ need to read at least some of the data somehwere to use the plugin. > Are you proposing to put the port index numbers in the metadata as well? > Otherwise you couldn't get at them without loading and linking the > plugin. Of course, it's ladspa:index if the numbers aren't there then theres nothing to link the port data to the float *. > So the plugin URI should exclusively go in the metadata file as well? > Why is that in the code? It has to be in the struct, otherwise you don't know what functions to call to get a particular plugin. - Steve From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 14:46:04 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 14:46:20 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060423170418.00303c6d@mango.fruits> References: <20060422095358.GD715@login.ecs.soton.ac.uk> <20060423131055.2a366786@mango.fruits> <20060423123952.GA5628@login.ecs.soton.ac.uk> <20060423170418.00303c6d@mango.fruits> Message-ID: <20060423184604.GE5628@login.ecs.soton.ac.uk> On Sun, Apr 23, 2006 at 05:04:18PM +0200, Florian Schmidt wrote: > On Sun, 23 Apr 2006 13:39:52 +0100 > Steve Harris wrote: > > > On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian Schmidt wrote: > > > thanks for taking the initiative on this! I would like to see a way for > > > the host to pass its native buffer size to the plugin though. I know, > > > this is really kind of contrary to how LADSPA is supposed to work (i.e. > > > the run () function should be able to handle an arbitrary number of > > > frames), but it has some serious advantages for fft-based algorithms. > > > And i think it should be possible to merge the two approaches somewhat. > > > > Thats a new feature. It'll have to wait til after 2.0 as far as I'm > > concerned. > > I tend to disagree as it is kinda orthogonal to the other proposed > changes. What time other than a major version change is better to add > such a feature? Generally, I'd agree, but in this case I think it's a bad time. We need to make sure we dont introduce anything that wierds the spec. It changes both plugin and host code, so it will be easier to add things once both have settled down, and the rought edges have been knocked off. - Steve From drobilla at connect.carleton.ca Sun Apr 23 16:26:03 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 23 15:03:01 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060423183952.GD5628@login.ecs.soton.ac.uk> References: <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> Message-ID: <1145823963.2493.80.camel@DaveLap> On Sun, 2006-04-23 at 19:39 +0100, Steve Harris wrote: > On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave Robillard wrote: > > On Sun, 2006-04-23 at 19:23 +0100, Steve Harris wrote: > > > On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote: > > > > But anyway, why can't it go in the code? I want to keep the C part > > > > minimal as well, but this is a unique identifier, the sole thing that > > > > actually does belong in the code. I need this to create an app/device > > > > like the above. What's the better reason it's a bad idea? Plugins have > > > > a unique string ID, and I need ports to as well. > > > > > > Theres no advantage to it being in the code, it means allocating an array > > > of strings, which means repeating the same code in every plugin. Also, you > > > can't get the strings unless you load and link the plugin, which is one of > > > the things were trying to get away from. > > > > The advantage is the mentioned use case which your suggestion destroys. > > The array can be static anyway, there's not really any "code" added. > > I don't see how it affects the usecase. You /always/ need to read at least > some of the data somehwere to use the plugin. Well, the plugin should be at least runnable without the metadata. Sure you'll know almost nothing about it, but you should be able to run it (eg in fixed code where you know the parameters and whatnot you're using are fine). (No user interacting app could feasibly do so though) The "somewhere" part is my point. This 'device' can not read metadata files, yet it needs to know the port IDs. Therefore the port IDs need to be in the code. > > Are you proposing to put the port index numbers in the metadata as well? > > Otherwise you couldn't get at them without loading and linking the > > plugin. > > Of course, it's ladspa:index if the numbers aren't there then theres > nothing to link the port data to the float *. > > > So the plugin URI should exclusively go in the metadata file as well? > > Why is that in the code? > > It has to be in the struct, otherwise you don't know what functions to > call to get a particular plugin. In other words it's there because it's a unique identifier for the plugin, used to reference it. I say port IDs need to be there for the same reason. Ports should be first class citizens with a proper identifier and all, IMO. Anyway, putting IDs in the metadata implies that, well, they're metadata, and can be fiddled with without breaking things. This is not true. They are unique identifiers (along with their plugin's URIs they define a URI) and as such are set in stone and must not change. They're just not metadata. But I want to emphasize the 'device' (or trivial host app, etc) over arguments about word definitions etc. I really don't want to have to fork LADSPA into an ABI incompatible derivative over something silly like this. -DR- From S.W.Harris at ecs.soton.ac.uk Sun Apr 23 17:37:32 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 23 17:37:52 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145823963.2493.80.camel@DaveLap> References: <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> Message-ID: <20060423213731.GA14155@login.ecs.soton.ac.uk> On Sun, Apr 23, 2006 at 04:26:03 -0400, Dave Robillard wrote: > > > The advantage is the mentioned use case which your suggestion destroys. > > > The array can be static anyway, there's not really any "code" added. > > > > I don't see how it affects the usecase. You /always/ need to read at least > > some of the data somehwere to use the plugin. > > Well, the plugin should be at least runnable without the metadata. Sure > you'll know almost nothing about it, but you should be able to run it > (eg in fixed code where you know the parameters and whatnot you're using > are fine). (No user interacting app could feasibly do so though) Sure, but that doesn't require you to be able to load the shortnames from the plugin binary. > The "somewhere" part is my point. This 'device' can not read metadata > files, yet it needs to know the port IDs. Therefore the port IDs need > to be in the code. It can't speak OSC either, so the integers are just fine. > > It has to be in the struct, otherwise you don't know what functions to > > call to get a particular plugin. > > In other words it's there because it's a unique identifier for the > plugin, used to reference it. I say port IDs need to be there for the > same reason. Ports should be first class citizens with a proper > identifier and all, IMO. They are, they have integers. The integers map to something very real in the plugin structure. Shortnames are just shortnames, you can't map them to ports unless they appear in the external data or you load and link the plugin. > Anyway, putting IDs in the metadata implies that, well, they're > metadata, and can be fiddled with without breaking things. This is not > true. They are unique identifiers (along with their plugin's URIs they > define a URI) and as such are set in stone and must not change. They're > just not metadata. Please dont use the word metadata, it's confusing, what's meta depends on your context. Not all the data can be fiddled with without breaking things. If you change the URI all your presets will stop working, if you change the port indexes then the structure of the plugin changes, etc. - Steve From drobilla at connect.carleton.ca Sun Apr 23 18:40:32 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 23 18:41:42 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145823963.2493.80.camel@DaveLap> References: <20060422172511.GH12135@login.ecs.soton.ac.uk> <1145728060.2358.36.camel@DaveLap> <20060422182050.GL12135@login.ecs.soton.ac.uk> <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> Message-ID: <1145832033.2493.89.camel@DaveLap> On Sun, 2006-04-23 at 16:26 -0400, Dave Robillard wrote: > On Sun, 2006-04-23 at 19:39 +0100, Steve Harris wrote: > > On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave Robillard wrote: > > > On Sun, 2006-04-23 at 19:23 +0100, Steve Harris wrote: > > > > On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote: > > > > > But anyway, why can't it go in the code? I want to keep the C part > > > > > minimal as well, but this is a unique identifier, the sole thing that > > > > > actually does belong in the code. I need this to create an app/device > > > > > like the above. What's the better reason it's a bad idea? Plugins have > > > > > a unique string ID, and I need ports to as well. > > > > > > > > Theres no advantage to it being in the code, it means allocating an array > > > > of strings, which means repeating the same code in every plugin. Also, you > > > > can't get the strings unless you load and link the plugin, which is one of > > > > the things were trying to get away from. > > > > > > The advantage is the mentioned use case which your suggestion destroys. > > > The array can be static anyway, there's not really any "code" added. > > > > I don't see how it affects the usecase. You /always/ need to read at least > > some of the data somehwere to use the plugin. > > Well, the plugin should be at least runnable without the metadata. Sure > you'll know almost nothing about it, but you should be able to run it > (eg in fixed code where you know the parameters and whatnot you're using > are fine). (No user interacting app could feasibly do so though) > > The "somewhere" part is my point. This 'device' can not read metadata > files, yet it needs to know the port IDs. Therefore the port IDs need > to be in the code. > > > > Are you proposing to put the port index numbers in the metadata as well? > > > Otherwise you couldn't get at them without loading and linking the > > > plugin. > > > > Of course, it's ladspa:index if the numbers aren't there then theres > > nothing to link the port data to the float *. > > > > > So the plugin URI should exclusively go in the metadata file as well? > > > Why is that in the code? > > > > It has to be in the struct, otherwise you don't know what functions to > > call to get a particular plugin. > > In other words it's there because it's a unique identifier for the > plugin, used to reference it. I say port IDs need to be there for the > same reason. Ports should be first class citizens with a proper > identifier and all, IMO. > > Anyway, putting IDs in the metadata implies that, well, they're > metadata, and can be fiddled with without breaking things. This is not > true. They are unique identifiers (along with their plugin's URIs they > define a URI) and as such are set in stone and must not change. They're > just not metadata. > > But I want to emphasize the 'device' (or trivial host app, etc) over > arguments about word definitions etc. I really don't want to have to > fork LADSPA into an ABI incompatible derivative over something silly > like this. For the sake of the record, it's been duked out on IRC and Steve wins :). (Specifically, ports will be required to have a unique string ID, but it will live in the data file, not the code). The RDF file is required to run the plugin anyway, since port type and direction etc. is contained there, making my argument about keeping the data file parsing off the 'server side' invalid. The data file is not a "metadata" file, it's required to execute the plugin at all (and I fully agree with this now, even if it does throw a bit of a monkey wrench in some embedded development plans of mine; it's for the greater good....) -DR- From S.W.Harris at ecs.soton.ac.uk Mon Apr 24 03:57:57 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Apr 24 03:59:34 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145832033.2493.89.camel@DaveLap> References: <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> Message-ID: <20060424075757.GB22289@login.ecs.soton.ac.uk> On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard wrote: > For the sake of the record, it's been duked out on IRC and Steve > wins :). (Specifically, ports will be required to have a unique string > ID, but it will live in the data file, not the code). Actually I didn't mean to say that they /will/ be required, just that I don't have a problem with it. I've not heard anyone else speak in favour of this, and it is a feature. If theres a critical mass of support I'm OK with adding it, as it should make the lives of some hosts much easier. At the risk of upsetting Dave, it can be added a a 3rd party extension without anything really bad happening. It just means that the Pd messages / OSC paths / whatever for some plugins will be ugly. "Market pressure" will ensire that all plugins support it if its useful to enough users. - Steve From damon at karuna.uklinux.net Mon Apr 24 06:11:39 2006 From: damon at karuna.uklinux.net (Damon Chaplin) Date: Mon Apr 24 07:12:17 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <20060422203239.GR12135@login.ecs.soton.ac.uk> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> <20060422203239.GR12135@login.ecs.soton.ac.uk> Message-ID: <1145873500.2488.21.camel@localhost.localdomain> On Sat, 2006-04-22 at 21:32 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote: > > nonono :) I think metadata outside the plugin is without a doubt the > > right way to go. I meant I'm just not a huge fan of the particular > > syntax of this Turtle stuff (as opposed to normal well-formed XML). > > Mostly because it means we need special tools and who knows what > > libraries to deal with it. > > you cant usefully read RDF/XML with just an XML parser anyway. It's quite > a lot of work to transform from the XML tree to the RDF graph. > > But yes, Turtle support is less widespeard than RDF/XML, but there are > still Free/Open parsers for every language I can think of (C(++), perl, > java, python, ruby, javascript, etc.) Speaking as a general developer, I'd much rather you just used plain XML. (Pretty much as you have now, in fact.) Everyone knows XML, and we all have XML parsers installed for pretty much every language. Turtle isn't a standard, is aimed at much more general problem areas, and will just force people to read more docs and install more packages. It might be a bit nicer for the person writing the plugin file, but that isn't that much work. (Or does turtle include some essential feature?) Damon PS. It sounds a bit strange to break backwards compatibility without adding new features at the same time. When you do add new features will you have to break backwards compatibility again? From S.W.Harris at ecs.soton.ac.uk Mon Apr 24 07:22:36 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Apr 24 07:22:59 2006 Subject: [linux-audio-dev] LADSPA 2 decision points In-Reply-To: <1145873500.2488.21.camel@localhost.localdomain> References: <20060422181240.GK12135@login.ecs.soton.ac.uk> <1145730130.2358.42.camel@DaveLap> <20060422185606.GA23263@hockin.org> <1145732718.2358.64.camel@DaveLap> <20060422203239.GR12135@login.ecs.soton.ac.uk> <1145873500.2488.21.camel@localhost.localdomain> Message-ID: <20060424112236.GC29411@login.ecs.soton.ac.uk> On Mon, Apr 24, 2006 at 11:11:39 +0100, Damon Chaplin wrote: > On Sat, 2006-04-22 at 21:32 +0100, Steve Harris wrote: > > On Sat, Apr 22, 2006 at 03:05:18PM -0400, Dave Robillard wrote: > > > nonono :) I think metadata outside the plugin is without a doubt the > > > right way to go. I meant I'm just not a huge fan of the particular > > > syntax of this Turtle stuff (as opposed to normal well-formed XML). > > > Mostly because it means we need special tools and who knows what > > > libraries to deal with it. > > > > you cant usefully read RDF/XML with just an XML parser anyway. It's quite > > a lot of work to transform from the XML tree to the RDF graph. > > > > But yes, Turtle support is less widespeard than RDF/XML, but there are > > still Free/Open parsers for every language I can think of (C(++), perl, > > java, python, ruby, javascript, etc.) > > Speaking as a general developer, I'd much rather you just used plain > XML. (Pretty much as you have now, in fact.) The current system is RDF/XML, not vanlla XML, you cant parse it usefully with stock XML parsers. XML is not very easy to extend without breaking other peoples tools. > Turtle isn't a standard, is aimed at much more general problem areas, > and will just force people to read more docs and install more packages. > It might be a bit nicer for the person writing the plugin file, but that > isn't that much work. (Or does turtle include some essential feature?) Turtle only missed being a standard months ago becasue of a wierd patent problem with a well-known company that shall be nameless. It will be a standard very soon. Future changes should not have to break back-compatibility. We only need to do it now to remove some old stuff that doesn't work very well. - Steve From drobilla at connect.carleton.ca Mon Apr 24 08:58:07 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Apr 24 08:59:20 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060424075757.GB22289@login.ecs.soton.ac.uk> References: <1145731653.2358.60.camel@DaveLap> <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> Message-ID: <1145883487.2493.126.camel@DaveLap> On Mon, 2006-04-24 at 08:57 +0100, Steve Harris wrote: > On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard wrote: > > For the sake of the record, it's been duked out on IRC and Steve > > wins :). (Specifically, ports will be required to have a unique string > > ID, but it will live in the data file, not the code). > > Actually I didn't mean to say that they /will/ be required, just that I > don't have a problem with it. I've not heard anyone else speak in favour > of this, and it is a feature. If theres a critical mass of support I'm OK > with adding it, as it should make the lives of some hosts much easier. > > At the risk of upsetting Dave, it can be added a a 3rd party extension > without anything really bad happening. It just means that the Pd messages > / OSC paths / whatever for some plugins will be ugly. "Market pressure" > will ensire that all plugins support it if its useful to enough users. Not so much a new feature as a clearer definition of existing things (port labels). It's a "feature" perhaps, but just something that needs to be defined in the data file. The features we need to avoid here are ones that mess with the code IMO. There are a few new bits of data that experience has shown we need to add to the data file (not mandatory like this one, just possible keys). Given how easy and un-breakey it is to do so (which is the entire point of doing this after all), we should take advantage. Anyway, at this point that's not very important, just definition of possible keys in the data file. We can discuss those once we're sure the code side of things (and existing data bits) is sound. -DR- From S.W.Harris at ecs.soton.ac.uk Mon Apr 24 10:53:54 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Apr 24 10:54:17 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1145883487.2493.126.camel@DaveLap> References: <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> Message-ID: <20060424145354.GA14607@login.ecs.soton.ac.uk> On Mon, Apr 24, 2006 at 08:58:07 -0400, Dave Robillard wrote: > > At the risk of upsetting Dave, it can be added a a 3rd party extension > > without anything really bad happening. It just means that the Pd messages > > / OSC paths / whatever for some plugins will be ugly. "Market pressure" > > will ensire that all plugins support it if its useful to enough users. > > Anyway, at this point that's not very important, just definition of > possible keys in the data file. We can discuss those once we're sure > the code side of things (and existing data bits) is sound. Yep. Seems reasonable. - Steve From christie.tom at gmail.com Mon Apr 24 12:21:58 2006 From: christie.tom at gmail.com (tom christie) Date: Mon Apr 24 12:22:04 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060424145354.GA14607@login.ecs.soton.ac.uk> References: <1145738908.2358.92.camel@DaveLap> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> Message-ID: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> I've been following the LAD mailing list for a while now, mostly to keep an eye the development of LADSPA. Now seems an appropriate time to voice my thoughts. Separating out the metadata is certainly (IMHO) the right thing to do, (I think Steve's proposal is a great step forward) It mitigates the problem of making LADSPA easily extensible by moving as much information as possible out of the fixed binary format. However the problem remains that the core API still cannot be extended without breaking backwards compatibility. Surely with LADSPA 2.0 it's time to change the struct based API to a library call based API. # ie. the currently proposed API looks like... ladspa_descriptor(index) descriptor { uri port_count implementation_data instantiate(descriptor, ...) connect_port(instance, ...) activate(instance) run(instance, ...) deactivate(instance) cleanup(instance) } # a function call based API would look like... ladspa2_descriptor(index) uri(descriptor) port_count(descriptor) instantiate(descriptor, ...) connect_port(instance, ...) activate(instance) run(instance, ...) deactivate(instance) cleanup(instance) In the former, any change in the descriptor structure will always break backwards compatibility. In the later, new functions can extend the core functionality without breaking backwards compatibility in any way. I'd be very interested in hearing people's opinions on this. Regards, Tom From taybin at earthlink.net Mon Apr 24 12:44:03 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Mon Apr 24 12:44:16 2006 Subject: [linux-audio-dev] ladspa2 and bundles Message-ID: <7706677.1145897043956.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> I like the bundle idea. What are the reasons to not use it? Reasons to use it include ease of distribution (especially on other platforms like osx). I think bundles are a great idea that should be adopted by other unixen. Or, can we make it so that bundles are a possible method of distribution and either it or the typical installation into various directories could be used? Taybin From jesse at essej.net Mon Apr 24 16:12:11 2006 From: jesse at essej.net (Jesse Chappell) Date: Mon Apr 24 16:12:24 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> References: <1145738908.2358.92.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> Message-ID: On 4/24/06, tom christie wrote: > In the former, any change in the descriptor structure will always break > backwards compatibility. > In the later, new functions can extend the core functionality without > breaking backwards compatibility in any way. Actually, just adding a large-ish chunk of reserved padding at the end of the descriptor struct can accomplish the same goal, as long as you are only adding new functions to the API. That, along with a version field also in the struct. jlc From hans at fugal.net Mon Apr 24 19:53:42 2006 From: hans at fugal.net (Hans Fugal) Date: Mon Apr 24 19:54:19 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060424075757.GB22289@login.ecs.soton.ac.uk> References: <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> Message-ID: <20060424235341.GB21178@falcon.fugal.net> On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris wrote: > On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard wrote: > > For the sake of the record, it's been duked out on IRC and Steve > > wins :). (Specifically, ports will be required to have a unique string > > ID, but it will live in the data file, not the code). > > Actually I didn't mean to say that they /will/ be required, just that I > don't have a problem with it. I've not heard anyone else speak in favour > of this, and it is a feature. If theres a critical mass of support I'm OK > with adding it, as it should make the lives of some hosts much easier. Well then let me weigh in. I have in the past cursed the insensibility of referencing a port with its arbitrary (from the human's POV) numerical ID. I want human-friendly port IDs. > At the risk of upsetting Dave, it can be added a a 3rd party extension > without anything really bad happening. It just means that the Pd messages > / OSC paths / whatever for some plugins will be ugly. "Market pressure" > will ensire that all plugins support it if its useful to enough users. Ick. I'm all for market pressure, but this is not the place for it, IMHO. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060424/14dee483/attachment-0001.bin From loki.davison at gmail.com Mon Apr 24 20:26:09 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Apr 24 20:26:15 2006 Subject: [linux-audio-dev] Re: LADSPA 2 In-Reply-To: <20060424235341.GB21178@falcon.fugal.net> References: <20060422201008.GM12135@login.ecs.soton.ac.uk> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <20060424235341.GB21178@falcon.fugal.net> Message-ID: On 4/25/06, Hans Fugal wrote: > On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris wrote: > > On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard wrote: > > > For the sake of the record, it's been duked out on IRC and Steve > > > wins :). (Specifically, ports will be required to have a unique string > > > ID, but it will live in the data file, not the code). > > > > Actually I didn't mean to say that they /will/ be required, just that I > > don't have a problem with it. I've not heard anyone else speak in favour > > of this, and it is a feature. If theres a critical mass of support I'm OK > > with adding it, as it should make the lives of some hosts much easier. > > Well then let me weigh in. I have in the past cursed the insensibility > of referencing a port with its arbitrary (from the human's POV) > numerical ID. I want human-friendly port IDs. Me too. From taybin at earthlink.net Tue Apr 25 00:38:16 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Tue Apr 25 00:38:36 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060424235341.GB21178@falcon.fugal.net> References: <20060422201008.GM12135@login.ecs.soton.ac.uk> <1145738908.2358.92.camel@DaveLap> <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <20060424235341.GB21178@falcon.fugal.net> Message-ID: <07C346F0-6404-4B13-8EB5-70E402C3AC7E@earthlink.net> On Apr 24, 2006, at 7:53 PM, Hans Fugal wrote: > On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris wrote: >> At the risk of upsetting Dave, it can be added a a 3rd party >> extension >> without anything really bad happening. It just means that the Pd >> messages >> / OSC paths / whatever for some plugins will be ugly. "Market >> pressure" >> will ensire that all plugins support it if its useful to enough >> users. > > Ick. I'm all for market pressure, but this is not the place for it, > IMHO. Why not? I think it's a great way of organically growing the spec by testing popularity and usage in the real world first. Taybin From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 04:46:46 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 04:47:09 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: References: <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> Message-ID: <20060425084646.GG24930@login.ecs.soton.ac.uk> On Mon, Apr 24, 2006 at 04:12:11 -0400, Jesse Chappell wrote: > On 4/24/06, tom christie wrote: > > > In the former, any change in the descriptor structure will always break > > backwards compatibility. > > In the later, new functions can extend the core functionality without > > breaking backwards compatibility in any way. > > Actually, just adding a large-ish chunk of reserved padding at the end > of the descriptor struct can accomplish the same goal, as long as you > are only adding new functions to the API. That, along with a version > field also in the struct. The pluin is responsibe for allocating the descriptor, so its not neccesary to add padding. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 05:00:07 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 05:00:51 2006 Subject: [linux-audio-dev] Re: LADSPA 2 In-Reply-To: References: <20060423065318.GB398@login.ecs.soton.ac.uk> <1145805959.2493.22.camel@DaveLap> <20060423182315.GC5628@login.ecs.soton.ac.uk> <1145821505.2493.59.camel@DaveLap> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <20060424235341.GB21178@falcon.fugal.net> Message-ID: <20060425090007.GH24930@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 10:26:09AM +1000, Loki Davison wrote: > On 4/25/06, Hans Fugal wrote: > > On Mon, 24 Apr 2006 at 08:57 +0100, Steve Harris wrote: > > > On Sun, Apr 23, 2006 at 06:40:32 -0400, Dave Robillard wrote: > > > > For the sake of the record, it's been duked out on IRC and Steve > > > > wins :). (Specifically, ports will be required to have a unique string > > > > ID, but it will live in the data file, not the code). > > > > > > Actually I didn't mean to say that they /will/ be required, just that I > > > don't have a problem with it. I've not heard anyone else speak in favour > > > of this, and it is a feature. If theres a critical mass of support I'm OK > > > with adding it, as it should make the lives of some hosts much easier. > > > > Well then let me weigh in. I have in the past cursed the insensibility > > of referencing a port with its arbitrary (from the human's POV) > > numerical ID. I want human-friendly port IDs. > > Me too. OK, given that no-one has spoken out against it, I'm happy to include a required shortname for ports, that must be [_a-zA-Z][_a-zA-Z0-9]* or similar. It's a burdon on all plugin authors, but host authors can ignore it. I've tentatively added ladspa:shortname to the stawman plugin's ports. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 05:07:14 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 05:07:33 2006 Subject: [linux-audio-dev] ladspa2 and bundles In-Reply-To: <7706677.1145897043956.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> References: <7706677.1145897043956.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Message-ID: <20060425090714.GI24930@login.ecs.soton.ac.uk> On Mon, Apr 24, 2006 at 12:44:03PM -0400, Taybin Rutkin wrote: > I like the bundle idea. What are the reasons to not use it? Reasons to use it include ease of distribution (especially on other platforms like osx). > > I think bundles are a great idea that should be adopted by other unixen. > > Or, can we make it so that bundles are a possible method of distribution and either it or the typical installation into various directories could be used? I'd like to see LADSPA 2.0 plugins always being directories, wether we go for bundles or not. It gives the plugin somewhere to stash its auxilarry data (precompiled tables etc.), which otherwise is a bit of a pain. It's possible to retrofit bundles to 2.x by reserving the lib/ directory inside the plugin directory for future use in 2.0. zeroinstall, http://0install.net/ uses something similar to bundles at it works well on linux. - Steve From christie.tom at gmail.com Tue Apr 25 06:28:47 2006 From: christie.tom at gmail.com (tom christie) Date: Tue Apr 25 06:28:56 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060425084646.GG24930@login.ecs.soton.ac.uk> References: <20060423182315.GC5628@login.ecs.soton.ac.uk> <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> Message-ID: <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> Okay, I ought to have qualified my 'will always break...' that's clearly not true. But there is still real inflexibility in using a struct based API. eg. Say a developer comes up with a nice extension (perhaps to allow a plugin to deal with multi-channel IO / non-causal audio effects / alter the audio frequency / support an 'end of stream' marker / midi / GUI / accessing metadata via function calls / or whatever...) With the struct based API the only way(*) for that extension to make it into LADSPA is for it to be part of the the struct in the next version of LADSPA. We want to keep LADSPA simple, so that's unlikely to happen. With the library call based API the developer defines and advertises the functions that make up the extension, and if it is useful hosts will start to implement it. If it proves it's worth it can be adopted as an official LADSPA *extension*, which hosts can choose (or not) to implement. The core API remains simple and unbloated, but LADSPA can still develop. (*) Yes there is trickery that could be played with, eg. using multiple discovery functions, but that's just icky. From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 06:28:42 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 06:29:08 2006 Subject: [linux-audio-dev] Update to LADSPA 2 strawman Message-ID: <20060425102842.GJ24930@login.ecs.soton.ac.uk> I've added the port shortnames (ladspa:shortname). This is still tentative in my mind, but as long as it doesn't cause any serious objections it will stay. Following a suggestion from Richard Furze I've removed the LADSPA_Data type and replaced it with void. The ports are datatyped in the data, but currently only ladspa:float is supported. I have misgivings about this, but it seems like a good way to open up to more datatypes in the future. I'd hate to see a future where there are plugins for translating between different kinds of boring PCM data, that would suck, but this could allow for some exciting developments. The first person to make a LADSPA plugin that speaks 16bit int PCM audio data gets the LART treatment ;) Thoughts? - Steve From larsl at users.sourceforge.net Tue Apr 25 06:46:01 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Tue Apr 25 06:48:20 2006 Subject: [linux-audio-dev] Update to LADSPA 2 strawman In-Reply-To: <20060425102842.GJ24930@login.ecs.soton.ac.uk> References: <20060425102842.GJ24930@login.ecs.soton.ac.uk> Message-ID: <1145961961.8826.5.camel@localhost> On Tue, 2006-04-25 at 11:28 +0100, Steve Harris wrote: > I've added the port shortnames (ladspa:shortname). This is still tentative > in my mind, but as long as it doesn't cause any serious objections it will > stay. > > Following a suggestion from Richard Furze I've removed the LADSPA_Data > type and replaced it with void. The ports are datatyped in the data, but > currently only ladspa:float is supported. I have misgivings about this, > but it seems like a good way to open up to more datatypes in the future. That is interesting - it could be used to store frames of frequency domain data, like the spectral variables in Csound, or timestamped events of different types, like JACK MIDI. In the future. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060425/44903c92/attachment-0001.bin From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 07:59:26 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 08:00:18 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> References: <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> Message-ID: <20060425115926.GL24930@login.ecs.soton.ac.uk> Sorry, I just dont feel that motivated by this. We have a bunch of code and experience around the struct format, and we know were going to need something equivalent for the forseeable future, so I dont see the point in changing it over just for the sake of it. Sure, for some possible future ABI-incomaptible extension we might want to add functions, but equally we might not. - Steve On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote: > Okay, I ought to have qualified my 'will always break...' that's > clearly not true. > But there is still real inflexibility in using a struct based API. > > eg. Say a developer comes up with a nice extension (perhaps to allow a > plugin to deal with multi-channel IO / non-causal audio effects / > alter the audio frequency / support an 'end of stream' marker / midi / > GUI / accessing metadata via function calls / or whatever...) > > With the struct based API the only way(*) for that extension to make > it into LADSPA is for it to be part of the the struct in the next > version of LADSPA. We want to keep LADSPA simple, so that's unlikely > to happen. > > With the library call based API the developer defines and advertises > the functions that make up the extension, and if it is useful hosts > will start to implement it. If it proves it's worth it can be adopted > as an official LADSPA *extension*, which hosts can choose (or not) to > implement. > > The core API remains simple and unbloated, but LADSPA can still develop. > > (*) Yes there is trickery that could be played with, eg. using > multiple discovery functions, but that's just icky. From hans at fugal.net Tue Apr 25 09:26:20 2006 From: hans at fugal.net (Hans Fugal) Date: Tue Apr 25 09:27:03 2006 Subject: [linux-audio-dev] ladspa2 and bundles In-Reply-To: <20060425090714.GI24930@login.ecs.soton.ac.uk> References: <7706677.1145897043956.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <20060425090714.GI24930@login.ecs.soton.ac.uk> Message-ID: <20060425132620.GA21880@falcon.fugal.net> On Tue, 25 Apr 2006 at 10:07 +0100, Steve Harris wrote: > On Mon, Apr 24, 2006 at 12:44:03PM -0400, Taybin Rutkin wrote: > > I like the bundle idea. What are the reasons to not use it? Reasons to use it include ease of distribution (especially on other platforms like osx). > > > > I think bundles are a great idea that should be adopted by other unixen. > > > > Or, can we make it so that bundles are a possible method of distribution and either it or the typical installation into various directories could be used? > > I'd like to see LADSPA 2.0 plugins always being directories, wether we go > for bundles or not. It gives the plugin somewhere to stash its auxilarry > data (precompiled tables etc.), which otherwise is a bit of a pain. Well, yes and no. Yes if you install it somewhere you have permissions to write to. No if it's installed somewhere by root. > It's possible to retrofit bundles to 2.x by reserving the lib/ directory > inside the plugin directory for future use in 2.0. > > zeroinstall, http://0install.net/ uses something similar to bundles at it > works well on linux. > I like the bundle idea as well. I've found it works pretty well in OS X, it gives a sense of one package to the user, who just drags it around in a file manager, and the power for the developer or power user to poke around in the directory. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060425/32907bbf/attachment.bin From hans at fugal.net Tue Apr 25 09:29:31 2006 From: hans at fugal.net (Hans Fugal) Date: Tue Apr 25 09:29:41 2006 Subject: [linux-audio-dev] Update to LADSPA 2 strawman In-Reply-To: <20060425102842.GJ24930@login.ecs.soton.ac.uk> References: <20060425102842.GJ24930@login.ecs.soton.ac.uk> Message-ID: <20060425132931.GB21880@falcon.fugal.net> On Tue, 25 Apr 2006 at 11:28 +0100, Steve Harris wrote: > I've added the port shortnames (ladspa:shortname). This is still tentative > in my mind, but as long as it doesn't cause any serious objections it will > stay. > > Following a suggestion from Richard Furze I've removed the LADSPA_Data > type and replaced it with void. The ports are datatyped in the data, but > currently only ladspa:float is supported. I have misgivings about this, > but it seems like a good way to open up to more datatypes in the future. > > I'd hate to see a future where there are plugins for translating between > different kinds of boring PCM data, that would suck, but this could allow Hmm, well couldn't we have one libsndfile plugin that can convert between whatever common boring PCM formats you like? I haven't looked closely at the ladspa2 stuff yet - is it possible to change these port types at runtime, if so the libsndfile plugin would only need an input and an output... -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060425/f95f692f/attachment.bin From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 10:09:37 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 10:10:02 2006 Subject: [linux-audio-dev] ladspa2 and bundles In-Reply-To: <20060425132620.GA21880@falcon.fugal.net> References: <7706677.1145897043956.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <20060425090714.GI24930@login.ecs.soton.ac.uk> <20060425132620.GA21880@falcon.fugal.net> Message-ID: <20060425140937.GN24930@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 07:26:20AM -0600, Hans Fugal wrote: > On Tue, 25 Apr 2006 at 10:07 +0100, Steve Harris wrote: > > I'd like to see LADSPA 2.0 plugins always being directories, wether we go > > for bundles or not. It gives the plugin somewhere to stash its auxilarry > > data (precompiled tables etc.), which otherwise is a bit of a pain. > > Well, yes and no. Yes if you install it somewhere you have permissions > to write to. No if it's installed somewhere by root. Ah, I meant things that are created at compilation or install time. Dynamic things have to be kept somewhere else, but plugins shouldn't be doing runtime i/o anyway. > > It's possible to retrofit bundles to 2.x by reserving the lib/ directory > > inside the plugin directory for future use in 2.0. > > > > zeroinstall, http://0install.net/ uses something similar to bundles at it > > works well on linux. > > > > I like the bundle idea as well. I've found it works pretty well in OS X, > it gives a sense of one package to the user, who just drags it around in > a file manager, and the power for the developer or power user to poke > around in the directory. Yes, exactly. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 10:11:34 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 10:11:53 2006 Subject: [linux-audio-dev] Update to LADSPA 2 strawman In-Reply-To: <20060425132931.GB21880@falcon.fugal.net> References: <20060425102842.GJ24930@login.ecs.soton.ac.uk> <20060425132931.GB21880@falcon.fugal.net> Message-ID: <20060425141134.GO24930@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 07:29:31AM -0600, Hans Fugal wrote: > On Tue, 25 Apr 2006 at 11:28 +0100, Steve Harris wrote: > > I'd hate to see a future where there are plugins for translating between > > different kinds of boring PCM data, that would suck, but this could allow > > Hmm, well couldn't we have one libsndfile plugin that can convert > between whatever common boring PCM formats you like? I haven't looked > closely at the ladspa2 stuff yet - is it possible to change these port > types at runtime, if so the libsndfile plugin would only need an input > and an output... Their constant. But that's what I was trying to avoid, the current sitatuion is that all LADSPA plugins speak only IEEE floats, and that's really nice. You can end up burning a lot of memory bandwidth and cpu just doing pointless PCM conversions. - Steve From christie.tom at gmail.com Tue Apr 25 12:40:59 2006 From: christie.tom at gmail.com (tom christie) Date: Tue Apr 25 12:41:11 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060425115926.GL24930@login.ecs.soton.ac.uk> References: <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> Message-ID: <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> > Sorry, I just dont feel that motivated by this. No problem :) just wanted to know if anyone else thought it was an important point. Two other concerns... A) There is no built-in way of a host distinguishing between a LADSPA 1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?) Would it make sense to change the name of the discovery function? eg... ladspa2_descriptor() instead of ladspa_descriptor() That way there's no chance of a 2.0 host thinking it has a 2.0 plugin when in fact it has a 1.1 plugin. (Or vice versa with a 1.1 host) Either case would cause the host to crash when it calls the instantiate() function. B) There is no way of a host distinguishing between a LADSPA 2.x and a LADSPA 2.y plugin. Would it make sense for the initial few bytes of the struct to explicitly declare that this really is a LADSPA struct and give the major and minor versions for which it was written? This would allow the struct to change in the future if neccessary without breaking things and without needing to change the name of the discovery function again. char ladspa_string[7]; // plugin must set this to "LADSPA\0" unsigned short major_version; // plugin must set this to 2 unsigned short minor_version; // plugin must set this to 0 The host should check for the null terminated "LADSPA" string, and should ensure that it's version is less than or equal that which the host supports before attempting to access the plugin. thoughts?... On 4/25/06, Steve Harris wrote: > Sorry, I just dont feel that motivated by this. We have a bunch of code > and experience around the struct format, and we know were going to need > something equivalent for the forseeable future, so I dont see the point in > changing it over just for the sake of it. > > Sure, for some possible future ABI-incomaptible extension we might want to > add functions, but equally we might not. > > - Steve > > On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote: > > Okay, I ought to have qualified my 'will always break...' that's > > clearly not true. > > But there is still real inflexibility in using a struct based API. > > > > eg. Say a developer comes up with a nice extension (perhaps to allow a > > plugin to deal with multi-channel IO / non-causal audio effects / > > alter the audio frequency / support an 'end of stream' marker / midi / > > GUI / accessing metadata via function calls / or whatever...) > > > > With the struct based API the only way(*) for that extension to make > > it into LADSPA is for it to be part of the the struct in the next > > version of LADSPA. We want to keep LADSPA simple, so that's unlikely > > to happen. > > > > With the library call based API the developer defines and advertises > > the functions that make up the extension, and if it is useful hosts > > will start to implement it. If it proves it's worth it can be adopted > > as an official LADSPA *extension*, which hosts can choose (or not) to > > implement. > > > > The core API remains simple and unbloated, but LADSPA can still develop. > > > > (*) Yes there is trickery that could be played with, eg. using > > multiple discovery functions, but that's just icky. > From larsl at users.sourceforge.net Tue Apr 25 12:58:18 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Tue Apr 25 12:58:23 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> References: <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> Message-ID: <1145984298.8826.32.camel@localhost> On Tue, 2006-04-25 at 17:40 +0100, tom christie wrote: > A) There is no built-in way of a host distinguishing between a LADSPA > 1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?) > > Would it make sense to change the name of the discovery function? > eg... ladspa2_descriptor() instead of ladspa_descriptor() That makes sense to me. You could of course say that all LADSPA2 plugins/bundles/directories should be stored in different directories from LADSPA1 (e.g. /usr/lib/ladspa2 instead of /usr/lib/ladspa) but since the user is free to set $LADSPA_PATH to whatever he wants and hosts are free to search whatever directories they want that wouldn't be a very stable solution. Having a separate discovery function is a good idea. > B) There is no way of a host distinguishing between a LADSPA 2.x and a > LADSPA 2.y plugin. > > Would it make sense for the initial few bytes of the struct to > explicitly declare that this really is a LADSPA struct and give the > major and minor versions for which it was written? This would allow > the struct to change in the future if neccessary without breaking > things and without needing to change the name of the discovery > function again. > > char ladspa_string[7]; // plugin must set this to "LADSPA\0" > unsigned short major_version; // plugin must set this to 2 > unsigned short minor_version; // plugin must set this to 0 I don't think that the string is needed - if the host got the descriptor from a ladspa2_descriptor() discovery function, that should be enough to be sure that it is a LADSPA2 descriptor. A version number might be good though - even if the goal is to add extensions without breaking the ABI it could still be necessary to break it at some point in the future. One version number should be enough though, and it doesn't have to match the actual version of the LADSPA spec. Like the DSSI_API_Version in the DSSI descriptor. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060425/bad9bd97/attachment.bin From drobilla at connect.carleton.ca Tue Apr 25 13:36:42 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Apr 25 13:36:17 2006 Subject: [linux-audio-dev] Update to LADSPA 2 strawman In-Reply-To: <20060425102842.GJ24930@login.ecs.soton.ac.uk> References: <20060425102842.GJ24930@login.ecs.soton.ac.uk> Message-ID: <1145986602.2369.0.camel@DaveLap> On Tue, 2006-04-25 at 11:28 +0100, Steve Harris wrote: > I've added the port shortnames (ladspa:shortname). This is still tentative > in my mind, but as long as it doesn't cause any serious objections it will > stay. > > Following a suggestion from Richard Furze I've removed the LADSPA_Data > type and replaced it with void. The ports are datatyped in the data, but > currently only ladspa:float is supported. I have misgivings about this, > but it seems like a good way to open up to more datatypes in the future. > > I'd hate to see a future where there are plugins for translating between > different kinds of boring PCM data, that would suck, but this could allow > for some exciting developments. The first person to make a LADSPA plugin > that speaks 16bit int PCM audio data gets the LART treatment ;) > > Thoughts? Votes += infinity -DR- From paniq at paniq.org Tue Apr 25 17:33:54 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Apr 25 17:26:09 2006 Subject: [linux-audio-dev] all-purpose xplatform audio decoding library? Message-ID: <1146000834.14289.9.camel@localhost> maybe someone here can help? i need a decoder library that works on win32/linux, can decode wav/ogg/mp3, can seek with sample precision and supports rendering of userdefined frame sizes I'd say libsndfile, but it doesn't do MP3. which isnt that bad tho. i hate mp3. http://www.mega-nerd.com/libsndfile/ no ogg support only support for wav files i'm not fond of adding separate libs with different apis to access different audio codecs -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From paniq at paniq.org Tue Apr 25 17:41:41 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Apr 25 17:34:31 2006 Subject: [linux-audio-dev] Update to LADSPA 2 strawman In-Reply-To: <20060425141134.GO24930@login.ecs.soton.ac.uk> References: <20060425102842.GJ24930@login.ecs.soton.ac.uk> <20060425132931.GB21880@falcon.fugal.net> <20060425141134.GO24930@login.ecs.soton.ac.uk> Message-ID: <1146001301.14289.12.camel@localhost> LADSPA is not a sexy name. please consider using something more erotic this time.. acronyms are so 80s :) i'm going to read the header file now. On Tue, 2006-04-25 at 15:11 +0100, Steve Harris wrote: > On Tue, Apr 25, 2006 at 07:29:31AM -0600, Hans Fugal wrote: > > On Tue, 25 Apr 2006 at 11:28 +0100, Steve Harris wrote: > > > I'd hate to see a future where there are plugins for translating between > > > different kinds of boring PCM data, that would suck, but this could allow > > > > Hmm, well couldn't we have one libsndfile plugin that can convert > > between whatever common boring PCM formats you like? I haven't looked > > closely at the ladspa2 stuff yet - is it possible to change these port > > types at runtime, if so the libsndfile plugin would only need an input > > and an output... > > Their constant. > > But that's what I was trying to avoid, the current sitatuion is that all > LADSPA plugins speak only IEEE floats, and that's really nice. > > You can end up burning a lot of memory bandwidth and cpu just doing > pointless PCM conversions. > > - Steve -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 17:37:28 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 17:37:53 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> References: <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> Message-ID: <20060425213728.GQ24930@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 05:40:59PM +0100, tom christie wrote: > > Sorry, I just dont feel that motivated by this. > No problem :) just wanted to know if anyone else thought it was an > important point. > > > Two other concerns... > > > A) There is no built-in way of a host distinguishing between a LADSPA > 1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?) I was imagining they would be in a different path, and as they will be in .ladspa2 directories, and the .so files are discoverable via the RDF manifest, theres no real reason why you would find one and not be sure what version it was, however... > Would it make sense to change the name of the discovery function? > eg... ladspa2_descriptor() instead of ladspa_descriptor() > > That way there's no chance of a 2.0 host thinking it has a 2.0 plugin > when in fact it has a 1.1 plugin. (Or vice versa with a 1.1 host) > Either case would cause the host to crash when it calls the > instantiate() function. Right, I can't see any reason not to do this. > B) There is no way of a host distinguishing between a LADSPA 2.x and a > LADSPA 2.y plugin. > > Would it make sense for the initial few bytes of the struct to > explicitly declare that this really is a LADSPA struct and give the > major and minor versions for which it was written? This would allow > the struct to change in the future if neccessary without breaking > things and without needing to change the name of the discovery > function again. > > char ladspa_string[7]; // plugin must set this to "LADSPA\0" > unsigned short major_version; // plugin must set this to 2 > unsigned short minor_version; // plugin must set this to 0 I made a version of the .h that does this (the version thing, not the header), but I couldn't think if any cases where it was useful - if it gets as far as the time you fetch the descriptor from the .so before you find out what the version is thats problaby a mistake. You should be able to reject descriptors you cant handle before that stage, otherwise it will annoy users. user: "I want that one", host: "oh, sorry, I dont understand it" One of my aims for LADSPA 2 is to remove the need to dlload the plugin (expensive in CPU+memory, potentially dangerous) until you need to pass data through it. - Steve From mle+la at mega-nerd.com Tue Apr 25 17:44:51 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Tue Apr 25 17:45:03 2006 Subject: [linux-audio-dev] all-purpose xplatform audio decoding library? In-Reply-To: <1146000834.14289.9.camel@localhost> References: <1146000834.14289.9.camel@localhost> Message-ID: <20060426074451.15f680e4.mle+la@mega-nerd.com> Leonard \ wrote: > http://www.mega-nerd.com/libsndfile/ > no ogg support Ogg support has been "in progress" for about 2 years now: http://www.metadecks.org/software/libsndfile/ Feel free to ping Conrad Parker about this. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Being completely naked during the act of coitus annuls the marriage." -- Rashad Hassan Khalil, a former dean of Al-Azhar University's faculty of Sharia (or Islamic law) From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 17:47:55 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 17:48:21 2006 Subject: [linux-audio-dev] LADSPA_Descriptor.ImplementationData usage? Message-ID: <20060425214755.GR24930@login.ecs.soton.ac.uk> I'm in a cruft killing mood. Has anyone ever used ImplementationData? I know I haven't, and I goggled for it, but all I found was the ladspa.h file, which has a comment to the affect of: we're not sure why you'd need this, but, just incase here's a void *. If anoyone has used it, or has a potential use for it, it should stay, but otherwise it should go IMHO. - Steve From paniq at paniq.org Tue Apr 25 17:58:23 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Apr 25 17:50:26 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060425115926.GL24930@login.ecs.soton.ac.uk> References: <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> Message-ID: <1146002303.14289.27.camel@localhost> Ok, some thoughts about the headerfile: - i would find it helpful if the header also contained a definition of a valid LADSPA URI, along with some examples. - passing the HostFeatures in instantiate is a bit too late. i wouldnt want to instantiate a plugin first to find out if they match i.e. when i enumerate plugins to display them in a menu. furthermore i'm not sure if it is an audio plugins duty to check the validity of a host. rather the host should analyze a static string pointed member containing required host features. this way the host programmer can choose the quickest method to do a match check. at least i think so. - why does the plugin require its own bundle path for instantiation? this can usually be deduced from the dl's own runtime image information, no? otherwise, an explanation of this choice in the comment would be nice. - comments still contain references to set_run_adding_gain - LADSPA is an ugly name ;) after reading this i do not see why a new ladspa header is required. there are barely any changes in 2. i think this is going to become more confusing than helpful, especially since it will not be possible to load ladspa 1+2 plugins in the same host with ease (yes, people do not like to fix orphaned code and recompile binaries, imagine!). furthermore, DSSI builds upon ladspa. a ladspa 2 enforces also a DSSI 2. again, looking at the slight changes that ladspa underwent, i dont see what the big fuzz is about. grumpily yours, -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From nettings at folkwang-hochschule.de Tue Apr 25 17:55:31 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Tue Apr 25 17:54:05 2006 Subject: [linux-audio-dev] LAC 2006 Live Streams Message-ID: <444E9AD3.2050802@folkwang-hochschule.de> hi *! the linux audio conference 2006, which takes place at the zkm in karlsruhe/germany from april 27 to april 30, will be streamed live for your convenience, inspiration and enjoyment. all presentations (which are listed on http://lac.zkm.de/2006/program.shtml) are covered as ogg vorbis audio streams in two bitrates (one for modem users and one for slightly-more-broadband users) and ogg theora/vorbis a/v streams (for broadband users only). to watch and/or listen, you can use a recent version of mplayer, vlc or curl | theora123, if you prefer. the stream urls are listed at http://lac.zkm.de/2006/streaming.shtml. we will start test streams tomorrow by 12:00 utc+2. as always, there will be chat channels to go with the streams, where you can report problems, discuss the presentations and also ask questions which will be relayed to the live audience by the local chat operators here at zkm. these channels are #lac2006 for general issues and chitchat, and #lac2006-track1 and #lac2006-track2 for questions and remarks about the current presentation, all on irc.freenode.net. you will be able to download the presentation slides in advance to read along as you listen and watch. the quality of the video streams will not be sufficient to read the projections, but you should easily be able to make out which slide is currently up. on behalf of eric rzewnicki (who did most of the streaming work this year) and the rest of the lac organizational team i wish you lots of fun with the streams. kudos again to the icecast team, especially to karl heyes, all the folks at xiph.org who brought us all those great free multimedia codecs, and the crew here at zkm for their great support and cooperation! best, j?rn From drobilla at connect.carleton.ca Tue Apr 25 17:58:08 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Apr 25 17:58:38 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146002303.14289.27.camel@localhost> References: <20060423183952.GD5628@login.ecs.soton.ac.uk> <1145823963.2493.80.camel@DaveLap> <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> Message-ID: <1146002289.3637.1.camel@DaveLap> On Tue, 2006-04-25 at 23:58 +0200, Leonard "paniq" Ritter wrote: > Ok, some thoughts about the headerfile: [snip] > after reading this i do not see why a new ladspa header is required. > there are barely any changes in 2. i think this is going to become more > confusing than helpful, especially since it will not be possible to load > ladspa 1+2 plugins in the same host with ease (yes, people do not like > to fix orphaned code and recompile binaries, imagine!). You are completely missing the entire point of LADSPA2. All the unecessary data has been removed from the header file (ie the plugin code). Look at the example plugin's code, it will be painfully obvious what the advantage is. -DR- From drobilla at connect.carleton.ca Tue Apr 25 18:01:18 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Apr 25 18:00:55 2006 Subject: [linux-audio-dev] LADSPA_Descriptor.ImplementationData usage? In-Reply-To: <20060425214755.GR24930@login.ecs.soton.ac.uk> References: <20060425214755.GR24930@login.ecs.soton.ac.uk> Message-ID: <1146002479.3637.5.camel@DaveLap> On Tue, 2006-04-25 at 22:47 +0100, Steve Harris wrote: > I'm in a cruft killing mood. > > Has anyone ever used ImplementationData? I know I haven't, and I goggled > for it, but all I found was the ladspa.h file, which has a comment to the > affect of: we're not sure why you'd need this, but, just incase here's a > void *. > > If anoyone has used it, or has a potential use for it, it should stay, but > otherwise it should go IMHO. I was just thinking this while going through the header (cleaned it up a bit). I don't even really understand what it's purpose is to be honest, never have. What does it allow that would not be possible if it weren't there? -DR- From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 18:02:28 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 18:02:51 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146002303.14289.27.camel@localhost> References: <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> Message-ID: <20060425220228.GS24930@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 11:58:23PM +0200, Leonard paniq Ritter wrote: > Ok, some thoughts about the headerfile: > > - i would find it helpful if the header also contained a definition of > a valid LADSPA URI, along with some examples. Yes, we were discussing this on IRC an hour or so ago. Any URI is a valid LADSPA URI, but there are some helpful recommendations. NB, the header file is just a hacked about ladspa.h, it's far from finished. > - passing the HostFeatures in instantiate is a bit too late. i wouldnt > want to instantiate a plugin first to find out if they match i.e. when i > enumerate plugins to display them in a menu. furthermore i'm not sure if > it is an audio plugins duty to check the validity of a host. rather the > host should analyze a static string pointed member containing required > host features. this way the host programmer can choose the quickest > method to do a match check. at least i think so. I think the easiest thing would be for the plugin to list its required features in the data file, then the host can weed them out without even getting that far. The plugin may just choose to modify its behaviour, not refuse, so the featuers list still should be passed to instantiate IMHO. > - why does the plugin require its own bundle path for instantiation? > this can usually be deduced from the dl's own runtime image information, > no? otherwise, an explanation of this choice in the comment would be > nice. Can it? I wasn't aware of that, in that case its redundant. > - comments still contain references to set_run_adding_gain Cheers, I'l fix that. > - LADSPA is an ugly name ;) Yep. > after reading this i do not see why a new ladspa header is required. > there are barely any changes in 2. i think this is going to become more > confusing than helpful, especially since it will not be possible to load > ladspa 1+2 plugins in the same host with ease (yes, people do not like > to fix orphaned code and recompile binaries, imagine!). It should be perfectly possible to load both. Personally I prefer to remove obsolete cruft, but its a matter of taste. I did consder just ignoring the obsolete fields and resusing label as the uri, but its kinda ugly. > furthermore, DSSI builds upon ladspa. a ladspa 2 enforces also a DSSI 2. > again, looking at the slight changes that ladspa underwent, i dont see > what the big fuzz is about. Yes, but that's desirable anyway. With some of the (potential) new capbilities there are less ugly ways to do some of the things DSSI does, DSSI 2 should be much less complex that 1. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 18:04:21 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 18:04:45 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146002289.3637.1.camel@DaveLap> References: <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <1146002289.3637.1.camel@DaveLap> Message-ID: <20060425220421.GT24930@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote: > On Tue, 2006-04-25 at 23:58 +0200, Leonard "paniq" Ritter wrote: > > Ok, some thoughts about the headerfile: > [snip] > > after reading this i do not see why a new ladspa header is required. > > there are barely any changes in 2. i think this is going to become more > > confusing than helpful, especially since it will not be possible to load > > ladspa 1+2 plugins in the same host with ease (yes, people do not like > > to fix orphaned code and recompile binaries, imagine!). > > You are completely missing the entire point of LADSPA2. All the > unecessary data has been removed from the header file (ie the plugin > code). > > Look at the example plugin's code, it will be painfully obvious what the > advantage is. Well, with sufficeint use of calloc and careful spec wording its possible to get the same affect with no change to the struct, but I just dont see the point. The plugin and host code has to change anyway, and its less ugly if its removed. If we ever have an ABI change in the future then the LADSPA 1 pseudo-compatibility will be lost anyway. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Apr 25 18:11:38 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Apr 25 18:12:05 2006 Subject: [linux-audio-dev] LADSPA_Descriptor.ImplementationData usage? In-Reply-To: <1146002479.3637.5.camel@DaveLap> References: <20060425214755.GR24930@login.ecs.soton.ac.uk> <1146002479.3637.5.camel@DaveLap> Message-ID: <20060425221138.GU24930@login.ecs.soton.ac.uk> On Tue, Apr 25, 2006 at 06:01:18PM -0400, Dave Robillard wrote: > On Tue, 2006-04-25 at 22:47 +0100, Steve Harris wrote: > > I'm in a cruft killing mood. > > > > Has anyone ever used ImplementationData? I know I haven't, and I goggled > > for it, but all I found was the ladspa.h file, which has a comment to the > > affect of: we're not sure why you'd need this, but, just incase here's a > > void *. > > > > If anoyone has used it, or has a potential use for it, it should stay, but > > otherwise it should go IMHO. > > I was just thinking this while going through the header (cleaned it up a > bit). I don't even really understand what it's purpose is to be honest, > never have. > > What does it allow that would not be possible if it weren't there? Well, it somewhere to stash "class" level information, but I just use statics (easier) and/or shm (harder, but cross host) for that. It would be a bit tricky to use as you'd have to be really sure that the host was only going to request one descriptor, otherwise you'd have multiple copies of your "class" data, which could be either wasteful or dangerous. - Steve From paniq at paniq.org Tue Apr 25 18:33:50 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Apr 25 18:25:53 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060425220228.GS24930@login.ecs.soton.ac.uk> References: <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> Message-ID: <1146004431.14289.42.camel@localhost> On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote: > I think the easiest thing would be for the plugin to list its required > features in the data file, then the host can weed them out without even > getting that far. yup. > The plugin may just choose to modify its behaviour, not refuse, so the > featuers list still should be passed to instantiate IMHO. if it never refuses then its ok with me ;) > > > - why does the plugin require its own bundle path for instantiation? > > this can usually be deduced from the dl's own runtime image information, > > no? otherwise, an explanation of this choice in the comment would be > > nice. > > Can it? I wasn't aware of that, in that case its redundant. i assume the lib file resides in the bundle path or the bundle path has been compiled into the lib. on win32, GetModulePath can be used to get the path to the current module, i do not know the posix equivalent to do that. alternatively the host could be required to chdir to the bundle folder before the plugin is being instantiated? > It should be perfectly possible to load both. Personally I prefer to > remove obsolete cruft, but its a matter of taste. I did consder just > ignoring the obsolete fields and resusing label as the uri, but its kinda > ugly. i just had a discussion with dave robillard on irc regarding this topic. my original (silly) wish of just changing the name has now a pragmatical basis. from my point of view, ladspa 2 is something different than ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated plugin on the system. counting the mass of different plugins already available, it might take up to a year until distros catch up. you could avoid these migration issues if ladspa 2 had an entirely different name. none of the previous binaries have to be rebuilt, and can happily bitrot until no distro is supporting them anymore. it is maybe neccessary to support future api changes from the start, to allow soft migrations? > > Yes, but that's desirable anyway. With some of the (potential) new > capbilities there are less ugly ways to do some of the things DSSI does, > DSSI 2 should be much less complex that 1. > how are parameter boundaries determined now? are all parameters clamped to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the comments? -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From torbenh at gmx.de Tue Apr 25 18:23:29 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Apr 25 18:27:32 2006 Subject: [linux-audio-dev] Update to LADSPA 2 strawman In-Reply-To: <1146001301.14289.12.camel@localhost> References: <20060425102842.GJ24930@login.ecs.soton.ac.uk> <20060425132931.GB21880@falcon.fugal.net> <20060425141134.GO24930@login.ecs.soton.ac.uk> <1146001301.14289.12.camel@localhost> Message-ID: <20060425222329.GA10233@mobilat> On Tue, Apr 25, 2006 at 11:41:41PM +0200, Leonard paniq Ritter wrote: > LADSPA is not a sexy name. please consider using something more erotic > this time.. acronyms are so 80s :) its retro, it ALL going back to the eighties. > > i'm going to read the header file now. > > On Tue, 2006-04-25 at 15:11 +0100, Steve Harris wrote: > > On Tue, Apr 25, 2006 at 07:29:31AM -0600, Hans Fugal wrote: > > > On Tue, 25 Apr 2006 at 11:28 +0100, Steve Harris wrote: > > > > I'd hate to see a future where there are plugins for translating between > > > > different kinds of boring PCM data, that would suck, but this could allow > > > > > > Hmm, well couldn't we have one libsndfile plugin that can convert > > > between whatever common boring PCM formats you like? I haven't looked > > > closely at the ladspa2 stuff yet - is it possible to change these port > > > types at runtime, if so the libsndfile plugin would only need an input > > > and an output... > > > > Their constant. > > > > But that's what I was trying to avoid, the current sitatuion is that all > > LADSPA plugins speak only IEEE floats, and that's really nice. > > > > You can end up burning a lot of memory bandwidth and cpu just doing > > pointless PCM conversions. > > > > - Steve > -- > -- leonard "paniq" ritter > -- http://www.mjoo.org > -- http://www.paniq.org > > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From paniq at paniq.org Tue Apr 25 18:35:14 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Apr 25 18:27:41 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060425220421.GT24930@login.ecs.soton.ac.uk> References: <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <1146002289.3637.1.camel@DaveLap> <20060425220421.GT24930@login.ecs.soton.ac.uk> Message-ID: <1146004515.14289.44.camel@localhost> > If we ever have an ABI change in the future then the LADSPA 1 > pseudo-compatibility will be lost anyway. there is a difference between fixing and recompiling code ;) -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From drobilla at connect.carleton.ca Tue Apr 25 18:36:37 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Apr 25 18:36:13 2006 Subject: [linux-audio-dev] LADSPA_Descriptor.ImplementationData usage? In-Reply-To: <20060425221138.GU24930@login.ecs.soton.ac.uk> References: <20060425214755.GR24930@login.ecs.soton.ac.uk> <1146002479.3637.5.camel@DaveLap> <20060425221138.GU24930@login.ecs.soton.ac.uk> Message-ID: <1146004597.3637.19.camel@DaveLap> On Tue, 2006-04-25 at 23:11 +0100, Steve Harris wrote: > On Tue, Apr 25, 2006 at 06:01:18PM -0400, Dave Robillard wrote: > > On Tue, 2006-04-25 at 22:47 +0100, Steve Harris wrote: > > > I'm in a cruft killing mood. > > > > > > Has anyone ever used ImplementationData? I know I haven't, and I goggled > > > for it, but all I found was the ladspa.h file, which has a comment to the > > > affect of: we're not sure why you'd need this, but, just incase here's a > > > void *. > > > > > > If anoyone has used it, or has a potential use for it, it should stay, but > > > otherwise it should go IMHO. > > > > I was just thinking this while going through the header (cleaned it up a > > bit). I don't even really understand what it's purpose is to be honest, > > never have. > > > > What does it allow that would not be possible if it weren't there? > > Well, it somewhere to stash "class" level information, but I just use > statics (easier) and/or shm (harder, but cross host) for that. > > It would be a bit tricky to use as you'd have to be really sure that the > host was only going to request one descriptor, otherwise you'd have > multiple copies of your "class" data, which could be either wasteful or > dangerous. Ah. It makes sense I suppose, but class data can be static or just put in the LADSPA_Handle anyway. I say if it /can/ go without loss of functionality, it should go, so let's check... I just grepped my plugins source directory, which I'm relatively certain contains every LADSPA plugin ever released (and some that weren't). Other than some (unused) boilerplate in CMT's C++ wrappper, and setting it to NULL, it's not used once. -DR- From drobilla at connect.carleton.ca Tue Apr 25 18:46:41 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Apr 25 18:46:21 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146004431.14289.42.camel@localhost> References: <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> Message-ID: <1146005201.3637.29.camel@DaveLap> On Wed, 2006-04-26 at 00:33 +0200, Leonard "paniq" Ritter wrote: > On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote: > > I think the easiest thing would be for the plugin to list its required > > features in the data file, then the host can weed them out without even > > getting that far. > > yup. ++ Definitely shouldn't have to instantiate a plugin to see if you even want it, especially since (as mentioned) this would make the user experience awful. > > The plugin may just choose to modify its behaviour, not refuse, so the > > featuers list still should be passed to instantiate IMHO. > > if it never refuses then its ok with me ;) Plugins must be able to refuse hosts and hosts must be able to refuse plugins. It's the only way to allow extensions. I _guarantee_ plugins will exist that some hosts just don't want (they already do with LADSPA1), and some plugins will exists that require features hosts are not required to provide. This is a Good Thing. > i just had a discussion with dave robillard on irc regarding this topic. > my original (silly) wish of just changing the name has now a pragmatical > basis. from my point of view, ladspa 2 is something different than > ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated > plugin on the system. counting the mass of different plugins already > available, it might take up to a year until distros catch up. you could > avoid these migration issues if ladspa 2 had an entirely different name. > none of the previous binaries have to be rebuilt, and can happily bitrot > until no distro is supporting them anymore. While I am with you on the name thing, you don't understand. LADSPA2 will be completely installable in parallel with LADSPA1. Obviously it will not "replace" LADSPA1 on a system and immediately break all the installed plugins! > how are parameter boundaries determined now? are all parameters clamped > to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the > comments? This, like most everything else, is in the data file. You really need to read more than the header before commenting further ;) -DR- From paniq at paniq.org Tue Apr 25 19:23:27 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Apr 25 19:15:23 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146005201.3637.29.camel@DaveLap> References: <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <1146005201.3637.29.camel@DaveLap> Message-ID: <1146007407.14289.54.camel@localhost> On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard wrote: > Plugins must be able to refuse hosts and hosts must be able to refuse > plugins. It's the only way to allow extensions. I _guarantee_ plugins > will exist that some hosts just don't want (they already do with > LADSPA1), and some plugins will exists that require features hosts are > not required to provide. This is a Good Thing. maybe in a Perfect World. in practice, we are going to face irritations when plugins demand weird non-unified URIs to be passed in order to run at all. from what i see, no new URIs can be invented without requiring immediate support in all available hosts, and plugins that initially only work for one host are not that cool. ergo, the "feature" of blocking instantiation for a host not passing a required URI will be rarely used, for the simple reason that it might not work with all hosts. thus, do not allow it by spec. from my point of view, host features should be seen as "hints", which are not required, but of a suggestive nature. my argumentation is chaotic. decipher the obvious! > > While I am with you on the name thing, you don't understand. LADSPA2 > will be completely installable in parallel with LADSPA1. Obviously it > will not "replace" LADSPA1 on a system and immediately break all the > installed plugins! i hope this is taken care of! the new header suggests replacement, not complementation. > > This, like most everything else, is in the data file. You really need > to read more than the header before commenting further ;) the trusty header should be all documentation required... there was also no reference to additional documents in it. how about adding it? :o) > > -DR- > -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From drobilla at connect.carleton.ca Tue Apr 25 19:59:16 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Apr 25 19:58:54 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146007407.14289.54.camel@localhost> References: <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <1146005201.3637.29.camel@DaveLap> <1146007407.14289.54.camel@localhost> Message-ID: <1146009556.5918.12.camel@DaveLap> On Wed, 2006-04-26 at 01:23 +0200, Leonard "paniq" Ritter wrote: > On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard wrote: > > Plugins must be able to refuse hosts and hosts must be able to refuse > > plugins. It's the only way to allow extensions. I _guarantee_ plugins > > will exist that some hosts just don't want (they already do with > > LADSPA1), and some plugins will exists that require features hosts are > > not required to provide. This is a Good Thing. > > maybe in a Perfect World. in practice, we are going to face irritations > when plugins demand weird non-unified URIs to be passed in order to run > at all. from what i see, no new URIs can be invented without requiring > immediate support in all available hosts Where did you get this crazy idea? The whole point is that different hosts can provide different features. > and plugins that initially > only work for one host are not that cool. ergo, the "feature" of > blocking instantiation for a host not passing a required URI will be > rarely used, for the simple reason that it might not work with all > hosts. thus, do not allow it by spec. You want to impose plugins work on the lowest common denominator of hosts. Basically this amounts to mandating that certain plugins simply can not exist. Why would you want to do that? > from my point of view, host features should be seen as "hints", which > are not required, but of a suggestive nature. Plugins are free to interpret them as such and not /require/ the feature. It's totally up to the plugin. > my argumentation is chaotic. decipher the obvious! > > > > > While I am with you on the name thing, you don't understand. LADSPA2 > > will be completely installable in parallel with LADSPA1. Obviously it > > will not "replace" LADSPA1 on a system and immediately break all the > > installed plugins! > > i hope this is taken care of! the new header suggests replacement, not > complementation. The fact that you even considered that someone would really do this is frightening. Not an issue ;) > > This, like most everything else, is in the data file. You really need > > to read more than the header before commenting further ;) > > the trusty header should be all documentation required... there was also > no reference to additional documents in it. how about adding it? :o) If you think the header should be all the documentation required, then you completely Don't Get It on a fundamental level. Read the example plugin - all of it. -DR- From paniq at paniq.org Tue Apr 25 21:11:10 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Apr 25 21:02:45 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146009556.5918.12.camel@DaveLap> References: <1145832033.2493.89.camel@DaveLap> <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <1146005201.3637.29.camel@DaveLap> <1146007407.14289.54.camel@localhost> <1146009556.5918.12.camel@DaveLap> Message-ID: <1146013870.14289.107.camel@localhost> On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard wrote: > On Wed, 2006-04-26 at 01:23 +0200, Leonard "paniq" Ritter wrote: > > On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard wrote: > > > Plugins must be able to refuse hosts and hosts must be able to refuse > > > plugins. It's the only way to allow extensions. I _guarantee_ plugins > > > will exist that some hosts just don't want (they already do with > > > LADSPA1), and some plugins will exists that require features hosts are > > > not required to provide. This is a Good Thing. > > > > maybe in a Perfect World. in practice, we are going to face irritations > > when plugins demand weird non-unified URIs to be passed in order to run > > at all. from what i see, no new URIs can be invented without requiring > > immediate support in all available hosts > > Where did you get this crazy idea? The whole point is that different > hosts can provide different features. i agree. but i suppose this is a misunderstanding. why do you think it is a crazy idea? > > > and plugins that initially > > only work for one host are not that cool. ergo, the "feature" of > > blocking instantiation for a host not passing a required URI will be > > rarely used, for the simple reason that it might not work with all > > hosts. thus, do not allow it by spec. > > You want to impose plugins work on the lowest common denominator of > hosts. Basically this amounts to mandating that certain plugins simply > can not exist. Why would you want to do that? no i do not want to do that. this is a misunderstanding. please explain how you got this impression. > > > i hope this is taken care of! the new header suggests replacement, not > > complementation. > > The fact that you even considered that someone would really do this is > frightening. Not an issue ;) i have seen things you humans will never understand. > > If you think the header should be all the documentation required, then > you completely Don't Get It on a fundamental level. Read the example > plugin - all of it. i was able to implement a working ladspa host implementation only from the header, and that was a good experience. i would like it if it could stay that way. a tiny reference to an additional document that should be read in the header would also be cool. not mentioning required literature is unfriendly ;) -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From conrad at metadecks.org Tue Apr 25 21:27:28 2006 From: conrad at metadecks.org (Conrad Parker) Date: Tue Apr 25 21:27:45 2006 Subject: [linux-audio-dev] all-purpose xplatform audio decoding library? In-Reply-To: <20060426074451.15f680e4.mle+la@mega-nerd.com> References: <1146000834.14289.9.camel@localhost> <20060426074451.15f680e4.mle+la@mega-nerd.com> Message-ID: <20060426012728.GA4582@vergenet.net> On Wed, Apr 26, 2006 at 07:44:51AM +1000, Erik de Castro Lopo wrote: > Leonard \ wrote: > > > http://www.mega-nerd.com/libsndfile/ > > no ogg support > > Ogg support has been "in progress" for about 2 years now: > > http://www.metadecks.org/software/libsndfile/ > > Feel free to ping Conrad Parker about this. and feel free to test out the code at the URL Erik gave :) cheers, Conrad. From indigo at bitglue.com Tue Apr 25 22:05:25 2006 From: indigo at bitglue.com (Phil Frost) Date: Tue Apr 25 22:05:32 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146013870.14289.107.camel@localhost> References: <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <1146005201.3637.29.camel@DaveLap> <1146007407.14289.54.camel@localhost> <1146009556.5918.12.camel@DaveLap> <1146013870.14289.107.camel@localhost> Message-ID: <20060426020525.GA19623@unununium.org> On Wed, Apr 26, 2006 at 03:11:10AM +0200, Leonard paniq Ritter wrote: > On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard wrote: > > If you think the header should be all the documentation required, then > > you completely Don't Get It on a fundamental level. Read the example > > plugin - all of it. > > i was able to implement a working ladspa host implementation only from > the header, and that was a good experience. i would like it if it could > stay that way. a tiny reference to an additional document that should be > read in the header would also be cool. not mentioning required > literature is unfriendly ;) You are not alone on this one. I think it's great to have as much data as possible in a place that need not be dlopened to access. However, if I have to learn to use some whizz-bang library to read yet another markup language, spend an hour at w3c to learn about all these web-inspired formats, and grok some ladspa-specific schema to manipulate a plugin, I think this Simple Plugin API has missed the mark. Now, obviously the current example is incomplete, but whenever this stuff is done, I shouldn't have to write more than 5 lines of C to shove some bits through a plugin, and it shouldn't take me more than 5 minutes from the time I google "ladspa documentation" to learn to do it. If browsing or using ladspa plugins would require more than 5 lines of C or learning some new technology or library that does far more than I care about, I suggest the ladspa sdk include a well documented, simple convenience library to do the things that any ladspa host would want to do. This includes things like finding available plugins, and querying them for version, description, documentation references, and loading. If everything I need to know to use ladspa won't reasonably fit in a header, it isn't simple. From paul at linuxaudiosystems.com Tue Apr 25 22:55:55 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Apr 25 22:52:20 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426020525.GA19623@unununium.org> References: <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <1146005201.3637.29.camel@DaveLap> <1146007407.14289.54.camel@localhost> <1146009556.5918.12.camel@DaveLap> <1146013870.14289.107.camel@localhost> <20060426020525.GA19623@unununium.org> Message-ID: <1146020155.30453.88.camel@localhost.localdomain> On Tue, 2006-04-25 at 22:05 -0400, Phil Frost wrote: > You are not alone on this one. I think it's great to have as much data > as possible in a place that need not be dlopened to access. However, if > I have to learn to use some whizz-bang library to read yet another > markup language, spend an hour at w3c to learn about all these > web-inspired formats, and grok some ladspa-specific schema to manipulate > a plugin, I think this Simple Plugin API has missed the mark. > > Now, obviously the current example is incomplete, but whenever this > stuff is done, I shouldn't have to write more than 5 lines of C to shove > some bits through a plugin, and it shouldn't take me more than 5 minutes > from the time I google "ladspa documentation" to learn to do it. it takes *way* more lines of code than that to use a ladspa plugin in this way, and thats for the existing header-only specification. one the design goals of a good plugin API is to make life simple for plugins, because there are lots of them and presumably quite a few authors too, at a certain expense to hosts, because there are relatively few of them and their authors are likely to be more skilled at what they are doing. there are lots of little gotchas even with the amazingly simple API that LADSPA 1 represents, and quite a few of these will become simpler or will vanish with the metadata scheme that steve has outlined. --p From drobilla at connect.carleton.ca Tue Apr 25 23:16:30 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Apr 25 23:16:08 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426020525.GA19623@unununium.org> References: <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <1146005201.3637.29.camel@DaveLap> <1146007407.14289.54.camel@localhost> <1146009556.5918.12.camel@DaveLap> <1146013870.14289.107.camel@localhost> <20060426020525.GA19623@unununium.org> Message-ID: <1146021390.8910.4.camel@DaveLap> On Tue, 2006-04-25 at 22:05 -0400, Phil Frost wrote: > On Wed, Apr 26, 2006 at 03:11:10AM +0200, Leonard paniq Ritter wrote: > > On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard wrote: > > > If you think the header should be all the documentation required, then > > > you completely Don't Get It on a fundamental level. Read the example > > > plugin - all of it. > > > > i was able to implement a working ladspa host implementation only from > > the header, and that was a good experience. i would like it if it could > > stay that way. a tiny reference to an additional document that should be > > read in the header would also be cool. not mentioning required > > literature is unfriendly ;) > > You are not alone on this one. I think it's great to have as much data > as possible in a place that need not be dlopened to access. However, if > I have to learn to use some whizz-bang library to read yet another > markup language, spend an hour at w3c to learn about all these > web-inspired formats, and grok some ladspa-specific schema to manipulate > a plugin, I think this Simple Plugin API has missed the mark. > > Now, obviously the current example is incomplete, but whenever this > stuff is done, I shouldn't have to write more than 5 lines of C to shove > some bits through a plugin, and it shouldn't take me more than 5 minutes > from the time I google "ladspa documentation" to learn to do it. > > If browsing or using ladspa plugins would require more than 5 lines of C > or learning some new technology or library that does far more than I > care about, I suggest the ladspa sdk include a well documented, simple > convenience library to do the things that any ladspa host would want to > do. This includes things like finding available plugins, and querying > them for version, description, documentation references, and loading. > > If everything I need to know to use ladspa won't reasonably fit in a > header, it isn't simple. You're in luck. I'm already in the process of writing said library. :) Loading and using a LADSPA2 plugin (using the library) will be significantly less code than loading a LADSPA1, and certainly be a _lot_ more readable. -DR- From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 01:48:32 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 01:48:52 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146004431.14289.42.camel@localhost> References: <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> Message-ID: <20060426054832.GB21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 12:33:50 +0200, Leonard paniq Ritter wrote: > On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote: > > I think the easiest thing would be for the plugin to list its required > > features in the data file, then the host can weed them out without even > > getting that far. > > yup. > > > The plugin may just choose to modify its behaviour, not refuse, so the > > featuers list still should be passed to instantiate IMHO. > > if it never refuses then its ok with me ;) It's certainly allowed to refuse, it would just be bad manners, unless the host has ignored the required features list. > > > - why does the plugin require its own bundle path for instantiation? > > > this can usually be deduced from the dl's own runtime image information, > > > no? otherwise, an explanation of this choice in the comment would be > > > nice. > > > > Can it? I wasn't aware of that, in that case its redundant. > > i assume the lib file resides in the bundle path or the bundle path has > been compiled into the lib. on win32, GetModulePath can be used to get > the path to the current module, i do not know the posix equivalent to do > that. thats platform specific though, seems like the plugins shouldn't be full of #ifdef WIN32 ... code. > alternatively the host could be required to chdir to the bundle folder > before the plugin is being instantiated? Thats likely to cause all manner of excitement. > > It should be perfectly possible to load both. Personally I prefer to > > remove obsolete cruft, but its a matter of taste. I did consder just > > ignoring the obsolete fields and resusing label as the uri, but its kinda > > ugly. > > i just had a discussion with dave robillard on irc regarding this topic. > my original (silly) wish of just changing the name has now a pragmatical > basis. from my point of view, ladspa 2 is something different than > ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated > plugin on the system. counting the mass of different plugins already > available, it might take up to a year until distros catch up. you could > avoid these migration issues if ladspa 2 had an entirely different name. > none of the previous binaries have to be rebuilt, and can happily bitrot > until no distro is supporting them anymore. There is no LADSPA "system", its just a specification, so theres nothing to be replaced. All LADSPA 1.x software will be unaffected. > it is maybe neccessary to support future api changes from the start, to > allow soft migrations? Perhaps, I think that can be done in the data though. > > Yes, but that's desirable anyway. With some of the (potential) new > > capbilities there are less ugly ways to do some of the things DSSI does, > > DSSI 2 should be much less complex that 1. > > > > how are parameter boundaries determined now? are all parameters clamped > to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the > comments? Thier specified by range hints, allowing natural values, and the plugins are required to accept any value, though not neccesarily do anything sensibe with it. We Like It That Way. - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 02:23:48 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 02:24:24 2006 Subject: [linux-audio-dev] "LADSPA 2" name Message-ID: <20060426062348.GC21022@login.ecs.soton.ac.uk> Several people have suggested that LADSPA is not a great name for what we are calling LADSPA 2. Reasons for this include: The L, it's not really linux specific, and though /we/ know that its the L of LAD, its not obvious to people outside. The S, it ain't really going to be simple. For someone like me, who is neck deep in triples on a daily basis, 2.0 seems like the paragon of simplicity, but I can imagine 2.9 being quite a beast. LADSPA, (pron. ladspuh?) is a bit of a mouthful, and not exactly catchy. 2.0, it's not going to be obvious to all users that 2.0 and 1.0 are binary incompatible. I'm not sure everyone thinks in major and minor revisions. So, with some trepidation I suggest that we think about naming, with the proviso that if we haven't reached consensus by May 10th we default to LADSPA 2.0, and live with the pain. ---- My suggestion is that we ressurect the XAP name (http://www.google.com/search?q=lad+xap) It stood for Xap Audio Plugin IIRC. Pros: it's short*, relatively unused** and pronouncable*** Cons: xap.{com,org,net} will have gone long ago (too short), theres a small ammount of baggage. - Steve * I've typed LADSPA_ a lot ** There is a home automaption protocol, called xAP that takes plugin modules. Though I think we started using the name around the same time, they seem like nice people and we should OK it with them. *** "zap"@en-gb From v2 at iki.fi Wed Apr 26 04:10:02 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Wed Apr 26 04:10:15 2006 Subject: [linux-audio-dev] "LADSPA 2" name Message-ID: <1146039001.444f2ada06a6d@www1.helsinki.fi> Quoting Steve Harris : > My suggestion is that we ressurect the XAP name > (http://www.google.com/search?q=lad+xap) > It stood for Xap Audio Plugin IIRC. > > Pros: it's short*, relatively unused** and pronouncable*** More pros: we would have a VST -alike logo already! (looking at http://xap-plugins.org/artwork.html). And it's not too VST -alike, as XAP doesn't share a single letter with VST. > Cons: xap.{com,org,net} will have gone long ago (too short), theres a > small ammount of baggage. I think we would select a short name anyway. Most of them are gone already, so we have the same problem whichever [a-z][a-z][a-z] we select :) Sampo From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 04:17:37 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 04:18:01 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146039001.444f2ada06a6d@www1.helsinki.fi> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> Message-ID: <20060426081737.GD21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 11:10:02 +0300, Sampo Savolainen wrote: > Quoting Steve Harris : > > > My suggestion is that we ressurect the XAP name > > (http://www.google.com/search?q=lad+xap) > > It stood for Xap Audio Plugin IIRC. > > > > Pros: it's short*, relatively unused** and pronouncable*** > > More pros: we would have a VST -alike logo already! (looking at > http://xap-plugins.org/artwork.html). Indeed. I forgot to add, we also need to ask David's permission to reuse the name, seen as it was largely his baby. - Steve From christie.tom at gmail.com Wed Apr 26 04:48:01 2006 From: christie.tom at gmail.com (tom christie) Date: Wed Apr 26 04:48:08 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060425213728.GQ24930@login.ecs.soton.ac.uk> References: <1145832033.2493.89.camel@DaveLap> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> Message-ID: <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> > don't think that the string is needed I think that's fair. > One version number should be enough though, > and it doesn't have to match the actual version of the LADSPA spec Both those points (especially the second) sound simple and sensible. Okay, so on reflection... There's a case to be made that some version information ought to go into the struct, since it directly affects how the struct may be properly accessed. There are two case where you would need version information to correctly access the struct. 1) A future version extends the struct. (does not break backwards compatibility) version information is needed so that eg. a 2.1 host does not try to use 2.1 functionality in a 2.0 plugin. 2) A future version modifies the struct. (breaking backwards compatibility) case 2) is very unlikely to occur anytime soon, so let's just forget about that (it can be solved by using a new discovery function anyhow) case 1) could most simply be addressed like this: The struct starts with a single unsigned short. The host must check the version number at the start... If the plugin version >= host version: No problem - the host knows it's functionality is fully supported. If the plugin version < host version: The host may access the plugin normally and is aware of what functionality the plugin does not support. Why is this useful? Well, it provides a _built-in_ way of ensuring that the struct is properly accessed, even if the metadata file is corrupted or lost. Say a user meddles with the metadata file to make a 2.0 plugin look like a 2.1 plugin. The host attempts to access 2.1 functionality and core dumps. Say the metadata file has been lost - the plugin contains sufficient information to remain accessible although it no longer has any associated metadata. I realise that the LADSPA library should mostly enforce keeping things okay, but it seems like a nice idea to have a protected way of making sure that we don't accidentally attempt to access invalid memory when things go wrong. I would suggest then: A single unsigned short at the start of the struct, starting at '0' for ladspa 2.0 plugins and incrementing if and when the struct is extended. The LADSPA major and minor versions would stay in the metadata. Any milege in this?... From ce at christeck.de Wed Apr 26 04:59:10 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Apr 26 04:58:01 2006 Subject: [linux-audio-dev] [ANN] Simple Sysexxer 0.1 Message-ID: <200604261059.11118.ce@christeck.de> Hi all, as it is LAC time, it's also release time :) . Simple Sysexxer is a GUI sysex tool comparable to Sysexxer, but it's based on Qt4 (no KDE dependency) and ALSA only (no OSS dependency). Theoretically it should also build and run on Mac OS X, but I didn't try it yet. Feedback and bugreports are always welcome. Information and source code: http://www.christeck.de Best regards ce From blazemonger950 at hotmail.com Wed Apr 26 05:16:13 2006 From: blazemonger950 at hotmail.com (Blaze Monger) Date: Wed Apr 26 05:16:33 2006 Subject: [linux-audio-dev] Trouble compiling cheesetracker in Slackware 10.2 Message-ID: I have SCONS installed and when i type scons, it gives me this: Checking for libsigc++-1.2... Package sigc++-1.2 was not found in the pkg-config search path. Perhaps you should add the directory containing `sigc++-1.2.pc' to the PKG_CONFIG_PATH environment variable No package 'sigc++-1.2' found I've been trying to build this for hours and I can't find sigc++1.2.pc anywhere. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 05:38:50 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 05:39:27 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> References: <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> Message-ID: <20060426093850.GE21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 09:48:01 +0100, tom christie wrote: ... > Well, it provides a _built-in_ way of ensuring that the struct is > properly accessed, > even if the metadata file is corrupted or lost. > Say a user meddles with the metadata file to make a 2.0 plugin look > like a 2.1 plugin. The host attempts to access 2.1 functionality and > core dumps. > Say the metadata file has been lost - the plugin contains sufficient > information to remain accessible although it no longer has any > associated metadata. It's not metadata. If the data is corrupt or missing then youre SOL. It's just as vital as the arrays of structs were in LADSPA 1; if you dont have the data theres no way to use the plugin without causing segfaults. This is why the "plugin" is really a directory, all the stuff in there is neccesary. - Steve From dlphillips at woh.rr.com Wed Apr 26 06:06:33 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Apr 26 06:04:58 2006 Subject: [linux-audio-dev] Om-synth CVS compile problem Message-ID: <444F4629.5090108@woh.rr.com> Greetings: Has anyone else encountered this problem when compiling recent CVS Om-synth : if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DGTK_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -I../../../src/common -I../../../src/clients -DPKGDATADIR=\"/usr/local/share/om\" -DXTHREADS -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/X11R6/include -I/usr/include/atk-1.0 -DXTHREADS -I/usr/include/libglademm-2.4 -I/usr/lib/libglademm-2.4/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/libglade-2.0 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -DXTHREADS -I/usr/include/libgnomecanvasmm-2.6 -I/usr/lib/libgnomecanvasmm-2.6/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/libgnomecanvas-2.0 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libart-2.0 -I/usr/include/freetype2 -I/usr/local/include/lash-1.0 -I/usr/include/alsa -I/usr/local/include -g -O2 -DNDEBUG -DNDEBUG -pipe -fmessage-length=139 -fdiagnostics-show-location=every-line -MT PortController.o -MD -MP -MF ".deps/PortController.Tpo" -c -o PortController.o PortController.cpp; \ then mv -f ".deps/PortController.Tpo" ".deps/PortController.Po"; else rm -f ".deps/PortController.Tpo"; exit 1; fi PortController.cpp: In member function 'virtual void OmGtk::PortController::set_path(const Om::Path&)': PortController.cpp:120: error: 'class OmGtk::OmPort' has no member named 'set_name' make[4]: *** [PortController.o] Error 1 make[4]: Leaving directory `/home/dlphilp/om-synth/src/clients/gtk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/dlphilp/om-synth/src/clients' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/dlphilp/om-synth/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dlphilp/om-synth' make: *** [all] Error 2 The set_name function is commented out in OmPort.h. I've posted to the om-synth list and to the author, no responses yet. I'd like to review Om for my next LJ column, I have an older version workjingn but would like to profile the latest & greatest if possible. Best, dp From mista.tapas at gmx.net Wed Apr 26 06:06:00 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Wed Apr 26 06:07:04 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146020155.30453.88.camel@localhost.localdomain> References: <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <1146005201.3637.29.camel@DaveLap> <1146007407.14289.54.camel@localhost> <1146009556.5918.12.camel@DaveLap> <1146013870.14289.107.camel@localhost> <20060426020525.GA19623@unununium.org> <1146020155.30453.88.camel@localhost.localdomain> Message-ID: <20060426120600.3ff0c524@mango.fruits> On Tue, 25 Apr 2006 22:55:55 -0400 Paul Davis wrote: > it takes *way* more lines of code than that to use a ladspa plugin in > this way, and thats for the existing header-only specification. > > one the design goals of a good plugin API is to make life simple for > plugins, because there are lots of them and presumably quite a few > authors too, at a certain expense to hosts, because there are relatively > few of them and their authors are likely to be more skilled at what they > are doing. > > there are lots of little gotchas even with the amazingly simple API that > LADSPA 1 represents, and quite a few of these will become simpler or > will vanish with the metadata scheme that steve has outlined. Erm, just to voice my opinion on this LADSPA 2 thing i kinda hijack your post to Vote++; @Phil: Look at the example plugin. Life does get easier with this. Flo -- Palimm Palimm! http://tapas.affenbande.org From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 06:51:44 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 06:52:05 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update Message-ID: <20060426105144.GF21022@login.ecs.soton.ac.uk> I've written a first cut at an ontology/schema for the plugin RDF: http://plugin.org.uk/ladspa2/ladspa-2.ttl The term schema is a bit misleading, as it doesn't really enforce anything, it really just gives you some hints about what to write. The bulk of it is english text to explain the meaning of the bits that are no longer in the .h I tried to write it as clearly as possible, but the machine readable parts might still be a bit cryptic and there could be errors. Shout if there's any bits that don't make sense. - Steve From pshirkey at boosthardware.com Wed Apr 26 06:52:55 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Wed Apr 26 06:54:12 2006 Subject: [linux-audio-dev] Om-synth CVS compile problem In-Reply-To: <444F4629.5090108@woh.rr.com> References: <444F4629.5090108@woh.rr.com> Message-ID: <444F5107.9000708@boosthardware.com> Dave Phillips wrote: > Greetings: > > Has anyone else encountered this problem when compiling recent CVS > Om-synth : > > if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DGTK_DISABLE_DEPRECATED > -DGDK_DISABLE_DEPRECATED -I../../../src/common -I../../../src/clients > -DPKGDATADIR=\"/usr/local/share/om\" -DXTHREADS -I/usr/include/gtkmm-2.4 > -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 > -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 > -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 > -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 > -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo > -I/usr/X11R6/include -I/usr/include/atk-1.0 -DXTHREADS > -I/usr/include/libglademm-2.4 -I/usr/lib/libglademm-2.4/include > -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include > -I/usr/include/libglade-2.0 -I/usr/include/glibmm-2.4 > -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 > -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 > -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 > -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo > -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 > -DXTHREADS -I/usr/include/libgnomecanvasmm-2.6 > -I/usr/lib/libgnomecanvasmm-2.6/include -I/usr/include/gtkmm-2.4 > -I/usr/lib/gtkmm-2.4/include -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include > -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include > -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 > -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 > -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include > -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/X11R6/include > -I/usr/include/atk-1.0 -I/usr/include/libart-2.0 > -I/usr/include/freetype2 -I/usr/local/include/lash-1.0 > -I/usr/include/alsa -I/usr/local/include -g -O2 -DNDEBUG -DNDEBUG > -pipe -fmessage-length=139 -fdiagnostics-show-location=every-line -MT > PortController.o -MD -MP -MF ".deps/PortController.Tpo" -c -o > PortController.o PortController.cpp; \ > then mv -f ".deps/PortController.Tpo" ".deps/PortController.Po"; > else rm -f ".deps/PortController.Tpo"; exit 1; fi > PortController.cpp: In member function 'virtual void > OmGtk::PortController::set_path(const Om::Path&)': > PortController.cpp:120: error: 'class OmGtk::OmPort' has no member named > 'set_name' > make[4]: *** [PortController.o] Error 1 > make[4]: Leaving directory `/home/dlphilp/om-synth/src/clients/gtk' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/dlphilp/om-synth/src/clients' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/dlphilp/om-synth/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/dlphilp/om-synth' > make: *** [all] Error 2 > > > The set_name function is commented out in OmPort.h. > > I've posted to the om-synth list and to the author, no responses yet. > I'd like to review Om for my next LJ column, I have an older version > workjingn but would like to profile the latest & greatest if possible. > > Best, > > dp > > Hi, I got it using gcc-4.1.0. I wasn't able to fix it myself but it's a gcc syntax problem. It's was more then a two line fix so I left it. We should probably inform the author :) Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From larsl at users.sourceforge.net Wed Apr 26 06:53:49 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed Apr 26 06:54:17 2006 Subject: [linux-audio-dev] Om-synth CVS compile problem In-Reply-To: <444F4629.5090108@woh.rr.com> References: <444F4629.5090108@woh.rr.com> Message-ID: <1146048829.8829.2.camel@localhost> On Wed, 2006-04-26 at 06:06 -0400, Dave Phillips wrote: > Greetings: > > Has anyone else encountered this problem when compiling recent CVS > Om-synth : > > ... > > PortController.cpp: In member function 'virtual void > OmGtk::PortController::set_path(const Om::Path&)': > PortController.cpp:120: error: 'class OmGtk::OmPort' has no member named > 'set_name' > > The set_name function is commented out in OmPort.h. > > I've posted to the om-synth list and to the author, no responses yet. > I'd like to review Om for my next LJ column, I have an older version > workjingn but would like to profile the latest & greatest if possible. I compiled it just yesterday. set_name() has moved up to the superclass LibFlowCanvas::Port, you need the latest CVS version of flowcanvas. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060426/4e0255fa/attachment.bin From paul at linuxaudiosystems.com Wed Apr 26 07:05:20 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Apr 26 07:01:45 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <20060426105144.GF21022@login.ecs.soton.ac.uk> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> Message-ID: <1146049520.16871.5.camel@localhost.localdomain> On Wed, 2006-04-26 at 11:51 +0100, Steve Harris wrote: > I've written a first cut at an ontology/schema for the plugin RDF: > http://plugin.org.uk/ladspa2/ladspa-2.ttl > > The term schema is a bit misleading, as it doesn't really enforce > anything, it really just gives you some hints about what to write. The > bulk of it is english text to explain the meaning of the bits that are no > longer in the .h > > I tried to write it as clearly as possible, but the machine readable parts > might still be a bit cryptic and there could be errors. Shout if there's > any bits that don't make sense. i know you didn't want to actually change much of the spec, but i would like to protest at the continued inclusion of the "logarithmic" port hint. its totally useless. at the very least, the hint should be removed and replaced by two other hints: logarithmicE and logarithmic10. saying that something might be better viewed using a logarithmic scale really says nothing useful. a more satisfactory solution would add "dBFS" to indicate that the port contains values indicating volumetric or gain levels. something like that. From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 07:22:12 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 07:22:38 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <1146049520.16871.5.camel@localhost.localdomain> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> <1146049520.16871.5.camel@localhost.localdomain> Message-ID: <20060426112212.GH21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 07:05:20 -0400, Paul Davis wrote: > On Wed, 2006-04-26 at 11:51 +0100, Steve Harris wrote: > > I've written a first cut at an ontology/schema for the plugin RDF: > > http://plugin.org.uk/ladspa2/ladspa-2.ttl > > > > The term schema is a bit misleading, as it doesn't really enforce > > anything, it really just gives you some hints about what to write. The > > bulk of it is english text to explain the meaning of the bits that are no > > longer in the .h > > > > I tried to write it as clearly as possible, but the machine readable parts > > might still be a bit cryptic and there could be errors. Shout if there's > > any bits that don't make sense. > > i know you didn't want to actually change much of the spec, but i would yeah *cough* I did actualy change one thing, I droped the last clause of the integer hint, because it Makes No Damn Sense. The bit that recommends that you overshout the bounds you actually want, so that theres no rounding problems. the host has to do that, the plugin can't second guess how much leeway the hosts UI needs for rounding, and if the plugin rounds to nearest integer it all comes out in the wash anyway. Meant to say I'd done that, but forgot. > like to protest at the continued inclusion of the "logarithmic" port > hint. its totally useless. at the very least, the hint should be removed > and replaced by two other hints: logarithmicE and logarithmic10. saying > that something might be better viewed using a logarithmic scale really > says nothing useful. a more satisfactory solution would add "dBFS" to > indicate that the port contains values indicating volumetric or gain > levels. something like that. logarithmicE and logarithmic10 have the same effect (loge(x) = constant * log10(x)). But yes, I agree, its very wierd. I'm happy to ditch that hint. the only thing where it does anything like the right thing on is frequency, and there it is tricky as you can't *quite* go down to 0.0, but specifying how close to is a bit of a crapshoot - it generally depends on the sample rate. Immediatly after the spec is finished I will publish an extension that does real units stuff on controls, so hosts can intelligently handle dBFS, frequency and so on. For the record, I'm happy to drop features (many have got the chop), its adding things that I want to avoid. It's very hard to test features properly at this stage, so adding new ones is risky. Paul, while I've got your attention, are you OK with droppping runAdding? You're the person who most likly to have implemented it I think. 99% of my plugins support it, but it would have made my life much easier if they didn't. - Steve From paul at linuxaudiosystems.com Wed Apr 26 07:29:30 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Apr 26 07:25:57 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <20060426112212.GH21022@login.ecs.soton.ac.uk> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> <1146049520.16871.5.camel@localhost.localdomain> <20060426112212.GH21022@login.ecs.soton.ac.uk> Message-ID: <1146050970.16871.11.camel@localhost.localdomain> On Wed, 2006-04-26 at 12:22 +0100, Steve Harris wrote: > Paul, while I've got your attention, are you OK with droppping runAdding? > You're the person who most likly to have implemented it I think. > > 99% of my plugins support it, but it would have made my life much easier > if they didn't. Steinberg dropped it for VST 2.4, and what's good for the goose is good for the gander. Am I mixing analogies here? :) --p From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 07:36:04 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 07:36:23 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <1146050970.16871.11.camel@localhost.localdomain> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> <1146049520.16871.5.camel@localhost.localdomain> <20060426112212.GH21022@login.ecs.soton.ac.uk> <1146050970.16871.11.camel@localhost.localdomain> Message-ID: <20060426113604.GJ21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 07:29:30AM -0400, Paul Davis wrote: > On Wed, 2006-04-26 at 12:22 +0100, Steve Harris wrote: > > > Paul, while I've got your attention, are you OK with droppping runAdding? > > You're the person who most likly to have implemented it I think. > > > > 99% of my plugins support it, but it would have made my life much easier > > if they didn't. > > Steinberg dropped it for VST 2.4, and what's good for the goose is good > for the gander. Am I mixing analogies here? :) I always thought it was sauce for the goose, but google like yours more. - Steve From christie.tom at gmail.com Wed Apr 26 07:54:43 2006 From: christie.tom at gmail.com (tom christie) Date: Wed Apr 26 07:54:51 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426093850.GE21022@login.ecs.soton.ac.uk> References: <1145883487.2493.126.camel@DaveLap> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> Message-ID: <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> It's really just an extra layer of protection... I realise that the binary and data files will be accessed as a single unit, but a corrupt data file should never cause a segfault. Without a built-in struct version identifier the host (or LADSPA library) may segfault by incorrectly accessing the struct. (if the data file is corrupt) With a built-in struct version identifier the host (or LADSPA library) can ensure it will never access the struct in a way which will cause a segfault. (even if the data file is corrupt.) Okay, I'll hold my peace now ;) On 4/26/06, Steve Harris wrote: > On Wed, Apr 26, 2006 at 09:48:01 +0100, tom christie wrote: > ... > > > Well, it provides a _built-in_ way of ensuring that the struct is > > properly accessed, > > even if the metadata file is corrupted or lost. > > Say a user meddles with the metadata file to make a 2.0 plugin look > > like a 2.1 plugin. The host attempts to access 2.1 functionality and > > core dumps. > > Say the metadata file has been lost - the plugin contains sufficient > > information to remain accessible although it no longer has any > > associated metadata. > > It's not metadata. If the data is corrupt or missing then youre SOL. It's > just as vital as the arrays of structs were in LADSPA 1; if you dont have > the data theres no way to use the plugin without causing segfaults. > > This is why the "plugin" is really a directory, all the stuff in there is > neccesary. > > - Steve > From arnold.krille at gmail.com Wed Apr 26 10:22:38 2006 From: arnold.krille at gmail.com (Arnold Krille) Date: Wed Apr 26 10:22:45 2006 Subject: [linux-audio-dev] Re: LAC 2006 Live Streams In-Reply-To: <444E9AD3.2050802@folkwang-hochschule.de> References: <444E9AD3.2050802@folkwang-hochschule.de> Message-ID: <2def88b80604260722l1d1da524u55c8c9d011645b81@mail.gmail.com> Hi, 2006/4/25, Joern Nettingsmeier : > the linux audio conference 2006, which takes place at the zkm in > karlsruhe/germany from april 27 to april 30, will be streamed live for > your convenience, inspiration and enjoyment. Thanks in advance for providing this service for all of use unable to attend! I will surely be in the chats and video-streams. Eric (and the other chat-relays), be my voice, let me pull your strings, clap, cheer and ask for me!!! Arnold -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. From dlphillips at woh.rr.com Wed Apr 26 10:30:07 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Apr 26 10:28:30 2006 Subject: [linux-audio-dev] Om-synth CVS compile problem In-Reply-To: <1146048829.8829.2.camel@localhost> References: <444F4629.5090108@woh.rr.com> <1146048829.8829.2.camel@localhost> Message-ID: <444F83EF.8010203@woh.rr.com> Lars Luthman wrote: > [snip] > > >I compiled it just yesterday. set_name() has moved up to the superclass >LibFlowCanvas::Port, you need the latest CVS version of flowcanvas. > > > Thanks, Lars, that fixed the problem. Btw, is it possible to run multiple independent instances of Om-gtk ? Best, dp From larsl at users.sourceforge.net Wed Apr 26 10:52:35 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed Apr 26 10:52:41 2006 Subject: [linux-audio-dev] Om-synth CVS compile problem In-Reply-To: <444F83EF.8010203@woh.rr.com> References: <444F4629.5090108@woh.rr.com> <1146048829.8829.2.camel@localhost> <444F83EF.8010203@woh.rr.com> Message-ID: <1146063155.8829.11.camel@localhost> On Wed, 2006-04-26 at 10:30 -0400, Dave Phillips wrote: > Lars Luthman wrote: > > > [snip] > > > > > >I compiled it just yesterday. set_name() has moved up to the superclass > >LibFlowCanvas::Port, you need the latest CVS version of flowcanvas. > > > > > > > Thanks, Lars, that fixed the problem. > > Btw, is it possible to run multiple independent instances of Om-gtk ? It should be. If it isn't, that's probably a bug. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060426/39d2e4c9/attachment.bin From drobilla at connect.carleton.ca Wed Apr 26 10:55:12 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 10:54:54 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <20060426062348.GC21022@login.ecs.soton.ac.uk> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> Message-ID: <1146063313.10856.4.camel@DaveLap> On Wed, 2006-04-26 at 07:23 +0100, Steve Harris wrote: > Several people have suggested that LADSPA is not a great name for what we > are calling LADSPA 2. Reasons for this include: > > The L, it's not really linux specific, and though /we/ know that its the L > of LAD, its not obvious to people outside. > > The S, it ain't really going to be simple. For someone like me, who is > neck deep in triples on a daily basis, 2.0 seems like the paragon of > simplicity, but I can imagine 2.9 being quite a beast. > > LADSPA, (pron. ladspuh?) is a bit of a mouthful, and not exactly catchy. > > 2.0, it's not going to be obvious to all users that 2.0 and 1.0 are binary > incompatible. I'm not sure everyone thinks in major and minor revisions. > > So, with some trepidation I suggest that we think about naming, with the > proviso that if we haven't reached consensus by May 10th we default to > LADSPA 2.0, and live with the pain. > > ---- > > My suggestion is that we ressurect the XAP name > (http://www.google.com/search?q=lad+xap) > It stood for Xap Audio Plugin IIRC. > > Pros: it's short*, relatively unused** and pronouncable*** I know it's stupid, but starting with "X" has the same problem as starting with "G" and "K". Seeing XAP out of context, people will default to thinking it's some X related technology. > Cons: xap.{com,org,net} will have gone long ago (too short), theres a > small ammount of baggage. It would be very nice if we could get the specname.org domain, to provide stable resolvable plugin URIs for plugins for authors that don't have nice spiffy domains of their own... Then again, domains aren't free, and I know I'm not paying for it. :) -DR- From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 10:56:28 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 10:56:52 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> References: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> Message-ID: <20060426145627.GK21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 12:54:43PM +0100, tom christie wrote: > It's really just an extra layer of protection... > I realise that the binary and data files will be accessed as a single unit, > but a corrupt data file should never cause a segfault. That's somewhat like saying a corrupt binary should never cause a segfault... if the data file gets corrupted in a way that breaks the syntax, then there wont be enouhg data for hte host to attempt to load the plugin and it will refuse, but if through some miracle ladspa:InputControPort becomes ladspa:OutputControlPort then all kinds of crazy shit will go down. > Without a built-in struct version identifier the host (or LADSPA library) > may segfault by incorrectly accessing the struct. (if the data file is corrupt) I'm not interested in the case the data file is corrupt, its too much of a special case, and theres nothing sensible you can do about it. No-ones seriously interested in guarding against the caes where the .so is corrupt. If you care that much, ship a sha1 checksum with your plugin. > With a built-in struct version identifier the host (or LADSPA library) > can ensure it will never access the struct in a way which will cause a segfault. > (even if the data file is corrupt.) No it can't :) If the data file is currupt in any plausible way the host wont have enough information to even attept to open the plugin anyway. - Steve From drobilla at connect.carleton.ca Wed Apr 26 10:59:47 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 10:59:30 2006 Subject: [linux-audio-dev] Om-synth CVS compile problem In-Reply-To: <444F4629.5090108@woh.rr.com> References: <444F4629.5090108@woh.rr.com> Message-ID: <1146063587.10856.6.camel@DaveLap> On Wed, 2006-04-26 at 06:06 -0400, Dave Phillips wrote: > Greetings: > > Has anyone else encountered this problem when compiling recent CVS > Om-synth : > > if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DGTK_DISABLE_DEPRECATED > -DGDK_DISABLE_DEPRECATED -I../../../src/common -I../../../src/clients > -DPKGDATADIR=\"/usr/local/share/om\" -DXTHREADS -I/usr/include/gtkmm-2.4 > -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 > -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 > -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 > -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 > -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo > -I/usr/X11R6/include -I/usr/include/atk-1.0 -DXTHREADS > -I/usr/include/libglademm-2.4 -I/usr/lib/libglademm-2.4/include > -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include > -I/usr/include/libglade-2.0 -I/usr/include/glibmm-2.4 > -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 > -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 > -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 > -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo > -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 > -DXTHREADS -I/usr/include/libgnomecanvasmm-2.6 > -I/usr/lib/libgnomecanvasmm-2.6/include -I/usr/include/gtkmm-2.4 > -I/usr/lib/gtkmm-2.4/include -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include > -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include > -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 > -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 > -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include > -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/X11R6/include > -I/usr/include/atk-1.0 -I/usr/include/libart-2.0 > -I/usr/include/freetype2 -I/usr/local/include/lash-1.0 > -I/usr/include/alsa -I/usr/local/include -g -O2 -DNDEBUG -DNDEBUG > -pipe -fmessage-length=139 -fdiagnostics-show-location=every-line -MT > PortController.o -MD -MP -MF ".deps/PortController.Tpo" -c -o > PortController.o PortController.cpp; \ > then mv -f ".deps/PortController.Tpo" ".deps/PortController.Po"; > else rm -f ".deps/PortController.Tpo"; exit 1; fi > PortController.cpp: In member function 'virtual void > OmGtk::PortController::set_path(const Om::Path&)': > PortController.cpp:120: error: 'class OmGtk::OmPort' has no member named > 'set_name' > make[4]: *** [PortController.o] Error 1 > make[4]: Leaving directory `/home/dlphilp/om-synth/src/clients/gtk' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/dlphilp/om-synth/src/clients' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/dlphilp/om-synth/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/dlphilp/om-synth' > make: *** [all] Error 2 > > > The set_name function is commented out in OmPort.h. > > I've posted to the om-synth list and to the author, no responses yet. > I'd like to review Om for my next LJ column, I have an older version > workjingn but would like to profile the latest & greatest if possible. Sorry, I was busy with exams. Is your flowcanvas tree up to date? Update both trees to make sure they're synchronized. (That function is a method of a FlowCanvas class which OmPort extends) -DR- From drobilla at connect.carleton.ca Wed Apr 26 11:02:26 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 11:02:07 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <1146049520.16871.5.camel@localhost.localdomain> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> <1146049520.16871.5.camel@localhost.localdomain> Message-ID: <1146063746.10856.9.camel@DaveLap> On Wed, 2006-04-26 at 07:05 -0400, Paul Davis wrote: > On Wed, 2006-04-26 at 11:51 +0100, Steve Harris wrote: > > I've written a first cut at an ontology/schema for the plugin RDF: > > http://plugin.org.uk/ladspa2/ladspa-2.ttl > > > > The term schema is a bit misleading, as it doesn't really enforce > > anything, it really just gives you some hints about what to write. The > > bulk of it is english text to explain the meaning of the bits that are no > > longer in the .h > > > > I tried to write it as clearly as possible, but the machine readable parts > > might still be a bit cryptic and there could be errors. Shout if there's > > any bits that don't make sense. > > i know you didn't want to actually change much of the spec, but i would > like to protest at the continued inclusion of the "logarithmic" port > hint. its totally useless. at the very least, the hint should be removed > and replaced by two other hints: logarithmicE and logarithmic10. saying > that something might be better viewed using a logarithmic scale really > says nothing useful. a more satisfactory solution would add "dBFS" to > indicate that the port contains values indicating volumetric or gain > levels. something like that. Ah! No removing the logarithmic hint! :) Specifying the base along with it would be a very good idea though. Better to have a 'logarithmic' hint and a seperate 'log_base' though. -DR- From drobilla at connect.carleton.ca Wed Apr 26 11:07:23 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 11:07:04 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <20060426112212.GH21022@login.ecs.soton.ac.uk> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> <1146049520.16871.5.camel@localhost.localdomain> <20060426112212.GH21022@login.ecs.soton.ac.uk> Message-ID: <1146064043.10856.14.camel@DaveLap> On Wed, 2006-04-26 at 12:22 +0100, Steve Harris wrote: > On Wed, Apr 26, 2006 at 07:05:20 -0400, Paul Davis wrote: > > On Wed, 2006-04-26 at 11:51 +0100, Steve Harris wrote: > > > I've written a first cut at an ontology/schema for the plugin RDF: > > > http://plugin.org.uk/ladspa2/ladspa-2.ttl > > > > > > The term schema is a bit misleading, as it doesn't really enforce > > > anything, it really just gives you some hints about what to write. The > > > bulk of it is english text to explain the meaning of the bits that are no > > > longer in the .h > > > > > > I tried to write it as clearly as possible, but the machine readable parts > > > might still be a bit cryptic and there could be errors. Shout if there's > > > any bits that don't make sense. > > > > i know you didn't want to actually change much of the spec, but i would > > yeah *cough* I did actualy change one thing, I droped the last clause of > the integer hint, because it Makes No Damn Sense. The bit that recommends > that you overshout the bounds you actually want, so that theres no > rounding problems. the host has to do that, the plugin can't second guess > how much leeway the hosts UI needs for rounding, and if the plugin rounds > to nearest integer it all comes out in the wash anyway. > > Meant to say I'd done that, but forgot. > > > like to protest at the continued inclusion of the "logarithmic" port > > hint. its totally useless. at the very least, the hint should be removed > > and replaced by two other hints: logarithmicE and logarithmic10. saying > > that something might be better viewed using a logarithmic scale really > > says nothing useful. a more satisfactory solution would add "dBFS" to > > indicate that the port contains values indicating volumetric or gain > > levels. something like that. > > logarithmicE and logarithmic10 have the same effect (loge(x) = constant * > log10(x)). But yes, I agree, its very wierd. I'm happy to ditch that hint. > the only thing where it does anything like the right thing on is > frequency, and there it is tricky as you can't *quite* go down to 0.0, but > specifying how close to is a bit of a crapshoot - it generally depends on > the sample rate. > > Immediatly after the spec is finished I will publish an extension that > does real units stuff on controls, so hosts can intelligently handle dBFS, > frequency and so on. > > For the record, I'm happy to drop features (many have got the chop), its > adding things that I want to avoid. It's very hard to test features > properly at this stage, so adding new ones is risky. Logarithmic really can't go. If you bind a MIDI controller to a frequency port (be it an oscillator or lowpass filter or whatever), it's almost entirely useless if you don't know to do it logarithmically. Same thing with GUI sliders. This is really important for us using-ladspa-for-synthesis people. I got around the 0 issue by doing the log calculation on [1..n] and shifting down. Actually it even works for negative values... -DR- From drobilla at connect.carleton.ca Wed Apr 26 11:09:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 11:08:55 2006 Subject: [linux-audio-dev] Om-synth CVS compile problem In-Reply-To: <1146063155.8829.11.camel@localhost> References: <444F4629.5090108@woh.rr.com> <1146048829.8829.2.camel@localhost> <444F83EF.8010203@woh.rr.com> <1146063155.8829.11.camel@localhost> Message-ID: <1146064154.10856.16.camel@DaveLap> On Wed, 2006-04-26 at 16:52 +0200, Lars Luthman wrote: > On Wed, 2006-04-26 at 10:30 -0400, Dave Phillips wrote: > > Lars Luthman wrote: > > > > > [snip] > > > > > > > > >I compiled it just yesterday. set_name() has moved up to the superclass > > >LibFlowCanvas::Port, you need the latest CVS version of flowcanvas. > > > > > > > > > > > Thanks, Lars, that fixed the problem. > > > > Btw, is it possible to run multiple independent instances of Om-gtk ? > > It should be. If it isn't, that's probably a bug. Worked last time I tried it anyway. It's fun to do it on seperate computers and watch the plugins move around and connect themselves as if by magic :) -DR- From ico.bukvic at gmail.com Wed Apr 26 11:10:05 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Wed Apr 26 11:10:14 2006 Subject: [linux-audio-dev] LAC 2006 Live Streams In-Reply-To: <444E9AD3.2050802@folkwang-hochschule.de> Message-ID: <00a901c66943$80f038f0$0400a8c0@64BitBadass> Cool! Joern, do you need access to LAD site to post the recordings/materials for archival purposes and/or to offload the main server? Please e-mail me off-list and I'll provide you with the necessary info. Best wishes, Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Joern Nettingsmeier > Sent: Tuesday, April 25, 2006 5:56 PM > To: linux-audio-user@music.columbia.edu; linux-audio- > dev@music.columbia.edu; linux-audio-announce@music.columbia.edu > Subject: [linux-audio-dev] LAC 2006 Live Streams > > hi *! > > > the linux audio conference 2006, which takes place at the zkm in > karlsruhe/germany from april 27 to april 30, will be streamed live for > your convenience, inspiration and enjoyment. > > all presentations (which are listed on > http://lac.zkm.de/2006/program.shtml) are covered as ogg vorbis audio > streams in two bitrates (one for modem users and one for > slightly-more-broadband users) and ogg theora/vorbis a/v streams (for > broadband users only). to watch and/or listen, you can use a recent > version of mplayer, vlc or curl | theora123, if you prefer. > > the stream urls are listed at > http://lac.zkm.de/2006/streaming.shtml. we will start test streams > tomorrow by 12:00 utc+2. as always, there will be chat channels to go > with the streams, where you can report problems, discuss the > presentations and also ask questions which will be relayed to the live > audience by the local chat operators here at zkm. > these channels are #lac2006 for general issues and chitchat, and > #lac2006-track1 and #lac2006-track2 for questions and remarks about the > current presentation, all on irc.freenode.net. > > you will be able to download the presentation slides in advance to read > along as you listen and watch. the quality of the video streams will not > be sufficient to read the projections, but you should easily be able to > make out which slide is currently up. > > > on behalf of eric rzewnicki (who did most of the streaming work this > year) and the rest of the lac organizational team i wish you lots of fun > with the streams. kudos again to the icecast team, especially to karl > heyes, all the folks at xiph.org who brought us all those great free > multimedia codecs, and the crew here at zkm for their great support and > cooperation! > > > best, > > > j?rn From drobilla at connect.carleton.ca Wed Apr 26 11:18:13 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 11:18:35 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426093850.GE21022@login.ecs.soton.ac.uk> References: <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> Message-ID: <1146064693.10856.25.camel@DaveLap> On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote: > This is why the "plugin" is really a directory, all the stuff in there is > neccesary. On the plugin bundle thing, I've got working C code that takes a path to the directory, parses manifest.ttl, gleams the available plugin DLLs and data files from that, and enumerates all the plugins in the DLL. We need to clarify some things about bundles themselves: - What is the significance of the bundle name itself? (We need to avoid clashes somehow) - Do they contain one plugin variant, or any number? - One DLL or many? - What's the relation between the two above points? I'm not sure about number-of-plugins-per-bundle (though putting all of, say, swh-plugins in one bundle seems counter to the intent to me?) but I will suggest we reccommend that one DLL contains only variants of one plugin (or a group of very similar plugins). Reasoning is to avoid things like cmt.so which has a huge number of completely unrelated plugins in one lib, meaning a host has to link in all that crap just to use a simple amplifier plugin, which is no good. -DR- From christie.tom at gmail.com Wed Apr 26 12:48:32 2006 From: christie.tom at gmail.com (tom christie) Date: Wed Apr 26 12:48:38 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426145627.GK21022@login.ecs.soton.ac.uk> References: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> <20060426145627.GK21022@login.ecs.soton.ac.uk> Message-ID: <958b3a2e0604260948n241c493dra84179619391eca7@mail.gmail.com> > That's somewhat like saying a corrupt binary > should never cause a segfault... No, not at all. The data file is accessed as an input stream (to the host / LADSPA library). It's fine for a bad data file to cause the library to fail to be able to load it, or to load it and produce unexpected output, but it should *never* cause it to segfault. > No-ones seriously interested in guarding against the caes > where the .so is corrupt. Agreed, and neither am I. All I'm saying is that if the discovery function may potentially return differing structs from one LADSPA version to another, then it ought also provide a mechanism of determining exactly which struct it is returning. If it does that, then the worst that can ever happen is that the binary is accessed with duff input (no segfaulting). Okay, I really will shut it now, I begin to suspect I'm labouring the point :) t. From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 12:48:36 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 12:49:19 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146063313.10856.4.camel@DaveLap> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146063313.10856.4.camel@DaveLap> Message-ID: <20060426164836.GL21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 10:55:12AM -0400, Dave Robillard wrote: > > My suggestion is that we ressurect the XAP name > > (http://www.google.com/search?q=lad+xap) > > It stood for Xap Audio Plugin IIRC. > > > > Pros: it's short*, relatively unused** and pronouncable*** > > I know it's stupid, but starting with "X" has the same problem as > starting with "G" and "K". Seeing XAP out of context, people will > default to thinking it's some X related technology. Or XML related, yes. It's a risk. > > Cons: xap.{com,org,net} will have gone long ago (too short), theres a > > small ammount of baggage. > > It would be very nice if we could get the specname.org domain, to > provide stable resolvable plugin URIs for plugins for authors that don't > have nice spiffy domains of their own... > > Then again, domains aren't free, and I know I'm not paying for it. :) If we can find one thats not too expensive I'll pick up the tab. - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 12:52:02 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 12:52:20 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <1146064043.10856.14.camel@DaveLap> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> <1146049520.16871.5.camel@localhost.localdomain> <20060426112212.GH21022@login.ecs.soton.ac.uk> <1146064043.10856.14.camel@DaveLap> Message-ID: <20060426165201.GM21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 11:07:23AM -0400, Dave Robillard wrote: > > > like to protest at the continued inclusion of the "logarithmic" port > > > hint. its totally useless. at the very least, the hint should be removed > > > and replaced by two other hints: logarithmicE and logarithmic10. saying > > > that something might be better viewed using a logarithmic scale really > > > says nothing useful. a more satisfactory solution would add "dBFS" to > > > indicate that the port contains values indicating volumetric or gain > > > levels. something like that. > > > > logarithmicE and logarithmic10 have the same effect (loge(x) = constant * > > log10(x)). But yes, I agree, its very wierd. I'm happy to ditch that hint. > > the only thing where it does anything like the right thing on is > > frequency, and there it is tricky as you can't *quite* go down to 0.0, but > > specifying how close to is a bit of a crapshoot - it generally depends on > > the sample rate. > > > > Immediatly after the spec is finished I will publish an extension that > > does real units stuff on controls, so hosts can intelligently handle dBFS, > > frequency and so on. > > Logarithmic really can't go. If you bind a MIDI controller to a > frequency port (be it an oscillator or lowpass filter or whatever), it's > almost entirely useless if you don't know to do it logarithmically. > Same thing with GUI sliders. This is really important for us > using-ladspa-for-synthesis people. > > I got around the 0 issue by doing the log calculation on [1..n] and > shifting down. Actually it even works for negative values... But that doesnt give the desired behaviour for freuqnecy inputs, and its a hack at best for dBs. If you can hold out for the units extension (within 24h of the 2.0 spec, hopefully) it will all be a lot easier. - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 12:52:45 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 12:53:38 2006 Subject: [linux-audio-dev] Todays "LADSPA2" update In-Reply-To: <1146063746.10856.9.camel@DaveLap> References: <20060426105144.GF21022@login.ecs.soton.ac.uk> <1146049520.16871.5.camel@localhost.localdomain> <1146063746.10856.9.camel@DaveLap> Message-ID: <20060426165245.GN21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 11:02:26AM -0400, Dave Robillard wrote: > Specifying the base along with it would be a very good idea though. > Better to have a 'logarithmic' hint and a seperate 'log_base' though. Do the maths on that. - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 12:55:38 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 12:55:59 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <958b3a2e0604260948n241c493dra84179619391eca7@mail.gmail.com> References: <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> <20060426145627.GK21022@login.ecs.soton.ac.uk> <958b3a2e0604260948n241c493dra84179619391eca7@mail.gmail.com> Message-ID: <20060426165537.GO21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote: > > That's somewhat like saying a corrupt binary > > should never cause a segfault... > No, not at all. > The data file is accessed as an input stream (to the host / LADSPA library). > It's fine for a bad data file to cause the library to fail to be able > to load it, or to load it and produce unexpected output, but it should > *never* cause it to segfault. the only situation it can cause a segfault is where its mangled in a somehow still structurally and syntaxically correct way (too unlikly to be worth considering) or if the host pushes on without enough information. The point I was making is that you will get segfaults if you try to us the struct without the data, even if you know the version number, so dont. > All I'm saying is that if the discovery function may potentially > return differing structs from one LADSPA version to another, then it > ought also provide a mechanism of determining exactly which struct it > is returning. Sure, but its easier to version the struct in the data. - Steve From drobilla at connect.carleton.ca Wed Apr 26 13:14:06 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 13:13:49 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426165537.GO21022@login.ecs.soton.ac.uk> References: <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> <20060426145627.GK21022@login.ecs.soton.ac.uk> <958b3a2e0604260948n241c493dra84179619391eca7@mail.gmail.com> <20060426165537.GO21022@login.ecs.soton.ac.uk> Message-ID: <1146071646.10856.32.camel@DaveLap> On Wed, 2006-04-26 at 17:55 +0100, Steve Harris wrote: > On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote: > > > That's somewhat like saying a corrupt binary > > > should never cause a segfault... > > No, not at all. > > The data file is accessed as an input stream (to the host / LADSPA library). > > It's fine for a bad data file to cause the library to fail to be able > > to load it, or to load it and produce unexpected output, but it should > > *never* cause it to segfault. > > the only situation it can cause a segfault is where its mangled in a > somehow still structurally and syntaxically correct way (too unlikly to be > worth considering) or if the host pushes on without enough information. > > The point I was making is that you will get segfaults if you try to us the > struct without the data, even if you know the version number, so dont. > > > All I'm saying is that if the discovery function may potentially > > return differing structs from one LADSPA version to another, then it > > ought also provide a mechanism of determining exactly which struct it > > is returning. > > Sure, but its easier to version the struct in the data. Thinking about this I was worried about parallel installed multiple versions of the same plugin, but as long as the URI refers to a compatible version of the plugin, we don't need versioning in the struct itself, since the URI between two versions of a plugin (one of which is LADSPA2.0 and one which is binary incompatible LADSPA2.2 or whatever) must change since it's incompatible, right? We need to make absolutely sure multiple versions of a plugin can be installed at once, including new incompatible versions of the spec, is my point. I /think/ it's okay as stands though. -DR- From paniq at paniq.org Wed Apr 26 14:04:35 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Apr 26 13:53:35 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426054832.GB21022@login.ecs.soton.ac.uk> References: <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <20060426054832.GB21022@login.ecs.soton.ac.uk> Message-ID: <1146074675.14289.112.camel@localhost> On Wed, 2006-04-26 at 06:48 +0100, Steve Harris wrote: > > if it never refuses then its ok with me ;) > > It's certainly allowed to refuse, it would just be bad manners, unless the > host has ignored the required features list. so required features have to be checked on both sides. isn't that redundant? furthermore, surely there are other reasons why instantiation could fail. how can the host determine the reason for which a plugin refused to instantiate? > > thats platform specific though, seems like the plugins shouldn't be full > of #ifdef WIN32 ... code. yes, of course, that would be nonsense. but in case there is a posix equivalent, it will be available on win32 as well. but i dont know anything more about this. > > > alternatively the host could be required to chdir to the bundle folder > > before the plugin is being instantiated? > > Thats likely to cause all manner of excitement. the erotic kind of excitement? ;) -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From paniq at paniq.org Wed Apr 26 14:09:26 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Apr 26 13:58:25 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146039001.444f2ada06a6d@www1.helsinki.fi> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> Message-ID: <1146074966.14289.117.camel@localhost> On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: > I think we would select a short name anyway. Most of them are gone already, > so we have the same problem whichever [a-z][a-z][a-z] we select :) XAP suggests this could be an XML document type. what about FAP (FAP Audio Plugin)? GO FAP! FAP FAP FAP! i also would like CLAP. :) > -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From drobilla at connect.carleton.ca Wed Apr 26 14:03:38 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 14:03:21 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146074966.14289.117.camel@localhost> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> Message-ID: <1146074618.10856.37.camel@DaveLap> On Wed, 2006-04-26 at 20:09 +0200, Leonard "paniq" Ritter wrote: > On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: > > I think we would select a short name anyway. Most of them are gone already, > > so we have the same problem whichever [a-z][a-z][a-z] we select :) > > > XAP suggests this could be an XML document type. what about FAP (FAP > Audio Plugin)? RAP - Recursively Acronym'd Plugin -DR- From paniq at paniq.org Wed Apr 26 14:15:04 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Apr 26 14:04:28 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426145627.GK21022@login.ecs.soton.ac.uk> References: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> <20060426145627.GK21022@login.ecs.soton.ac.uk> Message-ID: <1146075304.14289.121.camel@localhost> On Wed, 2006-04-26 at 15:56 +0100, Steve Harris wrote: > That's somewhat like saying a corrupt binary should never cause a > segfault... if the data file gets corrupted in a way that breaks the > syntax, then there wont be enouhg data for hte host to attempt to load the > plugin and it will refuse, but if through some miracle > ladspa:InputControPort becomes ladspa:OutputControlPort then all kinds of > crazy shit will go down. segfaults will only be ok as long as there are no security advisories. beware the rdf exploits. :) -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From drobilla at connect.carleton.ca Wed Apr 26 14:05:20 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 14:05:40 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146074675.14289.112.camel@localhost> References: <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <20060426054832.GB21022@login.ecs.soton.ac.uk> <1146074675.14289.112.camel@localhost> Message-ID: <1146074720.10856.40.camel@DaveLap> On Wed, 2006-04-26 at 20:04 +0200, Leonard "paniq" Ritter wrote: > On Wed, 2006-04-26 at 06:48 +0100, Steve Harris wrote: > > > if it never refuses then its ok with me ;) > > > > It's certainly allowed to refuse, it would just be bad manners, unless the > > host has ignored the required features list. > > so required features have to be checked on both sides. isn't that > redundant? The plugin (obviously) needs to check the features anyway, since it needs to (or may want to) use them. Can't use something if you don't even know if it's there. -DR- From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 14:06:01 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 14:07:03 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146064693.10856.25.camel@DaveLap> References: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <1146064693.10856.25.camel@DaveLap> Message-ID: <20060426180601.GP21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave Robillard wrote: > On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote: > > This is why the "plugin" is really a directory, all the stuff in there is > > neccesary. > > On the plugin bundle thing, I've got working C code that takes a path to > the directory, parses manifest.ttl, gleams the available plugin DLLs and > data files from that, and enumerates all the plugins in the DLL. It shouldn't be neccesary to actually dlload() the .so file, if it is then theres a mistake somewhere. > We need to clarify some things about bundles themselves: > > - What is the significance of the bundle name itself? (We need to avoid > clashes somehow) Yes, its a bit awkward. It would be nice to be able to use URIs, but thats not going to wash. I was planning something like [abbreviated plugin name]-[collection name].whatever/ eg. Amp-swh.ladspa2 Assuming the number of collections doesnt grow to much, the current thing of people using thier initials or similar should work fine. The maintainer of each colleaction is responsible for making sure noone else uses the same collection name, and that none of thier abbreviated names collide. If we wanted to go overboard we could do something like [abbreviated plugin name]-[64bit hash of URI of one plugin].whatever/ eg. amp-5491370f050fa849.ladspa2/ which guarantees uniqueness, but its a bit of a pain, and the plugin bundle names will be a bit ugly. > - Do they contain one plugin variant, or any number? Probably leave it as a matter of taste. Though discouraging the cmt thing is a good idea IMHO. > - One DLL or many? As many as you want / need. > I'm not sure about number-of-plugins-per-bundle (though putting all of, > say, swh-plugins in one bundle seems counter to the intent to me?) but I > will suggest we reccommend that one DLL contains only variants of one > plugin (or a group of very similar plugins). Reasoning is to avoid > things like cmt.so which has a huge number of completely unrelated > plugins in one lib, meaning a host has to link in all that crap just to > use a simple amplifier plugin, which is no good. My intention was to have a pretty much 1:1 correspondance between .so's I have now and bundles in the future. ie. most plugins are on thier own, but logically grouped ones are in one .so. eg. a buch ov very similar oscialltors, filters etc. I dont think its neccesary to specify this though, the best natural level usually settles out. ie. people see cmt.so, and go "arrrghhh!". - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 14:08:26 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 14:08:49 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146074675.14289.112.camel@localhost> References: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <20060425220228.GS24930@login.ecs.soton.ac.uk> <1146004431.14289.42.camel@localhost> <20060426054832.GB21022@login.ecs.soton.ac.uk> <1146074675.14289.112.camel@localhost> Message-ID: <20060426180826.GQ21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 08:04:35PM +0200, Leonard paniq Ritter wrote: > On Wed, 2006-04-26 at 06:48 +0100, Steve Harris wrote: > > > if it never refuses then its ok with me ;) > > > > It's certainly allowed to refuse, it would just be bad manners, unless the > > host has ignored the required features list. > > so required features have to be checked on both sides. isn't that > redundant? SupportedFeatures is not just fo requirements. eg. Fon's plyphonic control ports can work around the case where the host doesnt support it. > furthermore, surely there are other reasons why instantiation could > fail. how can the host determine the reason for which a plugin refused > to instantiate? It can't. Meh. > > > alternatively the host could be required to chdir to the bundle folder > > > before the plugin is being instantiated? > > > > Thats likely to cause all manner of excitement. > > the erotic kind of excitement? ;) More the running around screaming kind ;) - Steve From luisgarrido at users.sourceforge.net Wed Apr 26 14:10:23 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Wed Apr 26 14:10:50 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <20060426164836.GL21022@login.ecs.soton.ac.uk> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146063313.10856.4.camel@DaveLap> <20060426164836.GL21022@login.ecs.soton.ac.uk> Message-ID: SAX? (Simple Audio eXtensions) Yup, it names also the XML parser, but it is music related. Incidentally, at some point in the near future it will be possible to register .ax domain names, don't know under which conditions. http://en.wikipedia.org/wiki/.ax CHAP? (Cunningly Hacked Audio Plugins) WASAP? (Widely Acknowledged Simple Audio Plugins) wasap.org is available. Cheers, Luis From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 14:13:23 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 14:13:40 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146074618.10856.37.camel@DaveLap> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> <1146074618.10856.37.camel@DaveLap> Message-ID: <20060426181323.GR21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 02:03:38PM -0400, Dave Robillard wrote: > On Wed, 2006-04-26 at 20:09 +0200, Leonard "paniq" Ritter wrote: > > On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: > > > I think we would select a short name anyway. Most of them are gone already, > > > so we have the same problem whichever [a-z][a-z][a-z] we select :) > > > > > > XAP suggests this could be an XML document type. what about FAP (FAP > > Audio Plugin)? > > RAP - Recursively Acronym'd Plugin Thats the kind of suggestion that makes non-free software developers think were all pissing about. But I still dont like it that much ;) EEP - Extensible Environment for Plugins? PEEP - Portable ... MEEP - Multiplatform ... Sadly BEEP has gone :( - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 14:14:47 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 14:15:18 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146074966.14289.117.camel@localhost> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> Message-ID: <20060426181446.GS21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 08:09:26PM +0200, Leonard paniq Ritter wrote: > On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: > > I think we would select a short name anyway. Most of them are gone already, > > so we have the same problem whichever [a-z][a-z][a-z] we select :) > > > XAP suggests this could be an XML document type. what about FAP (FAP > Audio Plugin)? > > GO FAP! FAP FAP FAP! Perhaps not. > i also would like CLAP. :) No, you wouldn't ;) - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 14:29:52 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 14:30:16 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146071646.10856.32.camel@DaveLap> References: <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <958b3a2e0604260454hc8d340dtac3591d38280c2b2@mail.gmail.com> <20060426145627.GK21022@login.ecs.soton.ac.uk> <958b3a2e0604260948n241c493dra84179619391eca7@mail.gmail.com> <20060426165537.GO21022@login.ecs.soton.ac.uk> <1146071646.10856.32.camel@DaveLap> Message-ID: <20060426182952.GT21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 01:14:06PM -0400, Dave Robillard wrote: > Thinking about this I was worried about parallel installed multiple > versions of the same plugin, but as long as the URI refers to a > compatible version of the plugin, we don't need versioning in the struct > itself, since the URI between two versions of a plugin (one of which is > LADSPA2.0 and one which is binary incompatible LADSPA2.2 or whatever) > must change since it's incompatible, right? Yes, the URI changes whenever the effective ABI changes, ie add, remove or change semantics of ports, or new struct ABI. > We need to make absolutely sure multiple versions of a plugin can be > installed at once, including new incompatible versions of the spec, is > my point. I /think/ it's okay as stands though. Yes, you just need to make sure the URIs and and bundle names change as appropriate. - Steve From capocasa at gmx.net Wed Apr 26 14:29:52 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Wed Apr 26 14:30:29 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <20060426062348.GC21022@login.ecs.soton.ac.uk> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> Message-ID: Thanks for putting in all the effort with LADSPA! I am, through Om, also a big user. I'll go very simple and broad here and suggest 'APA', standing for 'Audio Plugin Architecture'. + Aypeeay has a nice sound to it + The name is forwards compatible with being ported to Windows, Mac, or even becoming a de-facto or ISO standard for cross-platform audio processing. + The name does not cause brain-overload + The name sounds technical enough to be recognized as such by ordinary users but is simple enough to be used in communication + It can be typed with alternating hands which makes typing it often faster + It is fairly obvious how to pronounce it - There might be the occasional joke about the American Psychological Association, the American Philosophical Association, or the American Psychiatrical Association - There are several European companies using the acronym as their name Carlo From larsl at users.sourceforge.net Wed Apr 26 14:33:42 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed Apr 26 14:34:18 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: References: <20060426062348.GC21022@login.ecs.soton.ac.uk> Message-ID: <1146076422.29691.1.camel@localhost> On Wed, 2006-04-26 at 20:29 +0200, Carlo Capocasa wrote: > Thanks for putting in all the effort with LADSPA! I am, through Om, also > a big user. > > I'll go very simple and broad here and suggest 'APA', standing for > 'Audio Plugin Architecture'. This has the additional benefit that 'apa' means 'ape' or 'monkey' in swedish. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060426/da0897a8/attachment.bin From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 14:38:08 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 14:38:29 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146063313.10856.4.camel@DaveLap> <20060426164836.GL21022@login.ecs.soton.ac.uk> Message-ID: <20060426183808.GU21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 08:10:23PM +0200, Luis Garrido wrote: > SAX? (Simple Audio eXtensions) Yup, it names also the XML parser, but > it is music related. Incidentally, at some point in the near future it > will be possible to register .ax domain names, don't know under which > conditions. I quite like that. Not too keen on Simple, but SAX is a good TLA. Software Audio eXtensions? > http://en.wikipedia.org/wiki/.ax Doesn't look like .ax domains are open to non-residents. There are other things we can get though. - Steve From S.W.Harris at ecs.soton.ac.uk Wed Apr 26 14:39:40 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Apr 26 14:40:06 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <1146076422.29691.1.camel@localhost> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146076422.29691.1.camel@localhost> Message-ID: <20060426183940.GV21022@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 08:33:42PM +0200, Lars Luthman wrote: > On Wed, 2006-04-26 at 20:29 +0200, Carlo Capocasa wrote: > > Thanks for putting in all the effort with LADSPA! I am, through Om, also > > a big user. > > > > I'll go very simple and broad here and suggest 'APA', standing for > > 'Audio Plugin Architecture'. > > This has the additional benefit that 'apa' means 'ape' or 'monkey' in > swedish. Now, APE would be pretty cool. Audio Plugin Extenstions? - Steve From t_w_ at freenet.de Wed Apr 26 14:52:05 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Wed Apr 26 14:52:12 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <20060426183940.GV21022@login.ecs.soton.ac.uk> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146076422.29691.1.camel@localhost> <20060426183940.GV21022@login.ecs.soton.ac.uk> Message-ID: <20060426185205.GA19139@charly.SWORD> On Wed, Apr 26, 2006 at 07:39:40PM +0100, Steve Harris wrote: > > This has the additional benefit that 'apa' means 'ape' or 'monkey' in > > swedish. > > Now, APE would be pretty cool. > > Audio Plugin Extenstions? Hhmm, Audio Plugin Excellence Audio Plugins Extraordinary *shrug* Cheers, Thorsten Wilms From drobilla at connect.carleton.ca Wed Apr 26 14:53:05 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 14:53:30 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060426180601.GP21022@login.ecs.soton.ac.uk> References: <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <958b3a2e0604250940w4521e923m92951419e60edf97@mail.gmail.com> <20060425213728.GQ24930@login.ecs.soton.ac.uk> <958b3a2e0604260148s1f5c6e76l6b3c2017dd8bb7e2@mail.gmail.com> <20060426093850.GE21022@login.ecs.soton.ac.uk> <1146064693.10856.25.camel@DaveLap> <20060426180601.GP21022@login.ecs.soton.ac.uk> Message-ID: <1146077586.10856.64.camel@DaveLap> On Wed, 2006-04-26 at 19:06 +0100, Steve Harris wrote: > On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave Robillard wrote: > > On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote: > > > This is why the "plugin" is really a directory, all the stuff in there is > > > neccesary. > > > > On the plugin bundle thing, I've got working C code that takes a path to > > the directory, parses manifest.ttl, gleams the available plugin DLLs and > > data files from that, and enumerates all the plugins in the DLL. > > It shouldn't be neccesary to actually dlload() the .so file, if it is then > theres a mistake somewhere. Sorry, to be clearer loading the DLL was my goal (not the means towards enumerating the available plugins). Enumerating what indexes ladspa_descriptor returns is just what I happened to write to be sure I really did load the DLL successfully. > > We need to clarify some things about bundles themselves: > > > > - What is the significance of the bundle name itself? (We need to avoid > > clashes somehow) > > Yes, its a bit awkward. It would be nice to be able to use URIs, but thats > not going to wash. > > I was planning something like > [abbreviated plugin name]-[collection name].whatever/ > eg. Amp-swh.ladspa2 > Assuming the number of collections doesnt grow to much, the current thing > of people using thier initials or similar should work fine. The maintainer > of each colleaction is responsible for making sure noone else uses the > same collection name, and that none of thier abbreviated names collide. > > If we wanted to go overboard we could do something like > [abbreviated plugin name]-[64bit hash of URI of one plugin].whatever/ > eg. amp-5491370f050fa849.ladspa2/ > which guarantees uniqueness, but its a bit of a pain, and the plugin bundle > names will be a bit ugly. That is overboard, but I guess there's no real good solution to this that doesn't involve having a URI of some variety as the name, which is far too ugly. We do need to prevent people from doing stupid things like calling the directory "amp" though, so at least a recommendation in the spec is in order. > > - Do they contain one plugin variant, or any number? > > Probably leave it as a matter of taste. Though discouraging the cmt thing > is a good idea IMHO. > > > - One DLL or many? > > As many as you want / need. > > > I'm not sure about number-of-plugins-per-bundle (though putting all of, > > say, swh-plugins in one bundle seems counter to the intent to me?) but I > > will suggest we reccommend that one DLL contains only variants of one > > plugin (or a group of very similar plugins). Reasoning is to avoid > > things like cmt.so which has a huge number of completely unrelated > > plugins in one lib, meaning a host has to link in all that crap just to > > use a simple amplifier plugin, which is no good. > > My intention was to have a pretty much 1:1 correspondance between .so's I > have now and bundles in the future. ie. most plugins are on thier own, but > logically grouped ones are in one .so. eg. a buch ov very similar > oscialltors, filters etc. The way your plugins are divvied up is fine, but: > I dont think its neccesary to specify this though, the best natural level > usually settles out. ie. people see cmt.so, and go "arrrghhh!". They go arrrrggghhh, but cmt.so remains with no settling in sight :) I guess in the interests of defining as little as neccessary, it should go unspecified (though as above a recommendation would be good). Large bundles are okay because they ease the burden on the user, but I don't see any benefit of a huge chunk of completely unrelated plugins being in one .so As long as we have this nice bundle format, I suppose both a LADSPA repo site and a 'master package' of all LADSPA plugins can exist (both things that are requested pretty often), though they would only be able to usefully distribute binary builds, not source. :/ This is why I'm tempted to suggest that a bundle only contains related plugins, so a user could easily just install the SWH amp (say on a resource limited system). There's a lot of plugins out there that are totally useless for some people, it would be nice if /users/ could decide what plugins they want installed. But then of course the directory name problem becomes a bigger one that'd need to be solved properly.. -DR- From drobilla at connect.carleton.ca Wed Apr 26 14:58:12 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 14:58:08 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <20060426181323.GR21022@login.ecs.soton.ac.uk> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> <1146074618.10856.37.camel@DaveLap> <20060426181323.GR21022@login.ecs.soton.ac.uk> Message-ID: <1146077892.10856.70.camel@DaveLap> On Wed, 2006-04-26 at 19:13 +0100, Steve Harris wrote: > On Wed, Apr 26, 2006 at 02:03:38PM -0400, Dave Robillard wrote: > > On Wed, 2006-04-26 at 20:09 +0200, Leonard "paniq" Ritter wrote: > > > On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: > > > > I think we would select a short name anyway. Most of them are gone already, > > > > so we have the same problem whichever [a-z][a-z][a-z] we select :) > > > > > > > > > XAP suggests this could be an XML document type. what about FAP (FAP > > > Audio Plugin)? > > > > RAP - Recursively Acronym'd Plugin > > Thats the kind of suggestion that makes non-free software developers think > were all pissing about. That's a good thing, right? > EEP - Extensible Environment for Plugins? > PEEP - Portable ... > MEEP - Multiplatform ... PEEP - Palindromic Extensible Environment for Plugins :) -DR- From luisgarrido at users.sourceforge.net Wed Apr 26 15:10:50 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Wed Apr 26 15:10:59 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146077892.10856.70.camel@DaveLap> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> <1146074618.10856.37.camel@DaveLap> <20060426181323.GR21022@login.ecs.soton.ac.uk> <1146077892.10856.70.camel@DaveLap> Message-ID: SAX: Sexy Audio eXtensions (or just make it recursive (TM)) APE: Audio Pluggable Extensions (not my favorite: there is already an important audio application that uses the term and I cringe thinking of the simian lingo that is going to develop around it, but well...) PEA: Pluggable Extensions for Audio. Luis From drobilla at connect.carleton.ca Wed Apr 26 15:18:41 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 15:18:23 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <20060426183940.GV21022@login.ecs.soton.ac.uk> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146076422.29691.1.camel@localhost> <20060426183940.GV21022@login.ecs.soton.ac.uk> Message-ID: <1146079121.10856.77.camel@DaveLap> On Wed, 2006-04-26 at 19:39 +0100, Steve Harris wrote: > On Wed, Apr 26, 2006 at 08:33:42PM +0200, Lars Luthman wrote: > > On Wed, 2006-04-26 at 20:29 +0200, Carlo Capocasa wrote: > > > Thanks for putting in all the effort with LADSPA! I am, through Om, also > > > a big user. > > > > > > I'll go very simple and broad here and suggest 'APA', standing for > > > 'Audio Plugin Architecture'. > > > > This has the additional benefit that 'apa' means 'ape' or 'monkey' in > > swedish. > > Now, APE would be pretty cool. > > Audio Plugin Extenstions? http://www.monkeysaudio.com/ File extension: .ape -DR- From drobilla at connect.carleton.ca Wed Apr 26 15:41:39 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Apr 26 15:41:24 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146077892.10856.70.camel@DaveLap> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> <1146074618.10856.37.camel@DaveLap> <20060426181323.GR21022@login.ecs.soton.ac.uk> <1146077892.10856.70.camel@DaveLap> Message-ID: <1146080499.11718.0.camel@DaveLap> On Wed, 2006-04-26 at 14:58 -0400, Dave Robillard wrote: > PEEP - Palindromic Extensible Environment for Plugins or PEEPER Extensible Environment for Plugins, Entitled Recursively 10 points to anyone who can fit both Palindromic and Recursive in there. ;) -DR- From indigo at bitglue.com Wed Apr 26 16:07:05 2006 From: indigo at bitglue.com (Phil Frost) Date: Wed Apr 26 16:07:18 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <20060426181323.GR21022@login.ecs.soton.ac.uk> References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> <1146074618.10856.37.camel@DaveLap> <20060426181323.GR21022@login.ecs.soton.ac.uk> Message-ID: <20060426200704.GA25554@unununium.org> On Wed, Apr 26, 2006 at 07:13:23PM +0100, Steve Harris wrote: > Thats the kind of suggestion that makes non-free software developers think > were all pissing about. > > But I still dont like it that much ;) > > EEP - Extensible Environment for Plugins? > PEEP - Portable ... > MEEP - Multiplatform ... > > Sadly BEEP has gone :( > > - Steve I already have a linux audio project going with a friend called "meep". You can't have it ;) From jens.andreasen at chello.se Wed Apr 26 16:29:16 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Apr 26 16:29:26 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <20060426164836.GL21022@login.ecs.soton.ac.uk> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146063313.10856.4.camel@DaveLap> <20060426164836.GL21022@login.ecs.soton.ac.uk> Message-ID: <1146083357.25180.75.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-04-26 at 17:48 +0100, Steve Harris wrote: > > Then again, domains aren't free, and I know I'm not paying for it. :) > > If we can find one thats not too expensive I'll pick up the tab. > > - Steve If you can put up with not beeing the root domain, you could get somthing like [ladspa|xap|apa].linux.dk for free -- mvh // Jens M Andreasen From kjetil at ccrma.stanford.edu Wed Apr 26 16:30:24 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Wed Apr 26 16:30:50 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <20060426081018.0528612E8FE0@music.columbia.edu> References: <20060426081018.0528612E8FE0@music.columbia.edu> Message-ID: Steve Harris: > > Several people have suggested that LADSPA is not a great name for what we > are calling LADSPA 2. Reasons for this include: > > The L, it's not really linux specific, and though /we/ know that its the L > of LAD, its not obvious to people outside. > > The S, it ain't really going to be simple. For someone like me, who is > neck deep in triples on a daily basis, 2.0 seems like the paragon of > simplicity, but I can imagine 2.9 being quite a beast. > > LADSPA, (pron. ladspuh?) is a bit of a mouthful, and not exactly catchy. > > 2.0, it's not going to be obvious to all users that 2.0 and 1.0 are binary > incompatible. I'm not sure everyone thinks in major and minor revisions. > > So, with some trepidation I suggest that we think about naming, with the > proviso that if we haven't reached consensus by May 10th we default to > LADSPA 2.0, and live with the pain. > I don't agree about taking away the "L". Ladspa is not linux-specific, but it has certainly originated from linux, and has the best support in linux software. If linux dissapears before the ladspa format, we can at least still remember linux through the name of ladspa... Regarding your argumentation about the prononounciation, I think its a bit anglocentric language-vice. In most other countries (scandinavian, german, spanish, belgian, dutch, slavic (I might be wrong about some of these though)), where the "a" is actually pronounced like the round "ah" (and very short in this case), and you don't have to move the mouth that much as in english (and especially in american english), "ladspa" sounds really cool and is not very difficult to say. A good solution to this problem would be if the english speakers started to allways say the more common rounder "ah" instead of "a", not only for ladspa, but for all acronyms. I think the argument about S is valid enough though, but not a good enough argument to change a name we all have learned and love(?). As an alternative, we can change the meaning of s into something else, like Super, Second, Sophisticated, System, Steve, Sourcecode, Syntax, Structure, Success, Superb, Superior. To name a few, well, I'm sure there are better alternatives. > ---- > > My suggestion is that we ressurect the XAP name > (http://www.google.com/search?q=lad+xap) > It stood for Xap Audio Plugin IIRC. > > Pros: it's short*, relatively unused** and pronouncable*** > > Cons: xap.{com,org,net} will have gone long ago (too short), theres a > small ammount of baggage. > I think its too short. Its not cool, and its hard to remember from the pronounciation. From paniq at paniq.org Wed Apr 26 17:25:39 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Apr 26 17:13:58 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: References: <20060426081018.0528612E8FE0@music.columbia.edu> Message-ID: <1146086739.14289.128.camel@localhost> On Wed, 2006-04-26 at 13:30 -0700, Kjetil S. Matheussen wrote: > I think the argument about S is valid enough though, but not a good enough > argument to change a name we all have learned and love(?). As an > alternative, we can change the meaning of s into something else, like > Super, Second, Sophisticated, System, Steve, Sourcecode, Syntax, > Structure, Success, Superb, Superior. To name a few, well, I'm sure there > are better alternatives. What about SHAG: Steve Harris' Audio Gear -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From pshirkey at boosthardware.com Wed Apr 26 17:55:22 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Wed Apr 26 17:56:21 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <1146086739.14289.128.camel@localhost> References: <20060426081018.0528612E8FE0@music.columbia.edu> <1146086739.14289.128.camel@localhost> Message-ID: <444FEC4A.6020504@boosthardware.com> Leonard "paniq" Ritter wrote: > > What about SHAG: Steve Harris' Audio Gear > LAP - Linux Audio Plugin LDP - Linux Digital Plugin LFX - Linux FX LPA - Linux Plugin API PLA - Plugin for Linux Audio SLAP - Simpler Linux Audio Plugin -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From nettings at folkwang-hochschule.de Wed Apr 26 18:11:09 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Wed Apr 26 18:09:43 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAC 2006 Live Streams In-Reply-To: <20060426135602.GB23578@falcon.fugal.net> References: <444E9AD3.2050802@folkwang-hochschule.de> <20060426135602.GB23578@falcon.fugal.net> Message-ID: <444FEFFD.3040108@folkwang-hochschule.de> Hans Fugal wrote: > That sounds great! Will these also be available for download afterwards? > yes, if all goes well. we will not have time to edit them, but if someone volunteers, we can upload the raw dumps immediately after they are done, in 30min chunks. any takers? j?rn From ce at christeck.de Wed Apr 26 18:26:56 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Apr 26 18:26:14 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAC 2006 Live Streams In-Reply-To: <444FEFFD.3040108@folkwang-hochschule.de> References: <444E9AD3.2050802@folkwang-hochschule.de> <20060426135602.GB23578@falcon.fugal.net> <444FEFFD.3040108@folkwang-hochschule.de> Message-ID: <200604270026.57009.ce@christeck.de> > yes, if all goes well. we will not have time to edit them, but if > someone volunteers, we can upload the raw dumps immediately after > they are done, in 30min chunks. any takers? any chance to cut them by talk? How difficult is it to do? Can it be done after the conference or is there need to do it timely? And no, I did not volunteer (yet ;-) . Best regards ce From paniq at paniq.org Wed Apr 26 19:21:39 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Apr 26 19:09:38 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <444FEC4A.6020504@boosthardware.com> References: <20060426081018.0528612E8FE0@music.columbia.edu> <1146086739.14289.128.camel@localhost> <444FEC4A.6020504@boosthardware.com> Message-ID: <1146093700.14289.130.camel@localhost> On Thu, 2006-04-27 at 04:55 +0700, Patrick Shirkey wrote: > Leonard "paniq" Ritter wrote: > > > > > What about SHAG: Steve Harris' Audio Gear > > actually, now that i think about it "AudioGear" would be a fancy name, no? > -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From paniq at paniq.org Wed Apr 26 19:21:57 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Apr 26 19:10:02 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <444FEC4A.6020504@boosthardware.com> References: <20060426081018.0528612E8FE0@music.columbia.edu> <1146086739.14289.128.camel@localhost> <444FEC4A.6020504@boosthardware.com> Message-ID: <1146093717.14289.132.camel@localhost> On Thu, 2006-04-27 at 04:55 +0700, Patrick Shirkey wrote: > SLAP - Simpler Linux Audio Plugin i like that :D > -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From drunkenbird at gmail.com Wed Apr 26 19:17:56 2006 From: drunkenbird at gmail.com (grae) Date: Wed Apr 26 19:18:04 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <444FEC4A.6020504@boosthardware.com> References: <20060426081018.0528612E8FE0@music.columbia.edu> <1146086739.14289.128.camel@localhost> <444FEC4A.6020504@boosthardware.com> Message-ID: <73802df70604261617o44d0a20co7a93d2aa39a19b41@mail.gmail.com> Whatever the name ends up being, I'd really encourage that it be extremely unique. When I search for LADSPA in google, I get LADSPA and nothing but LADSPA related results. Now that's beautiful and it'd be a real shame to lose that. If it were to change to LAP (just for example), then just do a google search for "lap" and compare the accuracy and you'll clearly see my point. In fact I encourage anyone when attempting a name out there to consider this aspect in naming as a number one priority. It's such a benefit for everyone. That's my 2 cents. :) grae On 4/26/06, Patrick Shirkey wrote: > Leonard "paniq" Ritter wrote: > > > > > What about SHAG: Steve Harris' Audio Gear > > > > LAP - Linux Audio Plugin > LDP - Linux Digital Plugin > LFX - Linux FX > LPA - Linux Plugin API > > PLA - Plugin for Linux Audio > > SLAP - Simpler Linux Audio Plugin > > > > > > -- > Patrick Shirkey - Boost Hardware Ltd. > Http://www.boosthardware.com > Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide > ======================================== > > "Anything your mind can see you can manifest physically, then it will > become reality" - Macka B > > From b0ef at esben-stien.name Wed Apr 26 21:48:27 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed Apr 26 19:50:08 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146077892.10856.70.camel@DaveLap> (Dave Robillard's message of "Wed, 26 Apr 2006 14:58:12 -0400") References: <1146039001.444f2ada06a6d@www1.helsinki.fi> <1146074966.14289.117.camel@localhost> <1146074618.10856.37.camel@DaveLap> <20060426181323.GR21022@login.ecs.soton.ac.uk> <1146077892.10856.70.camel@DaveLap> Message-ID: <87slnz4wlw.fsf@esben-stien.name> Dave Robillard writes: > PEEP - Palindromic Extensible Environment for Plugins This is a very good one;). PEEP Extensible Environment for Plugins -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From jwoithe at physics.adelaide.edu.au Wed Apr 26 21:43:32 2006 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Wed Apr 26 21:41:21 2006 Subject: [linux-audio-dev] Trouble compiling cheesetracker in Slackware 10.2 Message-ID: <200604270143.k3R1hWt0027344@auster.physics.adelaide.edu.au> Blaze Monger wrote: > I have SCONS installed and when i type scons, it gives me this: > > Checking for libsigc++-1.2... > Package sigc++-1.2 was not found in the pkg-config search path. > Perhaps you should add the directory containing `sigc++-1.2.pc' > to the PKG_CONFIG_PATH environment variable > No package 'sigc++-1.2' found > > I've been trying to build this for hours and I can't find sigc++1.2.pc > anywhere. Slackware 10.2 doesn't come with sigc++. You will have to get the source, compile and install it before attempting to compile anything that uses it, such as cheesetracker. It's not hard though - sigc++ compiles and installs cleanly under Slackware 10.2 (for me at least) using the normal ./configure make make install process. Regards jonathan From taybin at earthlink.net Wed Apr 26 23:37:50 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Wed Apr 26 23:38:11 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: References: <20060426081018.0528612E8FE0@music.columbia.edu> Message-ID: On Apr 26, 2006, at 4:30 PM, Kjetil S. Matheussen wrote: > I don't agree about taking away the "L". Ladspa is not linux- > specific, but it has certainly originated from linux, and has the > best support in linux software. If linux dissapears before the > ladspa format, we can at least still remember linux through the > name of ladspa... It might be a little too early to plan for linux's departure from the computing scene. Besides, if ladspa is still around after linux has left the building, that just shows it shouldn't have been in the name. > Regarding your argumentation about the prononounciation, I think > its a bit > anglocentric language-vice. In most other countries (scandinavian, > german, spanish, belgian, dutch, slavic (I might be wrong about > some of these though)), where the "a" is actually pronounced like > the round "ah" (and very short in this case), and you don't have to > move the mouth that much as in english (and especially in american > english), "ladspa" sounds really cool and is not very difficult to > say. A good solution to this problem would be if the english > speakers started to allways say the more common rounder "ah" > instead of "a", not only for ladspa, but for all acronyms. I don't think that changing the english rules of pronunciation is a good solution. "no no, it's pronounced 'lad-spah'." "why?" "it sounds cooler with a european accent" Taybin From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 01:00:30 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 01:00:48 2006 Subject: [linux-audio-dev] "LADSPA 2" name In-Reply-To: <1146083357.25180.75.camel@c80-216-124-251.cm-upc.chello.se> References: <20060426062348.GC21022@login.ecs.soton.ac.uk> <1146063313.10856.4.camel@DaveLap> <20060426164836.GL21022@login.ecs.soton.ac.uk> <1146083357.25180.75.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060427050030.GA21744@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 10:29:16 +0200, Jens M Andreasen wrote: > On Wed, 2006-04-26 at 17:48 +0100, Steve Harris wrote: > > > > Then again, domains aren't free, and I know I'm not paying for it. :) > > > > If we can find one thats not too expensive I'll pick up the tab. > > > > - Steve > > If you can put up with not beeing the root domain, you could get > somthing like [ladspa|xap|apa].linux.dk for free Thanks, but, I'll register something under a TLD, I have some ideas... the thing I really want is for sale, but they want EUR10,000, which is too much. FWIW, my current favourite is SAX. Musical connotations, short, name collisions not too serious. - Steve From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 01:02:52 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 01:03:09 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <1146093700.14289.130.camel@localhost> References: <20060426081018.0528612E8FE0@music.columbia.edu> <1146086739.14289.128.camel@localhost> <444FEC4A.6020504@boosthardware.com> <1146093700.14289.130.camel@localhost> Message-ID: <20060427050252.GB21744@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 01:21:39 +0200, Leonard paniq Ritter wrote: > On Thu, 2006-04-27 at 04:55 +0700, Patrick Shirkey wrote: > > Leonard "paniq" Ritter wrote: > > > > > > > > What about SHAG: Steve Harris' Audio Gear > > > > > actually, now that i think about it "AudioGear" would be a fancy name, > no? Yes, but sounds a bit fruit flavoured to me, too close to AudioUnit. On the wordy front we could have FreePlug/OpenPlug or something, but its bit dull. - Steve From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 01:09:54 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 01:10:13 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: References: <20060426081018.0528612E8FE0@music.columbia.edu> Message-ID: <20060427050954.GC21744@login.ecs.soton.ac.uk> On Wed, Apr 26, 2006 at 11:37:50 -0400, Taybin Rutkin wrote: > I don't think that changing the english rules of pronunciation is a > good solution. > > "no no, it's pronounced 'lad-spah'." > "why?" > "it sounds cooler with a european accent" I've met many europeans who pronounce it L-A-D-S-P-A, using local letter pronunciations ("el ay dee ess pee ay" in en-gb), which is not only time consuming, it actually takes me a few moments to work out what they thier referring to. - Steve From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 04:45:30 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 04:46:36 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman Message-ID: <20060427084530.GE21744@login.ecs.soton.ac.uk> http://plugin.org.uk/ladspa2/ Removed the :logarithmic hint, I agree with Paul, its not fit-for-purpose as specified. I'm now using the DOAP schema (http://usefulinc.com/doap) instead of Dublin Core for software information, much more appropriate. Fixed a load of typos in the schema and examples. Dave R. doxygen-ised the .h and added some text about choosing URIs. I removed the references to run_adding() (I think I got them all). - Steve From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 05:02:20 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 05:02:38 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? Message-ID: <20060427090220.GF21744@login.ecs.soton.ac.uk> Discusson seems to have slowwed down a bit, so I went through the list archive and pulled out all the names: apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap ---- I vetoed ape and meep as the name clashes are too close. To see if theres early consensus lets run a condorcet vote on the options. If everyone posts thier preference in order seperated by >, eg. foo>bar>baz means "I'd like foo, but if I cant have that I'l have bar, and if I cant have that I'l have baz, everything else is unacceptable". Then we can run it thorugh an online voting system. - Steve From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 05:06:40 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 05:06:58 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <20060427090640.GG21744@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 10:02:20 +0100, Steve Harris wrote: > Discusson seems to have slowwed down a bit, so I went through the list > archive and pulled out all the names: > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > ---- My vote is: sax>eep>xap - Steve From drobilla at connect.carleton.ca Thu Apr 27 05:13:24 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu Apr 27 05:13:12 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060427084530.GE21744@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> Message-ID: <1146129205.27822.0.camel@DaveLap> On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote: > http://plugin.org.uk/ladspa2/ > > Removed the :logarithmic hint, I agree with Paul, its not > fit-for-purpose as specified. er, I need logarithmic. if it's not fit-for-purpose as specified then we can specify it differently. it's in ladspa 1 :) -DR- From t_w_ at freenet.de Thu Apr 27 05:19:21 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Thu Apr 27 05:19:33 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <20060427091921.GA7364@charly.SWORD> On Thu, Apr 27, 2006 at 10:02:20AM +0100, Steve Harris wrote: > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > To see if theres early consensus lets run a condorcet vote on the options. > If everyone posts thier preference in order seperated by >, eg. > foo>bar>baz ladspa2>sap>xap>peep>peeper>sax>fap>eep>clap>chap>apa>rap>pea>wasap>rap everything but ladspa(2) is a google nightmare. Cheers, Thorsten Wilms From koloska at voiceinterconnect.de Thu Apr 27 05:26:49 2006 From: koloska at voiceinterconnect.de (Uwe Koloska) Date: Thu Apr 27 05:26:41 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <200604271126.49520.koloska@voiceinterconnect.de> Am Donnerstag, 27. April 2006 11:02 schrieb Steve Harris: > Discusson seems to have slowwed down a bit, so I went through the list > archive and pulled out all the names: > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap sax is the "Simple API fo XML" (despite all the other meanings wikipedia reports) Uwe From ild0012 at raven.londonmet.ac.uk Thu Apr 27 05:37:34 2006 From: ild0012 at raven.londonmet.ac.uk (ild0012@raven.londonmet.ac.uk) Date: Thu Apr 27 05:36:34 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <200604271126.49520.koloska@voiceinterconnect.de> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> Message-ID: <20060427093734.GA5461@raven.londonmet.ac.uk> > Am Donnerstag, 27. April 2006 11:02 schrieb Steve Harris: > > Discusson seems to have slowwed down a bit, so I went through the list > > archive and pulled out all the names: > > > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > sax is the "Simple API fo XML" (despite all the other meanings wikipedia > reports) > May be Plux ? say like plux is plugin llibrary > Uwe > From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 06:12:33 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 06:12:52 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146129205.27822.0.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> Message-ID: <20060427101233.GH21744@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 05:13:24 -0400, Dave Robillard wrote: > On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote: > > http://plugin.org.uk/ladspa2/ > > > > Removed the :logarithmic hint, I agree with Paul, its not > > fit-for-purpose as specified. > > er, I need logarithmic. if it's not fit-for-purpose as specified then > we can specify it differently. it's in ladspa 1 :) Yeah, but given that it doesn't work, I think its reasonable to remove it. We replace it with something that does work the moment after "LADSPA2" is finalised. - Steve From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 06:14:22 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 06:14:43 2006 Subject: [linux-audio-dev] Googlable "LADSPA2" names In-Reply-To: <20060427091921.GA7364@charly.SWORD> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <20060427091921.GA7364@charly.SWORD> Message-ID: <20060427101422.GI21744@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 11:19:21 +0200, Thorsten Wilms wrote: > On Thu, Apr 27, 2006 at 10:02:20AM +0100, Steve Harris wrote: > > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > > > To see if theres early consensus lets run a condorcet vote on the options. > > If everyone posts thier preference in order seperated by >, eg. > > foo>bar>baz > > ladspa2>sap>xap>peep>peeper>sax>fap>eep>clap>chap>apa>rap>pea>wasap>rap > > everything but ladspa(2) is a google nightmare. Yeah, but it wont be after we have some web presence. A slotdot post and mention in LWN is all it needs to be highly ranked in google. - Steve From S.W.Harris at ecs.soton.ac.uk Thu Apr 27 06:16:09 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Apr 27 06:16:29 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <20060427093734.GA5461@raven.londonmet.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> Message-ID: <20060427101609.GJ21744@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 10:37:34 +0100, ild0012@raven.londonmet.ac.uk wrote: > > Am Donnerstag, 27. April 2006 11:02 schrieb Steve Harris: > > > Discusson seems to have slowwed down a bit, so I went through the list > > > archive and pulled out all the names: > > > > > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > > > sax is the "Simple API fo XML" (despite all the other meanings wikipedia > > reports) > > > May be Plux ? say like plux is plugin llibrary If you want that to be considered, please post it to the naming thread, I wont be able to keep track otherwise. And in general, please keep this thread only for voting. - Steve From wingo at pobox.com Thu Apr 27 06:21:59 2006 From: wingo at pobox.com (Andy Wingo) Date: Thu Apr 27 06:22:10 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAC 2006 Live Streams In-Reply-To: <444FEFFD.3040108@folkwang-hochschule.de> References: <444E9AD3.2050802@folkwang-hochschule.de> <20060426135602.GB23578@falcon.fugal.net> <444FEFFD.3040108@folkwang-hochschule.de> Message-ID: <1146133319.12330.69.camel@localhost.localdomain> Hi Joern, On Thu, 2006-04-27 at 00:11 +0200, Joern Nettingsmeier wrote: > yes, if all goes well. we will not have time to edit them, but if > someone volunteers, we can upload the raw dumps immediately after they > are done, in 30min chunks. any takers? I've been working on a graphical lossless ogg/theora+vorbis cutter you might want to try out. It requires the latest GStreamer (core, plugins-base, and python -- all three to be released today). It's still smoking from leaving the emacs oven but I've been able to do some rough edits with it. It's examples/remuxer.py in gst-python CVS. Run as python remuxer.py file:///tmp/foo.ogg -- it will same to foo-remuxed.ogg in the same dir. Anyway, an option. Let me know how your experience is if you use it. Regards, -- Andy Wingo http://wingolog.org/ From seablaede at gmail.com Thu Apr 27 07:00:42 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Apr 27 06:57:06 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <20060427101609.GJ21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> Message-ID: <4450A45A.1040905@gmail.com> My vote is to keep LADSPA. I just dont see enough reason to change it. Seablade From dlphillips at woh.rr.com Thu Apr 27 07:06:03 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu Apr 27 07:04:17 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450A45A.1040905@gmail.com> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> Message-ID: <4450A59B.804@woh.rr.com> Thomas Vecchione wrote: > My vote is to keep LADSPA. I just dont see enough reason to change it. > > Seablade > Ditto. It's easily pronounceable. it has a high Google profile, and it's been in extensive use. OTOH, if it's not "simple" anymore I understand the need for a change. Best, dp From larsl at users.sourceforge.net Thu Apr 27 07:12:32 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Thu Apr 27 07:12:36 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450A45A.1040905@gmail.com> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> Message-ID: <1146136352.7953.2.camel@localhost> On Thu, 2006-04-27 at 07:00 -0400, Thomas Vecchione wrote: > My vote is to keep LADSPA. I just dont see enough reason to change it. Mine too. LADSPA>>>APA>SAX -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060427/7a06a414/attachment.bin From luisgarrido at users.sourceforge.net Thu Apr 27 07:14:09 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Thu Apr 27 07:14:21 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060427101233.GH21744@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> Message-ID: The RDF stuff is looking more and more arcane and hairy with each iteration, with all those colons, periods and quotes, plus some SQL'ish for good measure. Human readable? I begin to miss the syntactic simplicity of only using angled brackets in XML. Sigh, not another syntax to learn, please. Luis From larsl at users.sourceforge.net Thu Apr 27 07:14:13 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Thu Apr 27 07:14:33 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <1146136352.7953.2.camel@localhost> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <1146136352.7953.2.camel@localhost> Message-ID: <1146136453.7953.4.camel@localhost> On Thu, 2006-04-27 at 13:12 +0200, Lars Luthman wrote: > On Thu, 2006-04-27 at 07:00 -0400, Thomas Vecchione wrote: > > My vote is to keep LADSPA. I just dont see enough reason to change it. > > Mine too. > > LADSPA>>>APA>SAX And when I say LADSPA I mean LADSPA2, of course. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060427/938b3614/attachment.bin From loki.davison at gmail.com Thu Apr 27 07:14:58 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Apr 27 07:15:59 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: On 4/27/06, Steve Harris wrote: > Discusson seems to have slowwed down a bit, so I went through the list > archive and pulled out all the names: > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > ---- > > I vetoed ape and meep as the name clashes are too close. > > To see if theres early consensus lets run a condorcet vote on the options. > If everyone posts thier preference in order seperated by >, eg. > foo>bar>baz > means "I'd like foo, but if I cant have that I'l have bar, and if I cant > have that I'l have baz, everything else is unacceptable". Then we can run > it thorugh an online voting system. > > - Steve > xap > sax > peep > ladspa2 Loki From t_w_ at freenet.de Thu Apr 27 07:25:08 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Thu Apr 27 07:25:16 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450A59B.804@woh.rr.com> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <4450A59B.804@woh.rr.com> Message-ID: <20060427112508.GB7364@charly.SWORD> On Thu, Apr 27, 2006 at 07:06:03AM -0400, Dave Phillips wrote: > Thomas Vecchione wrote: > > >My vote is to keep LADSPA. I just dont see enough reason to change it. > > > > Seablade > > > Ditto. It's easily pronounceable. it has a high Google profile, and it's > been in extensive use. > > OTOH, if it's not "simple" anymore I understand the need for a change. Well, the S can be for Streaming. The L could become Libre, should Linux ever cease to be the main platform. Cheers, Thorsten Wilms From larsl at users.sourceforge.net Thu Apr 27 07:26:09 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Thu Apr 27 07:26:28 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> Message-ID: <1146137169.7953.8.camel@localhost> On Thu, 2006-04-27 at 13:14 +0200, Luis Garrido wrote: > The RDF stuff is looking more and more arcane and hairy with each > iteration, with all those colons, periods and quotes, plus some > SQL'ish for good measure. Human readable? I begin to miss the > syntactic simplicity of only using angled brackets in XML. Sigh, not > another syntax to learn, please. I disagree - XML is a nightmare to read (and has plenty of weird characters too). TTL looks much nicer. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060427/5762df19/attachment.bin From luisgarrido at users.sourceforge.net Thu Apr 27 07:29:37 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Thu Apr 27 07:29:46 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name early consensus? In-Reply-To: References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: LADSPA is already long to write and the DSP bit is weird to pronounce in any language I know. An additional '2' would only make it longer and weirder. Call me lazy. As long as it is not a common word or acronym, like sax or pea, any choice can probably rank high in google in little time. Thus my vote is xap>peep Luis From dsbaikov at gmail.com Thu Apr 27 07:34:06 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Apr 27 07:34:16 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name early consensus? In-Reply-To: References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <70a871c80604270434r7ce1a3e6ie2e9310cb76536d6@mail.gmail.com> Here's my variants LiMP - Linux/Libre Media Plugin LAM - Linux Audio Module LAMA - Linux Audio Module Architecture From seablaede at gmail.com Thu Apr 27 07:46:31 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Apr 27 07:43:01 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450A59B.804@woh.rr.com> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <4450A59B.804@woh.rr.com> Message-ID: <4450AF17.4030704@gmail.com> >> > Ditto. It's easily pronounceable. it has a high Google profile, and it's been in extensive use. > > OTOH, if it's not "simple" anymore I understand the need for a change. Personally I consider it drop the acronym. Just call it LADSPA. It is pronounceable on its own as has been mentioned, and why the heck does everything in Linux/Open Source HAVE to be an acronym? So to clarify, if there is a problem with LADSPA based off the acronym, drop the fact it is an acronym and just call it LADSPA Plugins. Seablade From Jan.Weil at web.de Thu Apr 27 07:47:36 2006 From: Jan.Weil at web.de (Jan Weil) Date: Thu Apr 27 07:47:42 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450AF17.4030704@gmail.com> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <4450A59B.804@woh.rr.com> <4450AF17.4030704@gmail.com> Message-ID: <1146138456.7593.12.camel@localhost.localdomain> On Thu, 2006-04-27 at 07:46 -0400, Thomas Vecchione wrote: > Personally I consider it drop the acronym. Just call it LADSPA. It is > pronounceable on its own as has been mentioned, and why the heck does > everything in Linux/Open Source HAVE to be an acronym? > > So to clarify, if there is a problem with LADSPA based off the acronym, > drop the fact it is an acronym and just call it LADSPA Plugins. TPAFKAL ;-) From taybin at earthlink.net Thu Apr 27 07:59:48 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Apr 27 08:00:10 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: peeper>peep>apa Taybin On Apr 27, 2006, at 5:02 AM, Steve Harris wrote: > Discusson seems to have slowwed down a bit, so I went through the list > archive and pulled out all the names: > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > ---- > > I vetoed ape and meep as the name clashes are too close. > > To see if theres early consensus lets run a condorcet vote on the > options. > If everyone posts thier preference in order seperated by >, eg. > foo>bar>baz > means "I'd like foo, but if I cant have that I'l have bar, and if I > cant > have that I'l have baz, everything else is unacceptable". Then we > can run > it thorugh an online voting system. > > - Steve From jamesmichaelmcdermott at gmail.com Thu Apr 27 08:13:36 2006 From: jamesmichaelmcdermott at gmail.com (James McDermott) Date: Thu Apr 27 08:13:42 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: xap>apa>ladspa2 peep and limp have unfortunate connotations in English! From seablaede at gmail.com Thu Apr 27 08:23:25 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Apr 27 08:19:55 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <1146138456.7593.12.camel@localhost.localdomain> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <4450A59B.804@woh.rr.com> <4450AF17.4030704@gmail.com> <1146138456.7593.12.camel@localhost.localdomain> Message-ID: <4450B7BD.3080807@gmail.com> > TPAFKAL Probably be funnier if I had any clue what that meant;) Seablade From Jan.Weil at web.de Thu Apr 27 08:26:38 2006 From: Jan.Weil at web.de (Jan Weil) Date: Thu Apr 27 08:26:43 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450B7BD.3080807@gmail.com> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <4450A59B.804@woh.rr.com> <4450AF17.4030704@gmail.com> <1146138456.7593.12.camel@localhost.localdomain> <4450B7BD.3080807@gmail.com> Message-ID: <1146140798.7593.16.camel@localhost.localdomain> On Thu, 2006-04-27 at 08:23 -0400, Thomas Vecchione wrote: > > TPAFKAL > > Probably be funnier if I had any clue what that meant;) Remember the Prince story? TAFKAP? (The Plugin Api Formerly Known As Ladspa) From seablaede at gmail.com Thu Apr 27 08:34:26 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Apr 27 08:30:50 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <1146140798.7593.16.camel@localhost.localdomain> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <4450A59B.804@woh.rr.com> <4450AF17.4030704@gmail.com> <1146138456.7593.12.camel@localhost.localdomain> <4450B7BD.3080807@gmail.com> <1146140798.7593.16.camel@localhost.localdomain> Message-ID: <4450BA52.8050708@gmail.com> > Remember the Prince story? TAFKAP? > > (The Plugin Api Formerly Known As Ladspa) Oi.... Seablade From dlphillips at woh.rr.com Thu Apr 27 08:46:19 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu Apr 27 08:44:33 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <1146140798.7593.16.camel@localhost.localdomain> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> <4450A59B.804@woh.rr.com> <4450AF17.4030704@gmail.com> <1146138456.7593.12.camel@localhost.localdomain> <4450B7BD.3080807@gmail.com> <1146140798.7593.16.camel@localhost.localdomain> Message-ID: <4450BD1B.6010706@woh.rr.com> Jan Weil wrote: >On Thu, 2006-04-27 at 08:23 -0400, Thomas Vecchione wrote: > > >>>TPAFKAL >>> >>> >>Probably be funnier if I had any clue what that meant;) >> >> > >Remember the Prince story? TAFKAP? > >(The Plugin Api Formerly Known As Ladspa) > > Talk about sad: I sat here and wondered "What prince is he talking about ?"... I am so lame... :) Best, dp From Cedric.Roux at eurecom.fr Thu Apr 27 08:48:27 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Thu Apr 27 08:48:35 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450BD1B.6010706@woh.rr.com> Message-ID: On Thu, 27 Apr 2006, Dave Phillips wrote: > Jan Weil wrote: > > >On Thu, 2006-04-27 at 08:23 -0400, Thomas Vecchione wrote: > > > > > >>>TPAFKAL > >>> > >>> > >>Probably be funnier if I had any clue what that meant;) > >> > >> > > > >Remember the Prince story? TAFKAP? > > > >(The Plugin Api Formerly Known As Ladspa) > > > > > Talk about sad: I sat here and wondered "What prince is he talking about > ?"... > > I am so lame... :) > > Best, > > dp I propose KAFKA for "you Know it's hArd to Find a new Kewl name for ladspA". Otherwise, why not keep ladspa (ladspa2 if you like)? It's well known, why change? C?dric. From drunkenbird at gmail.com Thu Apr 27 08:58:24 2006 From: drunkenbird at gmail.com (grae) Date: Thu Apr 27 08:58:30 2006 Subject: [linux-audio-dev] Googlable "LADSPA2" names In-Reply-To: <20060427101422.GI21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <20060427091921.GA7364@charly.SWORD> <20060427101422.GI21744@login.ecs.soton.ac.uk> Message-ID: <73802df70604270558i79818189u6609ca8d3a48a902@mail.gmail.com> That's true. But it wouldn't be the same. The main .org site would jump to the top, but then you'd have 5 pages of saxaphones and sax parsers before you hit joe blow's blog about sax plugins. Maybe its not that important. Just my thoughts :) On 4/27/06, Steve Harris wrote: > On Thu, Apr 27, 2006 at 11:19:21 +0200, Thorsten Wilms wrote: > > On Thu, Apr 27, 2006 at 10:02:20AM +0100, Steve Harris wrote: > > > > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > > > > > To see if theres early consensus lets run a condorcet vote on the options. > > > If everyone posts thier preference in order seperated by >, eg. > > > foo>bar>baz > > > > ladspa2>sap>xap>peep>peeper>sax>fap>eep>clap>chap>apa>rap>pea>wasap>rap > > > > everything but ladspa(2) is a google nightmare. > > Yeah, but it wont be after we have some web presence. A slotdot post and > mention in LWN is all it needs to be highly ranked in google. > > - Steve > From drunkenbird at gmail.com Thu Apr 27 09:00:36 2006 From: drunkenbird at gmail.com (grae) Date: Thu Apr 27 09:00:44 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: References: <4450BD1B.6010706@woh.rr.com> Message-ID: <73802df70604270600h6c30e545n134499046866723a@mail.gmail.com> Agreed here, I vote to keep Ladspa. Change the acronym meaning or forget it entirely if desired. Lad'spa is easy to say and we all know what it is. :) On 4/27/06, Cedric Roux wrote: > On Thu, 27 Apr 2006, Dave Phillips wrote: > > > Jan Weil wrote: > > > > >On Thu, 2006-04-27 at 08:23 -0400, Thomas Vecchione wrote: > > > > > > > > >>>TPAFKAL > > >>> > > >>> > > >>Probably be funnier if I had any clue what that meant;) > > >> > > >> > > > > > >Remember the Prince story? TAFKAP? > > > > > >(The Plugin Api Formerly Known As Ladspa) > > > > > > > > Talk about sad: I sat here and wondered "What prince is he talking about > > ?"... > > > > I am so lame... :) > > > > Best, > > > > dp > > I propose KAFKA for "you Know it's hArd to Find a new Kewl name > for ladspA". > > Otherwise, why not keep ladspa (ladspa2 if you like)? It's well known, > why change? > > C?dric. > > From andre.pereira at ig.com.br Thu Apr 27 09:49:02 2006 From: andre.pereira at ig.com.br (=?utf-8?q?Andr=C3=A9_Alves_Pereira?=) Date: Thu Apr 27 09:49:19 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <73802df70604270600h6c30e545n134499046866723a@mail.gmail.com> References: <4450BD1B.6010706@woh.rr.com> <73802df70604270600h6c30e545n134499046866723a@mail.gmail.com> Message-ID: <200604271349.02409.andre.pereira@ig.com.br> I agree. I vote to keep Ladspa too. Andr? Magoo Em Quinta 27 Abril 2006 13:00, grae escreveu: > Agreed here, I vote to keep Ladspa. Change the acronym meaning or > forget it entirely if desired. Lad'spa is easy to say and we all know > what it is. :) > From pw_lists at slinkp.com Thu Apr 27 10:07:58 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Apr 27 10:08:12 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <4450A45A.1040905@gmail.com> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> <20060427101609.GJ21744@login.ecs.soton.ac.uk> <4450A45A.1040905@gmail.com> Message-ID: <20060427140757.GA9499@slinkp.com> On Thu, Apr 27, 2006 at 07:00:42AM -0400, Thomas Vecchione wrote: > My vote is to keep LADSPA. I just dont see enough reason to change it. +1. -- Paul Winkler http://www.slinkp.com From loki.davison at gmail.com Thu Apr 27 11:07:46 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Apr 27 11:08:07 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name In-Reply-To: References: <4450BD1B.6010706@woh.rr.com> Message-ID: On 4/27/06, Cedric Roux wrote: > On Thu, 27 Apr 2006, Dave Phillips wrote: > > > Jan Weil wrote: > > > > >On Thu, 2006-04-27 at 08:23 -0400, Thomas Vecchione wrote: > > > > > > > > >>>TPAFKAL > > >>> > > >>> > > >>Probably be funnier if I had any clue what that meant;) > > >> > > >> > > > > > >Remember the Prince story? TAFKAP? > > > > > >(The Plugin Api Formerly Known As Ladspa) > > > > > > > > Talk about sad: I sat here and wondered "What prince is he talking about > > ?"... > > > > I am so lame... :) > > > > Best, > > > > dp > > I propose KAFKA for "you Know it's hArd to Find a new Kewl name > for ladspA". > > Otherwise, why not keep ladspa (ladspa2 if you like)? It's well known, > why change? > > C?dric. Hey! i like that name! got for Kafka! Loki From musound at jps.net Thu Apr 27 11:39:06 2006 From: musound at jps.net (Sean Bolton) Date: Thu Apr 27 11:37:37 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060427101233.GH21744@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> Message-ID: On Apr 27, 2006, at 3:12 AM, Steve Harris wrote: > On Thu, Apr 27, 2006 at 05:13:24 -0400, Dave Robillard wrote: >> On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote: >>> http://plugin.org.uk/ladspa2/ >>> >>> Removed the :logarithmic hint, I agree with Paul, its not >>> fit-for-purpose as specified. >> >> er, I need logarithmic. if it's not fit-for-purpose as specified then >> we can specify it differently. it's in ladspa 1 :) > > Yeah, but given that it doesn't work, I think its reasonable to remove > it. > > We replace it with something that does work the moment after "LADSPA2" > is > finalised. Okay, Steve, I trust you have something ready to go that you feel will replace it, but I'm still worried. The discussion you and Paul had on this list sounded to me like you were both conflating the need for scaling a linear range (widget or MIDI CC) to an exponential one (e.g. frequency port), with the need to provide unit labels for port values (e.g. "dBFS"). The two are independent, and I agree with Dave that the log scaling hint is essential. It does work when bounds are sensibly specified (i.e. don't include zero), and needs to be extended -- not dropped -- to handle the other common cases people try to (ab)use it for. If we're going to replace it "the moment after 'LADSPA2' is finalised", then we'd better be sure the replacement is ready to go. Can you tell us more, please? -Sean From musical_snake at gmx.de Thu Apr 27 12:15:51 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Thu Apr 27 12:25:14 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name In-Reply-To: References: <4450BD1B.6010706@woh.rr.com> Message-ID: <4450EE37.70705@gmx.de> Has this list recently changed from a developer list to list for marketing personnel, that has to decide about product names and logos? ;-) Ladspa is ok because it does not have too many clashes with other names. If at all a name change, then LAPA = linux audio plugin api. Lapa is easy to pronounce in every language i ever heard. Especially good for asian people. OTOH, the word is widely used in portuguese. Ralf From matthias_weiss at gmx.at Thu Apr 27 15:26:31 2006 From: matthias_weiss at gmx.at (Matthias) Date: Thu Apr 27 14:33:27 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <20060427192630.GA592@deepThought> ladspa2>plux On Thu, Apr 27, 2006 at 10:02:20AM +0100, Steve Harris wrote: > Discusson seems to have slowwed down a bit, so I went through the list > archive and pulled out all the names: > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap > > ---- > > I vetoed ape and meep as the name clashes are too close. > > To see if theres early consensus lets run a condorcet vote on the options. > If everyone posts thier preference in order seperated by >, eg. > foo>bar>baz > means "I'd like foo, but if I cant have that I'l have bar, and if I cant > have that I'l have baz, everything else is unacceptable". Then we can run > it thorugh an online voting system. > > - Steve From kjetil at ccrma.stanford.edu Thu Apr 27 14:36:17 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Apr 27 14:36:27 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name In-Reply-To: <20060427111431.5C39B132D18B@music.columbia.edu> References: <20060427111431.5C39B132D18B@music.columbia.edu> Message-ID: I vote for "LADSPA" as well. From paniq at paniq.org Thu Apr 27 15:07:32 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu Apr 27 14:52:46 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <20060427050252.GB21744@login.ecs.soton.ac.uk> References: <20060426081018.0528612E8FE0@music.columbia.edu> <1146086739.14289.128.camel@localhost> <444FEC4A.6020504@boosthardware.com> <1146093700.14289.130.camel@localhost> <20060427050252.GB21744@login.ecs.soton.ac.uk> Message-ID: <1146164853.14289.152.camel@localhost> On Thu, 2006-04-27 at 06:02 +0100, Steve Harris wrote: > Yes, but sounds a bit fruit flavoured to me, too close to AudioUnit. > > On the wordy front we could have FreePlug/OpenPlug or something, but its > bit dull. actually something like Open* wouldnt be bad. OpenAP. > > - Steve -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From paniq at paniq.org Thu Apr 27 15:09:57 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu Apr 27 14:55:11 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146129205.27822.0.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> Message-ID: <1146164997.14289.154.camel@localhost> On Thu, 2006-04-27 at 05:13 -0400, Dave Robillard wrote: > On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote: > > http://plugin.org.uk/ladspa2/ > > > > Removed the :logarithmic hint, I agree with Paul, its not > > fit-for-purpose as specified. > > er, I need logarithmic. if it's not fit-for-purpose as specified then > we can specify it differently. it's in ladspa 1 :) its however really causing headaches on the host side. the default host lib should provide some means to convert linear/logarithmic properly. > > -DR- > > -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From paniq at paniq.org Thu Apr 27 15:11:15 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu Apr 27 14:56:28 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <20060427093734.GA5461@raven.londonmet.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> <200604271126.49520.koloska@voiceinterconnect.de> <20060427093734.GA5461@raven.londonmet.ac.uk> Message-ID: <1146165076.14289.156.camel@localhost> On Thu, 2006-04-27 at 10:37 +0100, ild0012@raven.londonmet.ac.uk wrote: > May be Plux ? say like plux is plugin llibrary Your search - openplux - did not match any documents. > > Uwe > > -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From paniq at paniq.org Thu Apr 27 15:12:52 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu Apr 27 14:58:06 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name In-Reply-To: References: <20060427111431.5C39B132D18B@music.columbia.edu> Message-ID: <1146165173.14289.158.camel@localhost> ok, here's my vote. openplux>plux>ladspa2 On Thu, 2006-04-27 at 11:36 -0700, Kjetil S. Matheussen wrote: > I vote for "LADSPA" as well. > -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From hans at fugal.net Thu Apr 27 15:57:54 2006 From: hans at fugal.net (Hans Fugal) Date: Thu Apr 27 15:58:07 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <20060427195754.GA28275@falcon.fugal.net> ladspa>lapa>plux>xap From b0ef at esben-stien.name Thu Apr 27 18:27:56 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Thu Apr 27 16:30:14 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> (Steve Harris's message of "Thu, 27 Apr 2006 10:02:20 +0100") References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <87bqum4psj.fsf@esben-stien.name> Steve Harris writes: > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap Out of this list; doesn't PEEP scream at you?;). It's a recursive acronym, it's cute and it's funny. A name does wonders. It's even backwards compatible. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From ix at replic.net Thu Apr 27 16:47:16 2006 From: ix at replic.net (carmen) Date: Thu Apr 27 16:47:15 2006 Subject: [linux-audio-dev] Re: "LADSPADSSI2" name In-Reply-To: <1146165173.14289.158.camel@localhost> References: <20060427111431.5C39B132D18B@music.columbia.edu> <1146165173.14289.158.camel@localhost> Message-ID: <20060427204716.GA3518@replic.net> On Thu Apr 27, 2006 at 09:12:52PM +0200, Leonard paniq Ritter wrote: > ok, here's my vote. > > openplux>plux>ladspa2 does DSSI get its own name? i was going to vote for XAP/LAP/SIN or something, but as VST and AU both consider instruments and filters part of the same family.. LADISSY? LDY? SPIDDY? From capocasa at gmx.net Thu Apr 27 16:50:57 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Thu Apr 27 16:51:40 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: Hey, Plux is a good one! Linux reference but not too obvious... and fun to use (okay now I'm gonna fill this synth here with all the PLUX and now see how it SOUNNNNDNDDDZZZZZ :) Plux > APA > LADSPA2 Carlo From jesse at essej.net Thu Apr 27 20:26:17 2006 From: jesse at essej.net (Jesse Chappell) Date: Thu Apr 27 20:26:24 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name In-Reply-To: <1146165173.14289.158.camel@localhost> References: <20060427111431.5C39B132D18B@music.columbia.edu> <1146165173.14289.158.camel@localhost> Message-ID: GMPI From conrad at metadecks.org Thu Apr 27 20:31:17 2006 From: conrad at metadecks.org (Conrad Parker) Date: Thu Apr 27 20:31:33 2006 Subject: [linux-audio-dev] "LADSPA2" name early consensus? In-Reply-To: <20060427090220.GF21744@login.ecs.soton.ac.uk> References: <20060427090220.GF21744@login.ecs.soton.ac.uk> Message-ID: <20060428003117.GG4582@vergenet.net> On Thu, Apr 27, 2006 at 10:02:20AM +0100, Steve Harris wrote: > Discusson seems to have slowwed down a bit, so I went through the list > archive and pulled out all the names: > > apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap xap>rap>peep Conrad. From errandir_news at mph.eclipse.co.uk Thu Apr 27 20:42:35 2006 From: errandir_news at mph.eclipse.co.uk (Martin Habets) Date: Thu Apr 27 20:42:41 2006 Subject: [linux-audio-dev] "LADSPA2" name In-Reply-To: <73802df70604270600h6c30e545n134499046866723a@mail.gmail.com> References: <4450BD1B.6010706@woh.rr.com> <73802df70604270600h6c30e545n134499046866723a@mail.gmail.com> Message-ID: <20060428004235.GA5275@palantir8> On Thu, Apr 27, 2006 at 08:00:36AM -0500, grae wrote: > Agreed here, I vote to keep Ladspa. Change the acronym meaning or > forget it entirely if desired. Lad'spa is easy to say and we all know > what it is. :) Yep, ladspa is just embedded in my brain. Change the 's' to super (as in meta) if you want/need to. :) -- Martin From drobilla at connect.carleton.ca Thu Apr 27 21:03:09 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu Apr 27 21:03:05 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name In-Reply-To: References: <20060427111431.5C39B132D18B@music.columbia.edu> <1146165173.14289.158.camel@localhost> Message-ID: <1146186189.11622.0.camel@DaveLap> On Thu, 2006-04-27 at 20:26 -0400, Jesse Chappell wrote: > GMPI Heh. How about AEMPI - Actually Existant Media Plugin Interface -DR- From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 03:33:24 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 03:33:47 2006 Subject: [linux-audio-dev] Re: "LADSPA2" name In-Reply-To: <1146186189.11622.0.camel@DaveLap> References: <20060427111431.5C39B132D18B@music.columbia.edu> <1146165173.14289.158.camel@localhost> <1146186189.11622.0.camel@DaveLap> Message-ID: <20060428073324.GA23451@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 09:03:09PM -0400, Dave Robillard wrote: > On Thu, 2006-04-27 at 20:26 -0400, Jesse Chappell wrote: > > GMPI > > Heh. How about AEMPI - Actually Existant Media Plugin Interface That's not even funny ;) I've always been a fan of the benevolant dictator model over committees. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 03:57:37 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 03:57:54 2006 Subject: [linux-audio-dev] LADSPA2 name early consensus Message-ID: <20060428075737.GD22764@login.ecs.soton.ac.uk> OK, it seems like the consensus is clear to me. So far, most people want to use/keep LADSPA2. I ran it through a condorcet program, just to make sure, but it't not in doubt. FWIW, by my count the pure "acceptable" numbers came out as: 17 ladspa2 7 xap 6 peep 5 apa 4 sax 4 plux 3 rap 2 peeper 2 eep 1 wasap 1 sap 1 pea 1 openplux 1 lapa 1 fap 1 clap 1 chap And the condorcet pattern was: 9 ladspa2 1 ladspa2>apa>sax 1 ladspa2>plux 1 ladspa2>sap>xap>peep>peeper>sax>fap>eep>clap>chap>apa>rap>pea>wasap>rap 1 ladspa2>lapa>plux>xap 1 openplux>plux>ladspa2 1 peep 1 peeper>peep>apa 1 plux>apa>ladspa2 1 sax>eep>xap 1 xap>apa>ladspa2 1 xap>peep 1 xap>rap>peep 1 xap>sax>peep>ladspa2 Only 23% of those voters would find LADSPA2 unacceptable, next best is XAP which 68% would find unacceptable. I wasn't especially rigourous, so I may have missed, or misinterpreted someones vote. Someone could poll the LAU list if they felt inclined. I think that we should give the people who's names appear on the original .h file a veto, as were doing some radical changes to the design - though hopefully still in the spirit of the original. It doesn't look like we'd ever reach consensus on any other name though. *sigh* I guess I should invest in an anti-RSI keyboard. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 04:02:26 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 04:02:47 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> Message-ID: <20060428080225.GE22764@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote: > The RDF stuff is looking more and more arcane and hairy with each > iteration, with all those colons, periods and quotes, plus some > SQL'ish for good measure. Human readable? I begin to miss the > syntactic simplicity of only using angled brackets in XML. Sigh, not > another syntax to learn, please. XML doesn't offer the features we need. If we define an XML schema for LADSPA2 descriptions, and someone extends it, you can bet your bottom dollar that it will break 90% of the parsers in some exciting way. I'm a big fan of XML, all my plugin source is in XML. This just isn't the right application for it. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 04:30:59 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 04:31:36 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> Message-ID: <20060428083059.GF22764@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 08:39:06AM -0700, Sean Bolton wrote: > Okay, Steve, I trust you have something ready to go that you feel will > replace it, but I'm still worried. The discussion you and Paul had on > this list sounded to me like you were both conflating the need for > scaling a linear range (widget or MIDI CC) to an exponential one > (e.g. frequency port), with the need to provide unit labels for port > values (e.g. "dBFS"). The two are independent, and I agree with > Dave that the log scaling hint is essential. It does work when bounds > are sensibly specified (i.e. don't include zero), and needs to be > extended -- not dropped -- to handle the other common cases people > try to (ab)use it for. Sure, the problem is that the log hint doesn't actually do what you want. The only time I use it is for frequency ports. Extending it so that it can cover that case would be really hard, and it only covers the one case, so you may as well just say "this is a frequency". Frequecies (eg. filter cutoff frequencies) typically go from 0-fs/something, and the LADSPA hint mechanism has no way of indicating really-close-to-zero-but-not-quite in a way that works reliably. You can do what Dave does, and remap everthing to 1-2 or similar, but then you don't get a linear relationship between input values and octaves, which is what you're after. I think I used to use it for gain too, but that works even less well, so I stopped. So, what you really need is the information about what the port is actualy representing, that way the hosts can make an intelligent choice about how to map it to a UI feature. eg. a pitch mapping for frequency inputs, and an IEC scale for dBs. > If we're going to replace it "the moment after 'LADSPA2' is finalised", > then we'd better be sure the replacement is ready to go. Can you > tell us more, please? I worked with some chemists who defined a RDF ontology for SI units, I was just planning to steal thier design. You can have a list of units that you want to handle logarithmically, if that's what you want to do, but I'd rather not encourage people io implement the Wrong Thing(TM). If you're concerned about this (I may not have considered all the implications, I dont have that much experience of host development) we could discuss it, but I dont want to do that until LADSPA2 is done and dusted. Too distracting. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 04:31:35 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 04:32:17 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146164997.14289.154.camel@localhost> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <1146164997.14289.154.camel@localhost> Message-ID: <20060428083135.GG22764@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 09:09:57PM +0200, Leonard paniq Ritter wrote: > On Thu, 2006-04-27 at 05:13 -0400, Dave Robillard wrote: > > On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote: > > > http://plugin.org.uk/ladspa2/ > > > > > > Removed the :logarithmic hint, I agree with Paul, its not > > > fit-for-purpose as specified. > > > > er, I need logarithmic. if it's not fit-for-purpose as specified then > > we can specify it differently. it's in ladspa 1 :) > > its however really causing headaches on the host side. the default host > lib should provide some means to convert linear/logarithmic properly. There is not properly. It just doesnt make sense. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 04:33:34 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 04:34:27 2006 Subject: [linux-audio-dev] Re: "LADSPADSSI2" name In-Reply-To: <20060427204716.GA3518@replic.net> References: <20060427111431.5C39B132D18B@music.columbia.edu> <1146165173.14289.158.camel@localhost> <20060427204716.GA3518@replic.net> Message-ID: <20060428083334.GH22764@login.ecs.soton.ac.uk> On Thu, Apr 27, 2006 at 08:47:16PM +0000, carmen wrote: > On Thu Apr 27, 2006 at 09:12:52PM +0200, Leonard paniq Ritter wrote: > > ok, here's my vote. > > > > openplux>plux>ladspa2 > > does DSSI get its own name? i was going to vote for XAP/LAP/SIN or something, but as VST and AU both consider instruments and filters part of the same family.. It /may/ be possible at some unspecified point in the future to define DSSI purely as a LADSPA2 extension. No promises though. - Steve From damon at karuna.uklinux.net Fri Apr 28 06:12:13 2006 From: damon at karuna.uklinux.net (Damon Chaplin) Date: Fri Apr 28 06:12:46 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060428080225.GE22764@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428080225.GE22764@login.ecs.soton.ac.uk> Message-ID: <1146219133.2496.14.camel@localhost.localdomain> On Fri, 2006-04-28 at 09:02 +0100, Steve Harris wrote: > On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote: > > The RDF stuff is looking more and more arcane and hairy with each > > iteration, with all those colons, periods and quotes, plus some > > SQL'ish for good measure. Human readable? I begin to miss the > > syntactic simplicity of only using angled brackets in XML. Sigh, not > > another syntax to learn, please. > > XML doesn't offer the features we need. If we define an XML schema for > LADSPA2 descriptions, and someone extends it, you can bet your bottom > dollar that it will break 90% of the parsers in some exciting way. But RDF can be written in XML, so it must have the features, mustn't it? I just find it very hard to believe that audio plugins are that special. Everyone else seems to manage fine with XML. Damon From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 06:57:08 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 06:57:28 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146219133.2496.14.camel@localhost.localdomain> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428080225.GE22764@login.ecs.soton.ac.uk> <1146219133.2496.14.camel@localhost.localdomain> Message-ID: <20060428105708.GK22764@login.ecs.soton.ac.uk> On Fri, Apr 28, 2006 at 11:12:13AM +0100, Damon Chaplin wrote: > On Fri, 2006-04-28 at 09:02 +0100, Steve Harris wrote: > > On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote: > > > The RDF stuff is looking more and more arcane and hairy with each > > > iteration, with all those colons, periods and quotes, plus some > > > SQL'ish for good measure. Human readable? I begin to miss the > > > syntactic simplicity of only using angled brackets in XML. Sigh, not > > > another syntax to learn, please. > > > > XML doesn't offer the features we need. If we define an XML schema for > > LADSPA2 descriptions, and someone extends it, you can bet your bottom > > dollar that it will break 90% of the parsers in some exciting way. > > But RDF can be written in XML, so it must have the features, mustn't it? Well, yes and no. RDF/XML is a way of writing RDF data in XML, the XML doesn't mean anything in terms of the XML tree, you need an RDF parser to make sense of it. You could define something equivlent just for LADSPA, but then you would just be reinventing RDF/XML, so why bother? > I just find it very hard to believe that audio plugins are that special. > Everyone else seems to manage fine with XML. No they dont. There are countless things that aren't done in XML, even XML heavy apps like Firefox use loads of RDF internally to model things that are painful to do in XML, eg. browser history and XPI manifests. - Steve From larsl at users.sourceforge.net Fri Apr 28 07:19:22 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Fri Apr 28 07:19:28 2006 Subject: [linux-audio-dev] LADSPA2 name early consensus In-Reply-To: <20060428075737.GD22764@login.ecs.soton.ac.uk> References: <20060428075737.GD22764@login.ecs.soton.ac.uk> Message-ID: <1146223162.8782.0.camel@localhost> On Fri, 2006-04-28 at 08:57 +0100, Steve Harris wrote: > OK, it seems like the consensus is clear to me. So far, most people want to > use/keep LADSPA2. > > ... > > *sigh* I guess I should invest in an anti-RSI keyboard. Emacs' Alt-/ is great. =) -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060428/8825a923/attachment.bin From capocasa at gmx.net Fri Apr 28 07:51:20 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Apr 28 07:51:41 2006 Subject: [linux-audio-dev] Re: LADSPA2 name early consensus In-Reply-To: <20060428075737.GD22764@login.ecs.soton.ac.uk> References: <20060428075737.GD22764@login.ecs.soton.ac.uk> Message-ID: Well, that's a little like saying 'Would you rather go to McDonalds or that new burger joint nobody knows that might be a lot better but also might be a lot worse?' Perhaps if a new name is to be decided the benevolent dictator should simply decide a new name is to be given and it is up to us to decide which. Carlo Steve Harris schrieb: > OK, it seems like the consensus is clear to me. So far, most people want to > use/keep LADSPA2. I ran it through a condorcet program, just to make sure, > but it't not in doubt. FWIW, by my count the pure "acceptable" numbers > came out as: > > 17 ladspa2 > 7 xap > 6 peep > 5 apa > 4 sax > 4 plux > 3 rap > 2 peeper > 2 eep > 1 wasap > 1 sap > 1 pea > 1 openplux > 1 lapa > 1 fap > 1 clap > 1 chap > > And the condorcet pattern was: > > 9 ladspa2 > 1 ladspa2>apa>sax > 1 ladspa2>plux > 1 ladspa2>sap>xap>peep>peeper>sax>fap>eep>clap>chap>apa>rap>pea>wasap>rap > 1 ladspa2>lapa>plux>xap > 1 openplux>plux>ladspa2 > 1 peep > 1 peeper>peep>apa > 1 plux>apa>ladspa2 > 1 sax>eep>xap > 1 xap>apa>ladspa2 > 1 xap>peep > 1 xap>rap>peep > 1 xap>sax>peep>ladspa2 > > Only 23% of those voters would find LADSPA2 unacceptable, next best is XAP > which 68% would find unacceptable. > > I wasn't especially rigourous, so I may have missed, or misinterpreted > someones vote. Someone could poll the LAU list if they felt inclined. > > I think that we should give the people who's names appear on the original > .h file a veto, as were doing some radical changes to the design - though > hopefully still in the spirit of the original. It doesn't look like we'd > ever reach consensus on any other name though. > > *sigh* I guess I should invest in an anti-RSI keyboard. > > - Steve > From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 09:13:14 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 09:13:35 2006 Subject: [linux-audio-dev] Re: LADSPA2 name early consensus In-Reply-To: References: <20060428075737.GD22764@login.ecs.soton.ac.uk> Message-ID: <20060428131314.GL22764@login.ecs.soton.ac.uk> On Fri, Apr 28, 2006 at 01:51:20PM +0200, Carlo Capocasa wrote: > > Well, that's a little like saying 'Would you rather go to McDonalds or > that new burger joint nobody knows that might be a lot better but also > might be a lot worse?' > > Perhaps if a new name is to be decided the benevolent dictator should > simply decide a new name is to be given and it is up to us to decide which. I don't think thats particularly helpful. There's not any agreement even amongst people who dont think that LADSPA is a good name what a good name is. So, I think saying "We can't use LADSPA2" wouldn't be especially benevolent :) That said, its up to the original LADSPA authors. - Steve From musound at jps.net Fri Apr 28 13:01:15 2006 From: musound at jps.net (Sean Bolton) Date: Fri Apr 28 13:00:21 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060428083059.GF22764@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> Message-ID: <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> On Apr 28, 2006, at 1:30 AM, Steve Harris wrote: > On Thu, Apr 27, 2006 at 08:39:06AM -0700, Sean Bolton wrote: >> Okay, Steve, I trust you have something ready to go that you feel will >> replace it, but I'm still worried. The discussion you and Paul had on >> this list sounded to me like you were both conflating the need for >> scaling a linear range (widget or MIDI CC) to an exponential one >> (e.g. frequency port), with the need to provide unit labels for port >> values (e.g. "dBFS"). The two are independent, and I agree with >> Dave that the log scaling hint is essential. It does work when bounds >> are sensibly specified (i.e. don't include zero), and needs to be >> extended -- not dropped -- to handle the other common cases people >> try to (ab)use it for. > > Sure, the problem is that the log hint doesn't actually do what you > want. > The only time I use it is for frequency ports. Extending it so that it > can > cover that case would be really hard, and it only covers the one case, > so > you may as well just say "this is a frequency". > > > So, what you really need is the information about what the port is > actualy > representing, that way the hosts can make an intelligent choice about > how > to map it to a UI feature. eg. a pitch mapping for frequency inputs, > and > an IEC scale for dBs. Yikes, now I'm sure this is headed the wrong direction! Say you specify that a port is representing frequency -- is it a pitch multiplier, where the 'knob' should be scaled by pitch (i.e. log(frequency)), or does it refer to an FFT bin, so that it should be scaled linearly? How about a delay time whose unit is 'seconds'? Log or linear scaling? Or a distortion drive control whose unit is technically 'radians'? How's a host supposed to figure out how to scale that? What should it do with a 'magnification' port that is unitless? It's not possible for a host to know how to scale a port from just the unit labeling. Unit labeling and input value scaling are independent, in fact are completely orthogonal except in certain conventional cases like IEC for some (not all!) dB ranges. I'm okay waiting until the base LADSPA2 spec is done to figure this part out, to keep the confusion down, so long as we all realize that until we do, LADSPA2 hosts will be even more clumsy in this regard than LADSPA 1 hosts currently are. And Steve -- setting my knit-picking here aside ;-) -- thank you very much for all your work on this! -Sean From S.W.Harris at ecs.soton.ac.uk Fri Apr 28 13:59:52 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Apr 28 14:00:11 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> Message-ID: <20060428175952.GN22764@login.ecs.soton.ac.uk> On Fri, Apr 28, 2006 at 10:01:15AM -0700, Sean Bolton wrote: > On Apr 28, 2006, at 1:30 AM, Steve Harris wrote: > >On Thu, Apr 27, 2006 at 08:39:06AM -0700, Sean Bolton wrote: > >>Okay, Steve, I trust you have something ready to go that you feel will > >>replace it, but I'm still worried. The discussion you and Paul had on > >>this list sounded to me like you were both conflating the need for > >>scaling a linear range (widget or MIDI CC) to an exponential one > >>(e.g. frequency port), with the need to provide unit labels for port > >>values (e.g. "dBFS"). The two are independent, and I agree with > >>Dave that the log scaling hint is essential. It does work when bounds > >>are sensibly specified (i.e. don't include zero), and needs to be > >>extended -- not dropped -- to handle the other common cases people > >>try to (ab)use it for. > > > >Sure, the problem is that the log hint doesn't actually do what you > >want. > >The only time I use it is for frequency ports. Extending it so that it > >can > >cover that case would be really hard, and it only covers the one case, > >so > >you may as well just say "this is a frequency". > > > > > > >So, what you really need is the information about what the port is > >actualy > >representing, that way the hosts can make an intelligent choice about > >how > >to map it to a UI feature. eg. a pitch mapping for frequency inputs, > >and > >an IEC scale for dBs. > > Yikes, now I'm sure this is headed the wrong direction! Say you specify > that a port is representing frequency -- is it a pitch multiplier, > where the > 'knob' should be scaled by pitch (i.e. log(frequency)), or does it > refer to > an FFT bin, so that it should be scaled linearly? Right, so theres a subtle bit of semantics there, which I glossed over. In the filter case your actually offering an absolute pitch control, measured in Hz. In the FFT case, it's frequency measured in Hz. > How about a delay time whose unit is 'seconds'? Log or linear scaling? Or indeed musical time (bars, beats, semi-quavers or whatever). Seconds is not often that convienient unless you're working in 60 BPM :) But passing to the plugin in any other form is antisocial. I didn't claim that this was easy, just that its possible and can do something useful, unlike the log hint. > Or a distortion drive control whose unit is technically 'radians'? How's > a host supposed to figure out how to scale that? What should it do with > a 'magnification' port that is unitless? The "technically radians" thing its a bit of a blind, I have a few like that, and I just map it to a semantics free %age or similar. > It's not possible for a host to know how to scale a port from just the > unit > labeling. Unit labeling and input value scaling are independent, in > fact > are completely orthogonal except in certain conventional cases like > IEC for some (not all!) dB ranges. Indeed, the dB ranges will need to be distinguished, and in any caase the host may not want to use IEC scales, if it has a preferred one. Scaling is only one aspect of the problem of how to correctly provide a way for the user to set certain values, many types of control port can have improved UI if the host is motivated enough to provide it. > I'm okay waiting until the base LADSPA2 spec is done to figure this part > out, to keep the confusion down, so long as we all realize that until we > do, LADSPA2 hosts will be even more clumsy in this regard than > LADSPA 1 hosts currently are. Yes, that is a downside. Pitch (aka frequency) inputs will work slightly less well than they did in LADSPA1, for a bit. > And Steve -- setting my knit-picking here aside ;-) -- thank you very > much > for all your work on this! No problem, keep up the high quality nit picking :) - Steve From drobilla at connect.carleton.ca Fri Apr 28 14:29:42 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Apr 28 14:29:48 2006 Subject: [linux-audio-dev] LADSPA2 name early consensus In-Reply-To: <20060428075737.GD22764@login.ecs.soton.ac.uk> References: <20060428075737.GD22764@login.ecs.soton.ac.uk> Message-ID: <1146248982.2340.2.camel@DaveLap> On Fri, 2006-04-28 at 08:57 +0100, Steve Harris wrote: > OK, it seems like the consensus is clear to me. So far, most people want to > use/keep LADSPA2. I ran it through a condorcet program, just to make sure, > but it't not in doubt. FWIW, by my count the pure "acceptable" numbers > came out as: Most people who suggested we keed LADSPA said "LADSPA", not LADSPA2. If we keep the name LADSPA, everything is going to have to say LADSPA2, directory names, API calls... "LADSPA2" looks like an ugly working name to me. --votes -DR- From drobilla at connect.carleton.ca Fri Apr 28 14:33:06 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Apr 28 14:33:13 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146219133.2496.14.camel@localhost.localdomain> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428080225.GE22764@login.ecs.soton.ac.uk> <1146219133.2496.14.camel@localhost.localdomain> Message-ID: <1146249186.2340.4.camel@DaveLap> On Fri, 2006-04-28 at 11:12 +0100, Damon Chaplin wrote: > On Fri, 2006-04-28 at 09:02 +0100, Steve Harris wrote: > > On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote: > > > The RDF stuff is looking more and more arcane and hairy with each > > > iteration, with all those colons, periods and quotes, plus some > > > SQL'ish for good measure. Human readable? I begin to miss the > > > syntactic simplicity of only using angled brackets in XML. Sigh, not > > > another syntax to learn, please. > > > > XML doesn't offer the features we need. If we define an XML schema for > > LADSPA2 descriptions, and someone extends it, you can bet your bottom > > dollar that it will break 90% of the parsers in some exciting way. > > But RDF can be written in XML, so it must have the features, mustn't it? > > I just find it very hard to believe that audio plugins are that special. > Everyone else seems to manage fine with XML. Google around the 'net for some examples of the same data in RDF/XML versus Turtle. You'll change your mind real quick. ;) -DR- From paniq at paniq.org Fri Apr 28 15:19:20 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Fri Apr 28 14:58:59 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146249186.2340.4.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428080225.GE22764@login.ecs.soton.ac.uk> <1146219133.2496.14.camel@localhost.localdomain> <1146249186.2340.4.camel@DaveLap> Message-ID: <1146251960.14289.181.camel@localhost> On Fri, 2006-04-28 at 14:33 -0400, Dave Robillard wrote: > Google around the 'net for some examples of the same data in RDF/XML > versus Turtle. You'll change your mind real quick. ;) great, another damn data format. we need to pull in _more_ dependencies. it is important to have _more_ crude data formats. why not have one data format per data element and embed the parser in the file as well, while we're at it? thus, i suggest writing it in turtle, accompanied by an embedded parser written in javascript, whose properties are described by an rdf file. come on, i'm sure we can put in more! -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From ix at replic.net Fri Apr 28 21:00:04 2006 From: ix at replic.net (carmen) Date: Fri Apr 28 21:00:14 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> Message-ID: <20060429010004.GC3518@replic.net> > It's not possible for a host to know how to scale a port from just the unit > labeling. Unit labeling and input value scaling are independent, in fact > are completely orthogonal except in certain conventional cases like > IEC for some (not all!) dB ranges. ++. there definitely needs to be a 'logarithmic' hint. maybe even log(10) vs log(2). im sure this RDF/JSON/YAML thing can make a case for it From S.W.Harris at ecs.soton.ac.uk Sat Apr 29 05:50:28 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 29 05:50:46 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060429010004.GC3518@replic.net> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> Message-ID: <20060429095028.GB26788@login.ecs.soton.ac.uk> On Sat, Apr 29, 2006 at 01:00:04 +0000, carmen wrote: > > It's not possible for a host to know how to scale a port from just the unit > > labeling. Unit labeling and input value scaling are independent, in fact > > are completely orthogonal except in certain conventional cases like > > IEC for some (not all!) dB ranges. > > ++. there definitely needs to be a 'logarithmic' hint. maybe even log(10) vs log(2). Errm, you you really need to think about that harder. The hint that "this should be scaled logarithmically" isn't enough information to do anything useful - try it. If you try to define an operation that hosts can apply generally then you will find there are lots of cases where it can't be applied. Either because it can't be computed, or because it does something unhelpful. > im sure this RDF/JSON/YAML thing can make a case for it Possibly, but I doubt the field of mathematics can ;) if a is the users parameter UI control value in [0,1], u is the lower bound, v is the upper bound, and b is the log base, then: port val = ( (1-a) log(u) + a log(v) )^b = ( -a log(u) + log(u) + a log(v) )^b = log( ( u+v^a ) / u^a )^b = (u + v^a) / u^a so the log base cancels out. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 29 05:57:51 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 29 05:58:12 2006 Subject: [linux-audio-dev] LADSPA2 name early consensus In-Reply-To: <1146248982.2340.2.camel@DaveLap> References: <20060428075737.GD22764@login.ecs.soton.ac.uk> <1146248982.2340.2.camel@DaveLap> Message-ID: <20060429095751.GC26788@login.ecs.soton.ac.uk> On Fri, Apr 28, 2006 at 02:29:42 -0400, Dave Robillard wrote: > On Fri, 2006-04-28 at 08:57 +0100, Steve Harris wrote: > > OK, it seems like the consensus is clear to me. So far, most people want to > > use/keep LADSPA2. I ran it through a condorcet program, just to make sure, > > but it't not in doubt. FWIW, by my count the pure "acceptable" numbers > > came out as: > > Most people who suggested we keed LADSPA said "LADSPA", not LADSPA2. > If we keep the name LADSPA, everything is going to have to say LADSPA2, > directory names, API calls... > > "LADSPA2" looks like an ugly working name to me. --votes Richard Furse also agrees, he said: [talking about the PEA name, which he likes, but I don't] > Really not sure about LADSPA2 - happy with just about anything else! We > could always bill it as "LADSPA PEA" or suchlike if folk really care > about the Trademark. I don't think that's strong enough to count as a veto, and he's away at the moment, so I can't ask him. It's enough to want me to hope we can reach a consensus on something other than LADSPA2 though. For the record, I was initally in favour of just using LADSPA2 (I'm really lazy), but he talked me out of it, hence the mail to the list asking for votes. - Steve From cuse at users.sourceforge.net Sat Apr 29 07:11:30 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Sat Apr 29 06:49:47 2006 Subject: [linux-audio-dev] [ANN] libgig 3.0.0 Message-ID: <200604291311.32232.cuse@users.sourceforge.net> Hi! Usually I don't announce new versions of libgig here anymore, but this release might be of interest for some: Beside a bunch of bug fixes it now also allows to modify existing and create new Gigasampler files. If anybody's interested in writing a .gig editor, have a look at the "gigwritedemo.cpp" example application: http://stud.hs-heilbronn.de/~cschoene/projects/libgig/#examples libgig is released under (pure) GPL and as always available on its original site: http://stud.hs-heilbronn.de/~cschoene/projects/libgig/ as well as on the LS server: http://www.linuxsampler.org/downloads.html http://download.linuxsampler.org/packages/ CU Christian P.S. I just restored the old libgig source packages on the LS server, all other packages will be restored after LAC (that is next week) - I know the downloads section on LS.org was dead for too long now, sorry! From ix at replic.net Sat Apr 29 08:23:32 2006 From: ix at replic.net (carmen) Date: Sat Apr 29 08:23:32 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060429095028.GB26788@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060429095028.GB26788@login.ecs.soton.ac.uk> Message-ID: <20060429122332.GF3518@replic.net> > > im sure this RDF/JSON/YAML thing can make a case for it > > Possibly, but I doubt the field of mathematics can ;) possibly not. but, i'm not a mathematician :) i just know that toggling sliders between log and linear in PD, Bidule, Audiomulch etc can be useful, and some kind of hint from the plug which should be the default could be useful.. > > if a is the users parameter UI control value in [0,1], u is the lower > bound, v is the upper bound, and b is the log base, then: > > port val = ( (1-a) log(u) + a log(v) )^b > = ( -a log(u) + log(u) + a log(v) )^b > = log( ( u+v^a ) / u^a )^b > = (u + v^a) / u^a > > so the log base cancels out. when its 0-1, yes. what about 20-22050? i guess i wasnt clear on why you are convinced log hint is a bad idea. but given the above goblygook i gues i will never understand :) > > - Steve From cannam at all-day-breakfast.com Sat Apr 29 10:09:49 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sat Apr 29 10:09:13 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060428083135.GG22764@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> Message-ID: <200604291509.49790.cannam@all-day-breakfast.com> I haven't posted to this thread yet, for a couple of reasons besides the usual lack of time. One reason is that on a technical level I don't have any argument with most of what Steve says. Removing descriptive data from the plugin I think is a good principle. I'm not fond of this Turtle format, it is complicated and I don't find it easily "visually parseable" but it's still better than XML RDF, and so long as you can easily hack someone else's .ttl file to make your own, it probably isn't much of an issue. Technically it all looks pretty much OK. But the other reason is that I don't find much to make me care about the outcome at this stage. This may be a technically better way to design a LADSPA-like plugin API, but until it offers something significantly more useful than LADSPA, that's rather irrelevant to anyone outside this thread. A LADSPA 2 that is the same as LADSPA 1, "technically superior" but incompatible will probably fail. Authors of existing hosts won't want the trouble; plugin authors will put up with the potential extra work of doing LADSPA 1 to get better host coverage. So the aim is to do more interesting things with it afterwards. But what? We want to avoid ending up with LADSPA, DSSI, and "LADSPA2", with the latter two being incompatible overlapping extensions of the first. That would be very impractical for authors of plugins that might want features from both of the extended APIs. I think we want to avoid having LADSPA, DSSI, "LADSPA2" and "DSSI2" as well; the menu is complicated enough already, for anyone reading it for the first time. This format is really going to have to aim to grow into something that can replace DSSI as well. And while that could be great, it's a much more snaggly business -- DSSI has turned out pretty complicated, for some very sound reasons, and that has already helped it to be less popular than we'd hoped. If it was obvious that we could simplify it a lot the "LADSPA2" way, that would be great, but I don't see at first glance that it is. So, I wouldn't mind hearing some thoughts on what this rewrite might ultimately be for. Chris From larsl at users.sourceforge.net Sat Apr 29 11:24:38 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat Apr 29 11:24:47 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <200604291509.49790.cannam@all-day-breakfast.com> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> Message-ID: <1146324278.7932.12.camel@localhost> On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote: > This format is really going to have to aim to grow into something that > can replace DSSI as well. And while that could be great, it's a much > more snaggly business -- DSSI has turned out pretty complicated, for > some very sound reasons, and that has already helped it to be less > popular than we'd hoped. If it was obvious that we could simplify it a > lot the "LADSPA2" way, that would be great, but I don't see at first > glance that it is. With the port types specified in the RDF file, MIDI input should be doable with explicit LADSPA2 ports of some defined MIDI type, which means that we wouldn't need the run_synth() callback. The GUI specification and the OSC protocol is already pretty much applicable to LADSPA as well as DSSI, so that should work in LADSPA2 too. New additions like MIDI output and transport info could also be done as port types. The things that aren't obvious how to do are 1) the configure() callback 2) the dynamic program lists and midi mappings (static definitions could be written in the RDF file, but that's no fun) 3) program selection 4) the run_multiple*() callbacks (how many plugins use these?) -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060429/9bddeac2/attachment.bin From drobilla at connect.carleton.ca Sat Apr 29 12:32:06 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 29 12:32:21 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060429095028.GB26788@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060429095028.GB26788@login.ecs.soton.ac.uk> Message-ID: <1146328326.2552.5.camel@DaveLap> On Sat, 2006-04-29 at 10:50 +0100, Steve Harris wrote: > On Sat, Apr 29, 2006 at 01:00:04 +0000, carmen wrote: > > > It's not possible for a host to know how to scale a port from just the unit > > > labeling. Unit labeling and input value scaling are independent, in fact > > > are completely orthogonal except in certain conventional cases like > > > IEC for some (not all!) dB ranges. > > > > ++. there definitely needs to be a 'logarithmic' hint. maybe even log(10) vs log(2). > > Errm, you you really need to think about that harder. The hint that "this > should be scaled logarithmically" isn't enough information to do anything > useful - try it. If you try to define an operation that hosts can apply > generally then you will find there are lots of cases where it can't > be applied. Either because it can't be computed, or because it does > something unhelpful. It's information with which you can do something a LOT more useful than without... -DR- From drobilla at connect.carleton.ca Sat Apr 29 12:40:11 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 29 12:40:25 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <200604291509.49790.cannam@all-day-breakfast.com> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> Message-ID: <1146328811.2552.15.camel@DaveLap> On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote: > I haven't posted to this thread yet, for a couple of reasons besides the > usual lack of time. > > One reason is that on a technical level I don't have any argument with > most of what Steve says. Removing descriptive data from the plugin I > think is a good principle. I'm not fond of this Turtle format, it is > complicated and I don't find it easily "visually parseable" but it's > still better than XML RDF, and so long as you can easily hack someone > else's .ttl file to make your own, it probably isn't much of an issue. > Technically it all looks pretty much OK. > > But the other reason is that I don't find much to make me care about the > outcome at this stage. This may be a technically better way to design > a LADSPA-like plugin API, but until it offers something significantly > more useful than LADSPA, that's rather irrelevant to anyone outside > this thread. A LADSPA 2 that is the same as LADSPA 1, "technically > superior" but incompatible will probably fail. Authors of existing > hosts won't want the trouble; plugin authors will put up with the > potential extra work of doing LADSPA 1 to get better host coverage. So > the aim is to do more interesting things with it afterwards. But what? The idea is to make LADSPA2 such that new, interesting things can happen as extensions without breaking things. LADSPA1 can't do this. As an example, LADSPA2 of course does not specify anything about MIDI, but MIDI processing LADSPA2 plugins can be built if someone defines an extension to do so. Even with major improvements like that aside, the ability to add new handy pieces of metadata at will is enough of a win to make it worthwhile, IMO. LADSPA2 itself isn't very exciting, true. But what LADSPA2 will allow is the most exciting linux audio thing to happen in a while, if you ask me.. -DR- From drobilla at connect.carleton.ca Sat Apr 29 12:42:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 29 12:42:30 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146324278.7932.12.camel@localhost> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> Message-ID: <1146328934.2552.18.camel@DaveLap> On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: > On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote: > > This format is really going to have to aim to grow into something that > > can replace DSSI as well. And while that could be great, it's a much > > more snaggly business -- DSSI has turned out pretty complicated, for > > some very sound reasons, and that has already helped it to be less > > popular than we'd hoped. If it was obvious that we could simplify it a > > lot the "LADSPA2" way, that would be great, but I don't see at first > > glance that it is. > > With the port types specified in the RDF file, MIDI input should be > doable with explicit LADSPA2 ports of some defined MIDI type, which > means that we wouldn't need the run_synth() callback. The GUI > specification and the OSC protocol is already pretty much applicable to > LADSPA as well as DSSI, so that should work in LADSPA2 too. New > additions like MIDI output and transport info could also be done as port > types. > > The things that aren't obvious how to do are > > 1) the configure() callback OSC message. > 2) the dynamic program lists and midi mappings (static definitions > could be written in the RDF file, but that's no fun) That's a tougher one. > 3) program selection OSC message. > 4) the run_multiple*() callbacks (how many plugins use these?) Silly useless function. Toss it on the trash heap with run_adding. -DR- From S.W.Harris at ecs.soton.ac.uk Sat Apr 29 13:14:46 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 29 13:15:08 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060429122332.GF3518@replic.net> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060429095028.GB26788@login.ecs.soton.ac.uk> <20060429122332.GF3518@replic.net> Message-ID: <20060429171446.GA1693@login.ecs.soton.ac.uk> On Sat, Apr 29, 2006 at 12:23:32 +0000, carmen wrote: > > > im sure this RDF/JSON/YAML thing can make a case for it > > > > Possibly, but I doubt the field of mathematics can ;) > > possibly not. but, i'm not a mathematician :) i just know that toggling sliders between log and linear in PD, Bidule, Audiomulch etc can be useful, and some kind of hint from the plug which should be the default could be useful.. > > > > > if a is the users parameter UI control value in [0,1], u is the lower > > bound, v is the upper bound, and b is the log base, then: > > > > port val = ( (1-a) log(u) + a log(v) )^b > > = ( -a log(u) + log(u) + a log(v) )^b > > = log( ( u+v^a ) / u^a )^b > > = (u + v^a) / u^a > > > > so the log base cancels out. > > when its 0-1, yes. what about 20-22050? i guess i wasnt clear on why you are convinced log hint is a bad idea. but given the above goblygook i gues i will never understand :) It doesnt make any difference, but given the choice of numbers I think you're misunderstanding it, 20-22050 is u-v, the 0-1 is just an arbitrary choice for what the UI control's limits are. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 29 13:25:20 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 29 13:25:42 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146328934.2552.18.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> Message-ID: <20060429172520.GB1693@login.ecs.soton.ac.uk> On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave Robillard wrote: > > With the port types specified in the RDF file, MIDI input should be > > doable with explicit LADSPA2 ports of some defined MIDI type, which > > means that we wouldn't need the run_synth() callback. The GUI > > specification and the OSC protocol is already pretty much applicable to > > LADSPA as well as DSSI, so that should work in LADSPA2 too. New > > additions like MIDI output and transport info could also be done as port > > types. > > > > The things that aren't obvious how to do are > > > > 1) the configure() callback > > OSC message. Thats a little laconic, even by my standards :) To my mind the key thing about configure() is that it happens outside the RT context, and LADSPA-style plugins have no easy way of running an OSC server of thier own. > > 2) the dynamic program lists and midi mappings (static definitions > > could be written in the RDF file, but that's no fun) > > That's a tougher one. Control port :| > > 3) program selection > > OSC message. Or typed control port. > > 4) the run_multiple*() callbacks (how many plugins use these?) > > Silly useless function. Toss it on the trash heap with run_adding. I'll have take your word for that. It's an optimisation from what I remember, and I think Fon's suggestion of shared control ports between voices is both a better saving and conceptualy simpler. - Steve From S.W.Harris at ecs.soton.ac.uk Sat Apr 29 13:42:18 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 29 13:42:42 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146328811.2552.15.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146328811.2552.15.camel@DaveLap> Message-ID: <20060429174217.GC1693@login.ecs.soton.ac.uk> On Sat, Apr 29, 2006 at 12:40:11PM -0400, Dave Robillard wrote: > On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote: > > I haven't posted to this thread yet, for a couple of reasons besides the > > usual lack of time. > > > > One reason is that on a technical level I don't have any argument with > > most of what Steve says. Removing descriptive data from the plugin I > > think is a good principle. I'm not fond of this Turtle format, it is > > complicated and I don't find it easily "visually parseable" but it's > > still better than XML RDF, and so long as you can easily hack someone > > else's .ttl file to make your own, it probably isn't much of an issue. > > Technically it all looks pretty much OK. > > > > But the other reason is that I don't find much to make me care about the > > outcome at this stage. This may be a technically better way to design > > a LADSPA-like plugin API, but until it offers something significantly > > more useful than LADSPA, that's rather irrelevant to anyone outside > > this thread. A LADSPA 2 that is the same as LADSPA 1, "technically > > superior" but incompatible will probably fail. Authors of existing > > hosts won't want the trouble; plugin authors will put up with the > > potential extra work of doing LADSPA 1 to get better host coverage. So > > the aim is to do more interesting things with it afterwards. But what? > > The idea is to make LADSPA2 such that new, interesting things can happen > as extensions without breaking things. LADSPA1 can't do this. > > As an example, LADSPA2 of course does not specify anything about MIDI, > but MIDI processing LADSPA2 plugins can be built if someone defines an > extension to do so. > > Even with major improvements like that aside, the ability to add new > handy pieces of metadata at will is enough of a win to make it > worthwhile, IMO. > > LADSPA2 itself isn't very exciting, true. But what LADSPA2 will allow > is the most exciting linux audio thing to happen in a while, if you ask > me.. I think that's Chris's point though. LADSPA2 has a lot of potential, but why will the users care? However I know that at least one plugin developer will port all his plugins as soon as its finalised, and all the pent up addiditons to LADSPA people have been wanting for ages, but were just to painful to add can be applied. I think the promise of the new features (better auto-built UIs and control randomise are good examples) is enough to make users request support from host authors. These things take time, and I'm not expecting it to be an overnight success, but there are so many cool things that could be done with a more capable, but still fundamentally simple spec. As to DSSI, I regard it as a quiet sucess, theres a fair few pieces of software that wouldn't have existed without it, and it was a good learning experience. Plus we showed that its possible to have plugin UIs on linux without crazy X hacks :) As to wether LADSPA2 can replace DSSI, well, hopefully at some point (we never intended DSSI to be a permenant solution, D right), but its not so urgent. The problems with LADSPA dont affect DSSI so much because it has custom UIs and configure(), which cover a multitude of sins. - Steve From cannam at all-day-breakfast.com Sat Apr 29 13:43:14 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sat Apr 29 13:42:54 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146328934.2552.18.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> Message-ID: <200604291843.14976.cannam@all-day-breakfast.com> On Saturday 29 Apr 2006 17:42, Dave Robillard wrote: > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: > > The things that aren't obvious how to do are > > > > 1) the configure() callback > > OSC message. And there you've introduced something I haven't seen in this thread yet: sending messages rather than just values to your plugin. How come there are dozens of posts here talking about the name of the API and bitching over whether this "extensible" plugin API should start out with a logarithmic port hint, when things like this are going unmentioned? Is the expectation that any plugin be able to define that a certain port accepts any given structure of data, defined entirely in the RDF? Or what? > > 2) the dynamic program lists and midi mappings (static definitions > > could be written in the RDF file, but that's no fun) > > That's a tougher one. > > > 3) program selection > > OSC message. You see that's all terribly glib, but the things that make the non-GUI parts of DSSI complex are not so much about how data is passed to and from the plugin as when it is passed, what the dependencies between things are (e.g. when you change a configure value, the programs may change; when you change a program, the ports may change), what the threading requirements are and so on. An entirely generic anything-in anything-out plugin is unlikely to be much actual use, in practice. > > 4) the run_multiple*() callbacks (how many plugins use these?) Hexter, Xsynth, WhySynth etc. run_multiple is DSSI's equivalent of MIDI channels. There is no channel information in the note messages passed to a plugin; instead the host creates as many instances as it needs, effectively one instance per channel, and run_multiple allows the plugin to share work between them if appropriate. If it has no work to share, it just doesn't bother providing this function. This can have advantages for the plugin (the simple case is simpler) and user (any plugin appears able to receive any number of channels of input, without the user's having to know what the plugin's actual configuration is). The main disadvantage is simply that it's different from how other MIDI-based APIs work. In my view it's better in isolation -- in a homogenous environment -- but can become awkward when mixed with actual MIDI devices. Chris From S.W.Harris at ecs.soton.ac.uk Sat Apr 29 14:07:11 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Apr 29 14:07:33 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <200604291843.14976.cannam@all-day-breakfast.com> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <200604291843.14976.cannam@all-day-breakfast.com> Message-ID: <20060429180711.GE1693@login.ecs.soton.ac.uk> On Sat, Apr 29, 2006 at 06:43:14PM +0100, Chris Cannam wrote: > On Saturday 29 Apr 2006 17:42, Dave Robillard wrote: > > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: > > > The things that aren't obvious how to do are > > > > > > 1) the configure() callback > > > > OSC message. > > And there you've introduced something I haven't seen in this thread yet: > sending messages rather than just values to your plugin. How come > there are dozens of posts here talking about the name of the API and > bitching over whether this "extensible" plugin API should start out > with a logarithmic port hint, when things like this are going > unmentioned? > > Is the expectation that any plugin be able to define that a certain port > accepts any given structure of data, defined entirely in the RDF? Or > what? Not entirely in RDF, the RDF is just used to identify the structure, and and constant parameters to it. The definition of it can be done in whateve'rs the most approariate way (C struct in a headerfile for example). > > > 2) the dynamic program lists and midi mappings (static definitions > > > could be written in the RDF file, but that's no fun) > > > > That's a tougher one. > > > > > 3) program selection > > > > OSC message. > > You see that's all terribly glib, but the things that make the non-GUI > parts of DSSI complex are not so much about how data is passed to and > from the plugin as when it is passed, what the dependencies between > things are (e.g. when you change a configure value, the programs may > change; when you change a program, the ports may change), what the > threading requirements are and so on. An entirely generic anything-in > anything-out plugin is unlikely to be much actual use, in practice. Agreed. - Steve From drobilla at connect.carleton.ca Sat Apr 29 19:01:30 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Apr 29 19:02:03 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060429174217.GC1693@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146328811.2552.15.camel@DaveLap> <20060429174217.GC1693@login.ecs.soton.ac.uk> Message-ID: <1146351690.3531.9.camel@DaveLap> On Sat, 2006-04-29 at 18:42 +0100, Steve Harris wrote: > On Sat, Apr 29, 2006 at 12:40:11PM -0400, Dave Robillard wrote: > > On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote: > > > I haven't posted to this thread yet, for a couple of reasons besides the > > > usual lack of time. > > > > > > One reason is that on a technical level I don't have any argument with > > > most of what Steve says. Removing descriptive data from the plugin I > > > think is a good principle. I'm not fond of this Turtle format, it is > > > complicated and I don't find it easily "visually parseable" but it's > > > still better than XML RDF, and so long as you can easily hack someone > > > else's .ttl file to make your own, it probably isn't much of an issue. > > > Technically it all looks pretty much OK. > > > > > > But the other reason is that I don't find much to make me care about the > > > outcome at this stage. This may be a technically better way to design > > > a LADSPA-like plugin API, but until it offers something significantly > > > more useful than LADSPA, that's rather irrelevant to anyone outside > > > this thread. A LADSPA 2 that is the same as LADSPA 1, "technically > > > superior" but incompatible will probably fail. Authors of existing > > > hosts won't want the trouble; plugin authors will put up with the > > > potential extra work of doing LADSPA 1 to get better host coverage. So > > > the aim is to do more interesting things with it afterwards. But what? > > > > The idea is to make LADSPA2 such that new, interesting things can happen > > as extensions without breaking things. LADSPA1 can't do this. > > > > As an example, LADSPA2 of course does not specify anything about MIDI, > > but MIDI processing LADSPA2 plugins can be built if someone defines an > > extension to do so. > > > > Even with major improvements like that aside, the ability to add new > > handy pieces of metadata at will is enough of a win to make it > > worthwhile, IMO. > > > > LADSPA2 itself isn't very exciting, true. But what LADSPA2 will allow > > is the most exciting linux audio thing to happen in a while, if you ask > > me.. > > I think that's Chris's point though. LADSPA2 has a lot of potential, but > why will the users care? > > However I know that at least one plugin developer will port all his > plugins as soon as its finalised, and all the pent up addiditons to LADSPA > people have been wanting for ages, but were just to painful to add can be > applied. I think the promise of the new features (better auto-built UIs > and control randomise are good examples) is enough to make users request > support from host authors. > > These things take time, and I'm not expecting it to be an overnight > success, but there are so many cool things that could be done with a more > capable, but still fundamentally simple spec. Users /don't/ have any reason to be excited about getting LADSPA2 directly. That's irrelevant though. We need a better API with which to build good, useful things. Having that API will allow those good, useful things to be built, which of course benefits users. There are many, many plugins I've been itching to write but LADSPA1 wasn't up to the task (there are still some gaps in LADSPA from what SSM provided natively I intend to fill, for example). Users get their benefit from these new plugins being written. I don't care whatsoever if users care directly about LADSPA2 at this point - I want to build things with it. It's a plugin API, of course users don't care. Users aren't the.. uh, users of API's, developers are. We should build what we as developers would like to use. Screw the users, they'll care later when the benefits trickle down :) -DR- From cannam at all-day-breakfast.com Sun Apr 30 06:37:28 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sun Apr 30 06:36:54 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146351690.3531.9.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <20060429174217.GC1693@login.ecs.soton.ac.uk> <1146351690.3531.9.camel@DaveLap> Message-ID: <200604301137.29284.cannam@all-day-breakfast.com> On Sunday 30 Apr 2006 00:01, Dave Robillard wrote: > We need a better API with which to build good, useful things. So what are those things, and how will LADSPA2 get us to them? I'm not looking for perfect foresight here, just some inspiring examples. Just because one API is easier to extend than another, doesn't mean that it will necessarily happen easily or in a useful way (i.e. with consistent enough coverage from hosts or plugins to be really useful). The logarithmic hint discussion here is an example of that -- it's just about the most trivial thing that can be imagined as an application of an extensible API, yet it's ended up in a lengthy discussion with no consensus so far. Chris From S.W.Harris at ecs.soton.ac.uk Sun Apr 30 07:38:54 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 30 07:39:17 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <200604301137.29284.cannam@all-day-breakfast.com> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <20060429174217.GC1693@login.ecs.soton.ac.uk> <1146351690.3531.9.camel@DaveLap> <200604301137.29284.cannam@all-day-breakfast.com> Message-ID: <20060430113854.GB24665@login.ecs.soton.ac.uk> On Sun, Apr 30, 2006 at 11:37:28 +0100, Chris Cannam wrote: > On Sunday 30 Apr 2006 00:01, Dave Robillard wrote: > > We need a better API with which to build good, useful things. > > So what are those things, and how will LADSPA2 get us to them? I'm not > looking for perfect foresight here, just some inspiring examples. So, examples: Making disconnected ports have sensible behvaiour, eg. making stereo plugins work as mono ones, if only left in and out are connected. Port groups that are identified, eg. marking left and right ins as a pair. So hosts can offer sensible connection options, and distinguish from sidechain inputs. Randomisable control ports (Taybin has been after this for ages). It's a nice way to experiemnt with complex plugins. FFT data inputs, using a struct like { int num_bins; float data[num_bins]; } much more efficient the constant moving in and out of PCM, and makes plugins less complex. > Just because one API is easier to extend than another, doesn't mean that > it will necessarily happen easily or in a useful way (i.e. with > consistent enough coverage from hosts or plugins to be really useful). > The logarithmic hint discussion here is an example of that -- it's just > about the most trivial thing that can be imagined as an application of > an extensible API, yet it's ended up in a lengthy discussion with no > consensus so far. Well, actually the LOG hint is just an example of something that LADSPA1 (arguably) got wrong, and theres no eaasy way to fix it in LADSPA1. The reason it can't be fixed easily is that its far from trivial. Especially seen as noone knows what it means ;) You're right though, just building an extention mechanism is no guarantee that people will use, but if you dont then they don't have the choice. - Steve From musound at jps.net Sun Apr 30 11:49:51 2006 From: musound at jps.net (Sean Bolton) Date: Sun Apr 30 11:48:17 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146328934.2552.18.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> Message-ID: <987c7570eedcce4d6a7a6b8bbe62bd40@jps.net> On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote: > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: >> 4) the run_multiple*() callbacks (how many plugins use these?) > > Silly useless function. Toss it on the trash heap with run_adding. Dave, you complain about people talking down about modular synths, then yourself discount things that are only useful in non-modular designs? How about a little reciprocity here? run_multiple_synths() _is_ useless to any host (like Om), that wants to process an arbitrary connection graph one node at a time. run_multiple_synths() is very useful when a host can run multiple instances of a plugin at once. It provides easy, lock-free sharing of resources across the instances. It allows FluidSynth-DSSI and hexter to both provide a shared pool of voices used across several instances, with _sample-accurate_ voice stealing. It allows FluidSynth-DSSI to easily bolt onto libfluidsynth, and share soundfont data between multiple instances, without the need for a custom soundfont loader. In contrast, I purposely wrote WhySynth without using run_multiple_synths(), just to see how difficult the resource sharing would be. Nasty mess of mutexes and try_locks().... All of this is not to say that run_multiple_synths() doesn't have some real PITA issues. But that's a discussion better had over on dssi-devel. -Sean From drobilla at connect.carleton.ca Sun Apr 30 11:56:06 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 30 11:56:34 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060430113854.GB24665@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <20060429174217.GC1693@login.ecs.soton.ac.uk> <1146351690.3531.9.camel@DaveLap> <200604301137.29284.cannam@all-day-breakfast.com> <20060430113854.GB24665@login.ecs.soton.ac.uk> Message-ID: <1146412566.3531.12.camel@DaveLap> On Sun, 2006-04-30 at 12:38 +0100, Steve Harris wrote: > On Sun, Apr 30, 2006 at 11:37:28 +0100, Chris Cannam wrote: > > On Sunday 30 Apr 2006 00:01, Dave Robillard wrote: > > > We need a better API with which to build good, useful things. > > > > So what are those things, and how will LADSPA2 get us to them? I'm not > > looking for perfect foresight here, just some inspiring examples. > > So, examples: > > Making disconnected ports have sensible behvaiour, eg. making stereo > plugins work as mono ones, if only left in and out are connected. > > Port groups that are identified, eg. marking left and right ins as a pair. > So hosts can offer sensible connection options, and distinguish from > sidechain inputs. Similarly, distinguishing 'audible' ports from 'CV' ports, allowing a lot more (eg filter) plugins to run in Ardour. -DR- From drobilla at connect.carleton.ca Sun Apr 30 11:59:25 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 30 11:59:51 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <987c7570eedcce4d6a7a6b8bbe62bd40@jps.net> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <987c7570eedcce4d6a7a6b8bbe62bd40@jps.net> Message-ID: <1146412765.3531.15.camel@DaveLap> On Sun, 2006-04-30 at 08:49 -0700, Sean Bolton wrote: > On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote: > > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: > >> 4) the run_multiple*() callbacks (how many plugins use these?) > > > > Silly useless function. Toss it on the trash heap with run_adding. > > Dave, you complain about people talking down about modular > synths, then yourself discount things that are only useful in > non-modular designs? How about a little reciprocity here? [snip] ... a simple "I need it" would have been fine. ;) -DR- From musical_snake at gmx.de Sun Apr 30 12:25:51 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Sun Apr 30 12:35:47 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <200604301137.29284.cannam@all-day-breakfast.com> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <20060429174217.GC1693@login.ecs.soton.ac.uk> <1146351690.3531.9.camel@DaveLap> <200604301137.29284.cannam@all-day-breakfast.com> Message-ID: <4454E50F.7020801@gmx.de> Chris Cannam schrieb: >On Sunday 30 Apr 2006 00:01, Dave Robillard wrote: > > >>We need a better API with which to build good, useful things. >> >> Use LACPA instead of LADSPA ;-) It has * audio i/o support * sample accurate midi i/o support * controls with midi mapping * timeinfo support: tempo/beat/bar + samplenumber * automatic plugin gui builder support through simple ascii file * network capable (gui can run on different machine than plugin engine) * return to host the real value as a string instead of some fancy hints (=> good for displaying automation data) * has named audio and control i/os * fixed 2^x length buffersize when processing The default configuration is in a simple ascii file with some even simpler format: First line contains the field delimiter used for this file, rest is in the following format: type:name:displaytype:[num:[values]]:midi controller type:midi controller number : <- delimiter to use in this file audio:left in audio:right in audio:sidechain control:Gain left:slider:cc:1 control:Gain right:slider:cc:2 control:Link:pushbutton:cc:3 <- 7bit resolution with single CC control:Frequency:slider:cc:msb:4:lsb:5 <- 14bit resolution using 2 CCs control:Type:radiobutton:2:Mono:Stereo:nrpn:7 <- 14bit resolution through NRPN and so on. All audio data is -1.0 .. 1.0, all control data is 0.0 .. 1.0. There are no min/max values needed, because the plugin knows itself what the value is and the host can request a string representing the actual value + unit for display purposes as needed (same for plugin gui) example: host requests control 1, value 0.5 plugin returns "0.5 dB" For timeinfo i dropped smpte because its is trivial to calculate a smpte frame from the samplenumber and can thus be calculated by the plugin needing smpte synchronisation itself. Ralf PS: the lacpa.h i sent earlier to the list is outdated (and wouldn't even compile) From wsynth at gjcp.net Sun Apr 30 13:15:14 2006 From: wsynth at gjcp.net (Gordonjcp) Date: Sun Apr 30 13:18:37 2006 Subject: [linux-audio-dev] Re: "LADSPA 2" name In-Reply-To: <73802df70604261617o44d0a20co7a93d2aa39a19b41@mail.gmail.com> References: <20060426081018.0528612E8FE0@music.columbia.edu> <1146086739.14289.128.camel@localhost> <444FEC4A.6020504@boosthardware.com> <73802df70604261617o44d0a20co7a93d2aa39a19b41@mail.gmail.com> Message-ID: <4454F0A2.5020301@gjcp.net> grae wrote: > If it were to change to LAP (just for example), then just do a google > search for "lap" and compare the accuracy and you'll clearly see my > point. If I was making "dance" music and I wanted to search for "lap" plugins, I'm *damn* sure I wouldn't be hitting "I'm Feeling Lucky" Gordon. From S.W.Harris at ecs.soton.ac.uk Sun Apr 30 15:49:35 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Apr 30 15:49:55 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146412765.3531.15.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <987c7570eedcce4d6a7a6b8bbe62bd40@jps.net> <1146412765.3531.15.camel@DaveLap> Message-ID: <20060430194935.GB1592@login.ecs.soton.ac.uk> On Sun, Apr 30, 2006 at 11:59:25 -0400, Dave Robillard wrote: > On Sun, 2006-04-30 at 08:49 -0700, Sean Bolton wrote: > > On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote: > > > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: > > >> 4) the run_multiple*() callbacks (how many plugins use these?) > > > > > > Silly useless function. Toss it on the trash heap with run_adding. > > > > Dave, you complain about people talking down about modular > > synths, then yourself discount things that are only useful in > > non-modular designs? How about a little reciprocity here? > [snip] > > ... a simple "I need it" would have been fine. ;) On the contrary, some people have said "I need it" to the LOG hint, but it's still not the right thing ;) - Steve From drobilla at connect.carleton.ca Sun Apr 30 18:39:05 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Apr 30 18:39:36 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060430194935.GB1592@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <987c7570eedcce4d6a7a6b8bbe62bd40@jps.net> <1146412765.3531.15.camel@DaveLap> <20060430194935.GB1592@login.ecs.soton.ac.uk> Message-ID: <1146436745.7674.4.camel@DaveLap> On Sun, 2006-04-30 at 20:49 +0100, Steve Harris wrote: > On Sun, Apr 30, 2006 at 11:59:25 -0400, Dave Robillard wrote: > > On Sun, 2006-04-30 at 08:49 -0700, Sean Bolton wrote: > > > On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote: > > > > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: > > > >> 4) the run_multiple*() callbacks (how many plugins use these?) > > > > > > > > Silly useless function. Toss it on the trash heap with run_adding. > > > > > > Dave, you complain about people talking down about modular > > > synths, then yourself discount things that are only useful in > > > non-modular designs? How about a little reciprocity here? > > [snip] > > > > ... a simple "I need it" would have been fine. ;) > > On the contrary, some people have said "I need it" to the LOG hint, but > it's still not the right thing ;) That doesn't change the fact that we need it... I'm okay with taking it out of the core spec for the usual reasons, as long as something is going to come along soon that fills the gap. I can't stress enough how much this is needed. MIDI binding is a useless user nightmare without some sort of logarithmic hint. Since you took it away, Steve, you'll be the one to define that nice extension for us, right? :] -DR- From wsynth at gjcp.net Sun Apr 30 18:49:32 2006 From: wsynth at gjcp.net (Gordonjcp) Date: Sun Apr 30 18:53:02 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <1145603686.4773.5.camel@localhost.localdomain> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> <1145603686.4773.5.camel@localhost.localdomain> Message-ID: <44553EFC.1010507@gjcp.net> Jan Weil wrote: > Am Donnerstag, den 20.04.2006, 21:48 +0200 schrieb Lars Luthman: >> How about a machine-friendly interface for searching and downloading >> plugin tarballs (or references to distribution packages) so one could >> write a tool like CPAN for LADSPAs? An automated way to download and >> install plugins would be really useful if it could be integrated into >> software like Om, Ardour, JACK-rack etc. Scenario: you try to load a new >> Om patch that you downloaded from the net, you get the message "You >> don't have the 'foo' plugin, do you want to install it?", click Yes, and >> a few seconds (or minutes) later the plugin is installed and the patch >> is loaded. > > AFAIK most plugins don't have any dependencies. Is there anything wrong DSSI ones may do. It depends what toolkit their GUI was written in. Gordon From larsl at users.sourceforge.net Sun Apr 30 20:13:00 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Apr 30 20:13:16 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060429172520.GB1693@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> Message-ID: <1146442381.8629.26.camel@localhost> On Sat, 2006-04-29 at 18:25 +0100, Steve Harris wrote: > On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave Robillard wrote: > > > With the port types specified in the RDF file, MIDI input should be > > > doable with explicit LADSPA2 ports of some defined MIDI type, which > > > means that we wouldn't need the run_synth() callback. The GUI > > > specification and the OSC protocol is already pretty much applicable to > > > LADSPA as well as DSSI, so that should work in LADSPA2 too. New > > > additions like MIDI output and transport info could also be done as port > > > types. > > > > > > The things that aren't obvious how to do are > > > > > > 1) the configure() callback > > > > OSC message. > > Thats a little laconic, even by my standards :) To my mind the key thing > about configure() is that it happens outside the RT context, and > LADSPA-style plugins have no easy way of running an OSC server of thier > own. > > > > 2) the dynamic program lists and midi mappings (static definitions > > > could be written in the RDF file, but that's no fun) > > > > That's a tougher one. > > Control port :| Not really - plugins only get to write to the control ports in the run() callback (or select_program() for DSSIs), and it's entirely possible and plausible that a program would want to list the available programs for a plugin before it starts running it's audio callback. Would it be possible to change the instantiation function from LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, unsigned long SampleRate, const char* BundlePath, const char** HostFeatures); to something like this: LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, unsigned long SampleRate, const char* BundlePath, const char** HostFeatures, void** HostFeatureData); where HostFeatureData is a NULL-terminated array of the same size as HostFeatures, containing feature-specific data that the plugin can read and/or write. Then, if HostFeatures[3] is "PROGRAM_LIST_CALLBACK", HostFeatureData[3] can point to a 'const DSSI_Program_Descriptor *(*)(LADSPA_Handle, unsigned long)', i.e. a DSSI program list callback pointer, and the plugin can set it to point to its program list callback. Or you could define a "DSSI" host feature and a struct similar to the current DSSI_Descriptor with configure(), get_programs(), get_midi_controller_for_port() etc and pass a pointer to that instead. I don't see any other obvious way to let future extensions add their own callbacks (except for specifying a function name in the RDF file and then dlsym()ing that symbol name in the host). -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060501/4e632aea/attachment.bin