Re: This ladspa-rdf stuff works? Was: Re: [linux-audio-dev] TAP-plugins reverb presets

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

Subject: Re: This ladspa-rdf stuff works? Was: Re: [linux-audio-dev] TAP-plugins reverb presets
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Fri Mar 05 2004 - 22:30:46 EET


On Fri, Mar 05, 2004 at 08:15:24 +0100, Dr. Matthias Nagorni wrote:
> We do not lose anything if we accept either the proposal by Tim or Fons or
> something in between. Both proposals are binary compatible with the
> current standard. Plugin-writers and host-developers would still have the
> choice to use the extension or to ignore it and use e.g. the RDF extension
> instead. And I doubt that new plugin writer get scared by some slightly

I dont see the value in two parallel solutions. I still dont see that
scales/enumerations are an essential LADSPA feature:

        We've got on without them for 4 years (bar TAP reverb preset
        selection, but that is a mis-implementation IMHO).

        I can't think of any hosts that need enumerations but not RDF for
        other things (accurate defaults, presets, categorisation).

        Enumerations are metadata, const values in structs are metadata.
        Encoding metadata in binary formats inside objects is bad practice.

> extended ladspa.h, at least as long as it keeps to be as well-documented
> as it is now. I will now shut up and hope that an extension will be agreed
> upon. Once Tom (and hopefully others) follow the new standard, I will
> update AMS. And keep in mind: Extending LADSPA does not mean that all
> plugins need to be modified. It's only that cases like e.g. the reverb
> presets can be fixed in a clean way.

This has nothing to do with fixing the reverb preset problem, that is a
seperate problem. Using enumerations (of any kind) to do that will still
not work correctly.

- Steve


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

This archive was generated by hypermail 2b28 : Fri Mar 05 2004 - 22:29:58 EET