On Wednesday 04 September 2002 13:28, Tim Goetze wrote: > >Isn't this where the audio servers such as aRts have hoped to do > >business too? > > i don't know much about aRts, but from what i have heard it isn't > 100% clean realtime, and it's based on a particular programming > toolkit that not everybody wants to link against.
aRts is a bit schizophrenic - it wants to be a multimedia framework for thin "player" clients as well providing low latency audio and MIDI for sequencers as well as being a central repository for plugins. Recent discussions to address the basic conflicts of interest have highlighted the problems and are seeking to address them but I don't think it's going to be happening any time soon - and whatever it is it's not going to be a single solution/process anymore. > paul d is known to be fond enough of code reuse to not invent the > wheel twice, and we have both jackd and aRts. i take this to support > my conclusions. No I quite agree. I was just drawing a comparison because while to a certain extent implementing plugins at the server for aRts was a boon to thin client multimedia apps this came at the expense of applications that wanted a little more control (such as sequencers). I didn't want to see history repeating itself but then again I was already pretty sure that it wouldn't. [JACK and plugins] > of course this needn't strictly be integrated with jack. otoh, > combining it with a system-wide timebase opens up another dimension. Ok, this is kind of what I was getting at. So in effect what we could do right now is simply come up with our plugin abstraction layer straight away without waiting for JACK to implement anything else? Whilst the implementation of where plugins sit is something for tomorrow - today we can say _this_ defines our plugin interface and create (toolkit specific) libraries that understand this abstraction and implement them for qt or gtkmm etc. Indeed for the moment this is kind of what I've done for RG - I've just created a wrapper for LADSPA that's essentially just got the types abstracted (typedef float PortType) and encapsulated in hierarchy and that sits over LADSPA and talks abstract plugin language to the main gui. As this would be part of the exercise outlined in the above paragraph anyway perhaps it's worth implementing a LADPAL (Plugin Abstraction Layer) and its toolkit equivalent libraries now anyway? Or did I miss something important? I probably did. B
