Hi, Could it be more useful to have this ported to LADSPA? I am not familiar with the application nor the LADSPA API so please excuse me if this is a stupid idea. I sure would like a nice EQ plugin with a nice GUI. Regards On Wed, 2003-08-13 at 02:25, Erik de Castro Lopo wrote: -- antoine rivoire <antoine.rivoire(a)ntlworld.com>

Hallo, Steve Harris hat gesagt: // Steve Harris wrote: I think it best would be a Jack app (next to freqtweak) ciao -- Frank Barknecht _ ______footils.org__

Dave Phillips <dlphilp(a)bright.net>et>, on Wed Aug 13, 2003 [06:39:04 PM] said: Hi; What is 'ALport' and 'ALconfig', and where are they defined? Paul set(a)pobox.com

Martijn Sipkema wrote: Actually they are available for Linux. Richard Kent, author of the DAP soundfile editor, ported the SGI audio library quite some time ago. His work is called 'tichstuff' and is available here: ftp://mustec.bgsu.edu/pub/linux/tichstuff.tar.gz It includes libaudio and libaudiofile. I keep it in /usr/local/lib/tichstuff and /usr/local/include/tichstuff to keep it separarted from Michael Pruett's better-known libaudiofile port. Richard's work has been most valuable in porting SGI sound software to Linux. See this article for an account of its use in an older porting project: http://www.linuxjournal.com/article.php?sid=3007 Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org

"Kjetil S. Matheussen" wrote: Unfortunately libaudiofile doesn't address the particular problem, and Michael never ported libaudio. Kjetil, you have considerable experience porting SGI audio software to Linux: would you be interested in looking at Dan's code ? I'm sure you could see how to resolve the difficulty with SoundIn.h (it's written for SGI audio I/O). Best regards, == dp

Hello Gang, Would like to respond to Pete Yadlowsky... |I'm new to this mailing list, though not especially new to computer music. I |was heavily involved in it some years ago, mainly on the NeXT platform, then |fell away. Out of curiousity, I recently decided to look around and see what |was available today for Linux, audio-wise. I myself am dabling with the realm of audio under a 2.6 pre-test kernel right now on a linux system that I have been compiling my own source code on from 1997. I have had great success and would like to share my thoughts and experiences with you since I think that is the purpose of this discussion group. I have also developed my own graphical object oriented X Windows widget set using C++ that is quite effecient and simple so that I could get some things done. It has slowly been evolving to something quite nice. |One of the items I found was LADSPA. "A standardized interface for audio |plugin units carried in shared libraries," thought I. "Interesting idea." I |took a closer look at LADSPA and, like any happy programmer, decided that |there are some things about it that I'd do differently. So, to flesh out and |test my ideas, and just for fun, I proceeded to build a LADSPA-inspired |plugin system of my own. I'm writing now to present these ideas in the event |that someone may find a few of them useful, and to perhaps contribute to |LADSPA's evolution: I as well like the use of shared object libraries since it is not practical to statically link every conceivable modue into a large executable. Modularity is very important for expansion but it must appropriately planned to ensure that control over the process is maintained. |- I've done away with the distinction between control signals and audio |signals. I understand the performance gains to be had by computing one class |of signals less often than another, but I feel this is a hold-over from days |when computers were much slower than they are now. In my ideal system, |signals are signals and any signal should be potentially applicable to any |purpose. I don't want to be bothered with control vs. audio, either |conceptually or in actual code. Early on I adopted this approach but have changed my ways as I traveled down the path for a few reasons. Actually, I have made the distinction of a control signal versus an audio path for the sake of patching. A control signal in my system is primarily a single channel signal but has all the characteristics of a single audio channel. The audio channel is actually a stereo 2x channel. When patching the audio processes together it has helped to have this distinction so that I do not have to manage stereo audio channels as separate "control" paths. I have a module that will take a single "control" channel and allow you to pan is across into a "audio" channel. Likewise I have a module that sums the two channels of an audio path into a single "control" channel. It has actually been less of a bother this way then trying to deal with all those single channels in a standard audio processing chain and is actually a necessity when dealing with stereo reverb and other effects that use a stereo signal path (like rotary speaker emulation). I would also like to say that I have looked at the Jack and LADSPA signal paths and I believe they are single precision floating point numbers. I personally have adopted the double precision format and have done extensive benchmark tests and have found no degradation in performance but I can hear the difference slightly on some of the sounds I have created (extremely minor differences). I have found that most of the C library routines that I use for math are double precision and not being the most adept programmers, could not see doing it any other way so I did some testing and I found the double to be the best way to go with no sacrafices. |- Somewhat related to the item above, a plugin's run() method computes exactly |one sample at each call, not a block of samples. This is again a matter of |conceptual simplification. I don't want the individual plugin to have to know |anything of process iteration; that job is for the containing infrastructure. |Also, some years ago I started working on some computer synthesis software |and found that when units ("plugins") computed samples in blocks (instead of |one at a time), there was a strange behavior when these units were patched |together in looped delay line configurations. As I recall, gaps would appear |in the audio output, and these gaps would grow in length as the loop |proceeded. I don't remember if I ever discovered the exact cause, but I think |it had something to do with the relationship between the length of a block of |samples and the length of the delay line. Maybe I was doing something wrong, |but going to a one-sample-per-run process made the problem go away. I wanted |the flexibility of being able to patch units together in any sort of |topology. I would like to comment on this as well. The audio and signal path objects that I have described actually have the number of samples contained within a packet object and these are passed between the objects. The reason for this is so that I can tune the number of samples in each packet to the job at hand. When an audio or control packet is "used up" then the run() function will fetch another and the size value is adjustable based upon a system value but can also be adjusted at the module level. My reasoning for doing this is to provide a mechanism to balance the speed of a patch against its latency characteristics. I have found that a single sample has the lowest latency, especially in feedback loops, but the overhead in evoking the run() through the signal paths effectively reduces the throughput. By enabling a small buffer on each packet, a single run() request can queue up multiple samples which quickly improves the performance of the patch on the process but introduces some latency into the system. My reason for a variable here is so that I could primarily experiment with acceptable and unnoticable latency versus processor overhead. A note on looped delay lines. I have not experienced any strange side effects of buffering multiple samples in a looped delay with the implementation I describe. |- Every input port is a mixer/modulator. Since the operations of mixing and |modulating (multiplying) signals together are so often needed, I decided to |build them into plugin input ports. A given input port can accept any number |of connections from "feeders" and either mixes or modulates their outputs |transparently, according to the port's configuration. I believe this |simplifies use of the system and eliminates the need for a special |runAdding() plugin method. This is an interesting concept to me and in many cases is an issue of interface design as the implementation still results in signals added. On my interface, if I connect two outputs into a single input then the interface places a little "plus" sign in front of the input port. By clicking on the plus sign (it has a little circle around it as well) it will open up a module with a volume slider for each channel connected and there is a button to change the "+" into an "X" for modulation. Internally though, I create a separate module that is "auto-patched" into the patch for two reasons; 1) I dont incur the overhead of a summation or modulation process if there aren't two signals to contend with and 2) I do not burden the module code writer with the additional task of dealing with the process of summation or modulation of multiple inputs. It has just greatly simplified the code process and it is an interface issue as far as I am concerned. Also, in my system, attenuation or volume control is achieved by this mixing process so you can invoke a single channel mixer for the purpose of volume control where the volume is actual accomplished via a modulation ("X") process from an external control value. A "1.0" is normal volume, ".5" is half volume, etc. Thanks for sharing your ideas, I hope I have provided some insight and thanks for giving me the opportunity to listen to your ideas and respond.

down control system want I've innate do sense is blocks me can Sounds interesting. My system is similar but my audio paths are still stereophonic due to the large number of modules that rely on stereo pairs and you can always assign "control" channels to deal with an exception. I have a delay module that I have been working on that provides multile audio paths as you describe but the output is still in pairs. Ultimately I mix down to stereo anyway (I only have two ears). I know some audio systems support 6 channels for professional use but they are arrange in three stereo pairs. personally No difference according to my benchmarks - 0 difference objects summation initialized to with provided structure feeders' and experimentation, of partly wringing get sound I am a real time musician and I like the real time performance myself. I also like those old analog modular synthesizers with patchcords and knobs hanging all over the place and have never had the fun or precision in setting up a sound with digital synthesizers on the market today (although I love my Korg ProTrinity X 8^) ). My interest is in real time response to keyboards and other controllers using (yuck) MIDI for now. LADSPA is interesting but I do not see where it handles some of the issues of polyphonic voicing and assignment control. Soundslike you are having fun exploring the possibilities. Keep me informed of your progress. There are a great number of audio software elements out there and it is your sharing of ideas that brings new fruit to the table. Do not be discouraged by those that tell you that we already did it and why don't you use that. They are missing the point, aren't they! 8^) Now go make noise.

On Thu, Aug 14, 2003 at 01:24:50AM -0400, Paul Davis wrote: It's like designing a new windowing system. You MIGHT do better, but lots of really smart people have done worse. I'd actively beg that anyone who has a lot of thoughts on this PLEASE catch up on GMPI and join in the fray. The XAP ideas have actually been pretty well received so far, and the LAD community is doing a lot to stop the Mac and Windows people from screwing this up yet again (Paul, Steve - my thanks!). I too started my own plugin API to replace LADSPA for multichannel IO and instruments etc. It's a BIG problem to do really right. I think XAp had some REALLY clever ideas come out of it. GMPI is sanctioned by the MMA - if ANYTHING has a chance at succeeding cross-platform, that is it. Yes, it is a SLOW process. Yes, you'll have to make concessions to Windows developers. But in the end, you might just have a real winner of an API. Tim

On Thu, Aug 14, 2003 at 09:48:45AM +0100, Steve Harris wrote: This is a bit harsh, sorry, I didn't mean to be so negative. I'd been having a bad day. - Steve

On Thursday 14 August 2003 01:00 am, Brad Arant wrote: I'm presently dealing with polyphony at the Python level (Python bindings for my LADSPA-like system). I think so. I could buy all my carrots at the local supermarket, but then I wouldn't have the gratification of raising them myself. Also, there's always the possibility of digging up something new and interesting in even the most heavily trampled places. - Pete

LADSPA's evolution is most likely to take place within the context of GMPI (Generalized Music Plugin Interface), a cross-industry attempt to define a new platform and vendor independent audio/MIDI plugin API. it will be slow, but there isn't a lot of point in doing much more than tweaking LADSPA for now. note that LADSPA was originally designed to be a "least common denominator" among numerous fractured app-specific audio plugin APIs. it has served this purpose extremely well, and i think most of its contributors, users and developers would be inclined to leave it that way :) Sure, in your ideal system. In my ideal system, I'd love to be able to do real-time physical modelling of a full string orchestra, and add in real time convolution-based reverb to model the hall. But in any real system, there are always limits, and even on the recent 2.4GHz dual athlon system i tested recently, its completely *trivial* to overload the CPU with audio synthesis and processing. perry cook's SDK does this too. everybody knows its cool, just as everybody knows its incredibly inefficient. you have 100% of the overhead of a chain of function calls for every sample. for anything except trivial processing, its too expensive to be useful for a general purpose API (for now). if you read "the computer music tutorial" by curtis rhoads, you could avoid discovering this, and instead read about what people have done to tackle the problem since it was noted 25-30 years ago :) per-sample processing isn't a feasible option as a general API model for, oh, i'd guess at least another 3-4 years. and many operations that want to work in the frequency domain require blocks anyway, and so are not helped by this design. JACK (http://jackit.sf.net/) does this too. its a very nice design, although it has its downsides. --p

On Wed, Aug 13, 2003 at 08:09:19 -0400, Paul Davis wrote: So does sfront, SyncModular and and lots of hardware systems. You can do it efficiently in software if you downcompile the modules to a processing loop at runtime, c.f. the linuxsampler project. The is an area where we can really beet the closed source guys as we have no issues with giving away out DSP code. NB nor by the current design of blocked systems, the FFT, WSOLA, etc. requirements are a bit odd. My suspicion is that runAdding et al is just unneccesary (c.f. cache effects), but I haven't benchmarked it. - Steve

On Thu, Aug 14, 2003 at 03:00:51PM +0200, Ingo Oeser wrote: Well, if youre working in a modular you might not want it recompiling after every connection. And you could have the eqivalent of interpreting where the blocks are run like plugins, and only downcompiled when you tell it to (like in SyncModular). Right, but it wouldn't be able to downcompile commercial stuff, cos they wouldn't make the source available. Yes, its a significant win for blockless processing, less for for blocked, but I expect its still worthwhile. - Steve