RE: [linux-audio-dev] MuCoS, Glame, API Issues

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

Subject: RE: [linux-audio-dev] MuCoS, Glame, API Issues
From: Richard Guenther (richi_AT_student.uni-tuebingen.de)
Date: ke maalis 08 2000 - 05:08:38 EST


On Wed, 8 Mar 2000, Alexander Ehlert wrote:

> Hi Richard,
>
> > with the minimum of wrapping. No threads, no sockets (the host is free to
> > use these if it wants), no events, even only one data type (float).
>
> It would be no problem to introduce a property, where the plugin actually
> defines the datatype it wants to use and the host would have to do the
> right conversion. Wouldn't complicate ladspa too much I think.

Uh, no - better use floats everywhere, _if_ conversion is necessary just
create a conversion plugin.

> > The current state of this is visible (messily, just to save posting it to
> > the list all the time) at http://www.muse.demon.co.uk/ladspa.html. How
> > would you feel about also supporting this API in Glame? - are there any
> > tweaks you could suggest that would make it simpler for Glame to use
> > without breaking it for other people?

No, the API looks very strange to me, especially the "host controlled"
LADSPA_Data * DataLocation per connection!? what is this for (see
alexanders question below, too)??
Its definitely not possible to wrap around such a plugin inside glame
without breaking all the fun stuff of glame. You can of course set up
all the plugin in one thread, and everytime copy glames buffers to
LADSPAs DataLocation. But as I said in my previous mail - this "how
do we communicate, how does our buffer handling look like" is very special
to every engine - you cannot merge them easily without requiring to just
exchange one engine for another.

> It should be no problem to write a wrapper for ladspa plugins. But I just
> like to know how you handle the case, when the output buffer is larger
> than the input buffer, when you use effects like echo, delay, etc. The
> host would have to send an extra zeroed buffer, that has for example the
> size of the ringbuffer that has to be emptied. The host should be able to
> query that, if not the host could still sent zeroed buffers and check if
> they're coming back empty, but somehow I don't like the latter one.
>
> Cheers, Alex

Yes, this is also a valid point, especially as this case is not documented
anywhere?

Please people, read some of the glame source - f.i. try the following URL
to look at some simple filters:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/glame/src/filter/basic_sample.c?rev=1.7&content-type=text/x-cvsweb-markup&cvsroot=glame

Richard.


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST