Re: [LAD] [RFC] LADSPA 1.2

Krzysztof Foltman wrote:

> // this gives us text-to-string for arbitrary floats (side effect of
> which is being able to implement enums)
> const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
> float value);

> // this tells us which float values have "interesting" meaning
> void ladspa_get_scalepoints(LADSPA_Descriptor *descriptor, int port, /*
> [out] */ float **values, /* [out] */ int *values_count);

> For completeness (I'm probably starting a flamewar here) we might also
> have a reverse function, like:
>
> float ladspa_parse_value(LADSPA_Descriptor *descriptor, int port, const
> char *value, const char **error);

I'd be very happy to see this functionality too.
This (for me) would allow the removal of just about all parameter conversions
from the run function and just do them for display. (ie keep parameters native
as I don't have to worry about exposing internal values to users anymore). It
actually solves a whole lot of issues as we don't have to rely on hints to fine
tune the display of parameters.

While ideas are being tossed about, here are some more...
Do you think it would be possible to give the plugins some mechanism to
interrogate the host without breaking compatibility with ladspa v1.1? The things
I'd like to be able to find out about a host is for example:
* The current time signature and tempo (can be null when irrelevant)
* The language of the users environment (since we can format the parameters now)
* The application's name & version
* The application's ladspa version

//HostItems
//values
#define LADSPA_HOST_TEMPO 0x01 // 89.5
#define LADSPA_HOST_METER_BEATS 0x02 // the 3 in 3/4
#define LADSPA_HOST_METER_LENGTH 0x03 // the 4 in 3/4
#define LADSPA_HOST_LADSPA_MAJOR 0x04 // 1
#define LADSPA_HOST_LADSPA_MINOR 0x05 // 1
//strings
#define LADSPA_HOST_NAME 0x10 // "Crazy App"
#define LADSPA_HOST_VERSION 0x11 // "0.1.5"
#define LADSPA_HOST_LANGUAGE 0x12 // "en_AU.UTF-8"
#define LADSPA_HOST_LADSPA_VERSION 0x13 // "1.1"

float ladspa_get_host_value(LADSPA_Descriptor *descriptor, int HostItem)
const char *ladspa_get_host_string(LADSPA_Descriptor *descriptor, int HostItem)

The other thing I'd like to see is factory presets in RDF format. correct me if
I'm wrong but the current rdf schema only allows for preset "control ports"
which associate a preset name with an index. the actual values are "elsewhere"
(usually in code).

I mean something more like this (pseudo code)

<ladspa:Presents rdf:about="&ladspa;9999">
  <ladspa:PresetDef rdf:value="0" ladspa:hasLabel="Sick Delay">
    <ladspa:ControlValues>
      <ladspa:Control rdf:about="&ladspa;9999.0" rdf:value="1" />
      <ladspa:Control rdf:about="&ladspa;9999.1" rdf:value="0.4" />
      <ladspa:Control rdf:about="&ladspa;9999.2" rdf:value="99" />
      <ladspa:Control rdf:about="&ladspa;9999.3" rdf:value="-6" />
    </ladspa:ControlValues>
  </ladspa:PresetDef
  <ladspa:PresetDef rdf:value="1" ladspa:hasLabel="Long Delay">
      <ladspa:ControlValues>
      <ladspa:Control rdf:about="&ladspa;9999.0" rdf:value="1" />
      <ladspa:Control rdf:about="&ladspa;9999.1" rdf:value="2.5" />
      <ladspa:Control rdf:about="&ladspa;9999.2" rdf:value="0" />
      <ladspa:Control rdf:about="&ladspa;9999.3" rdf:value="0" />
    </ladspa:ControlValues>
  </ladspa:PresetDef>
</ladspa:Presents>

With some sort of standardised format we'd also be able to share user generated
presets between applications. (and each other)

regards,
Fraser
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 19 20:15:03 2009