RE: [linux-audio-dev] New LADSPA Version - Issues Resolved?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] New LADSPA Version - Issues Resolved?
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: to maalis 09 2000 - 05:33:05 EST


On Thu, 9 Mar 2000, Richard W.E. Furse wrote:

> Well, MN is written in C++ and will hopefully load up LADSPA plugins. I'd

Btw; what's the story behind MN? Last time I looked, the sources were not
available. ... anyway, definitely an interesting package. :)

> rather assumed that wrapper chunks in C, C++ or whatever would be
> host-dependent - but perhaps I should provide a basic framework class. Did

I guess writing a generic C++ wrapper is not necessary (at least at this
point). But still, I'm interested in discussing about the details. Basicly
I'd like to hide all the messy dynamic loading code behind a user-friendly
(and tested!) class interface. You could have functions like "vector<string>
available_plugins(void)" and "LADSPA_OBJECT* create_plugin(const string&
name)", etc ... But like in ecasound's case, the problematic part is
data input/output. It's very application specific.

> you have particular concerns in mind? (e.g. linking dynamically loading C
> against C++ - which I've not had a go at yet!)

Hmm, this shouldn't be too difficult as long as you keep C and C++
clearly apart. LADSPA object would simply have a "struct
LADSPA_Descriptor" as class member, and this way your current C-code
can be used without much change. I'll try to test this as soon as I
have some free time.

> I must admit I've stayed away from the STL because of lack of control of
> what happens inside it. If (i.current()) etc is the only way you can access
> the data in the buffers then it does sound like you're going to have to
> copy buffers. But I can't think of any way an API could get around this
> problem short of using STL itself - which would break the system for
> everyone else.

Actually data hiding has been my primary goal. Only the sample buffer
class itself knows about the actual data representation (currently a
STL vector). I'm free to rewrite the whole buffering system (or even
mix different buffering systems), without having to rewrite any effect
code. As for the plugin API, the current lowlevel approach is much better.
High-level (abstraction-wise) communication between apps still seems
to be difficult. Although we have various standards (CORBA, various
*OMs), plain C APIs, files, sockets and pipes still seem to work
better in practise.

Anyway, my biggest concern at the moment is whether I should
allow users to use multiple LADSPA plugins as a single ecasound chain
operator. This would minimize extra buffer copying with complex
(LADSPA) setups. Hmm, I have to think about this some more.

-- 
Kai Vehmanen <kaiv_AT_wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux multitrack audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:05 EST