[linux-audio-dev] Todays "LADSPA2" update

[Steve Harris]

On Wed, Apr 26, 2006 at 07:05:20 -0400, Paul Davis wrote:
> On Wed, 2006-04-26 at 11:51 +0100, Steve Harris wrote:
> > I've written a first cut at an ontology/schema for the plugin RDF:
> > http://plugin.org.uk/ladspa2/ladspa-2.ttl
> > 
> > The term schema is a bit misleading, as it doesn't really enforce
> > anything, it really just gives you some hints about what to write. The
> > bulk of it is english text to explain the meaning of the bits that are no
> > longer in the .h
> > 
> > I tried to write it as clearly as possible, but the machine readable parts
> > might still be a bit cryptic and there could be errors. Shout if there's
> > any bits that don't make sense.
> 
> i know you didn't want to actually change much of the spec, but i would

yeah *cough* I did actualy change one thing, I droped the last clause of
the integer hint, because it Makes No Damn Sense. The bit that recommends
that you overshout the bounds you actually want, so that theres no
rounding problems. the host has to do that, the plugin can't second guess
how much leeway the hosts UI needs for rounding, and if the plugin rounds
to nearest integer it all comes out in the wash anyway.

Meant to say I'd done that, but forgot.

> like to protest at the continued inclusion of the "logarithmic" port
> hint. its totally useless. at the very least, the hint should be removed
> and replaced by two other hints: logarithmicE and logarithmic10. saying
> that something might be better viewed using a logarithmic scale really
> says nothing useful. a more satisfactory solution would add "dBFS" to
> indicate that the port contains values indicating volumetric or gain
> levels. something like that.

logarithmicE and logarithmic10 have the same effect (loge(x) = constant *
log10(x)). But yes, I agree, its very wierd. I'm happy to ditch that hint.
the only thing where it does anything like the right thing on is
frequency, and there it is tricky as you can't *quite* go down to 0.0, but
specifying how close to is a bit of a crapshoot - it generally depends on
the sample rate.

Immediatly after the spec is finished I will publish an extension that
does real units stuff on controls, so hosts can intelligently handle dBFS,
frequency and so on.

For the record, I'm happy to drop features (many have got the chop), its
adding things that I want to avoid. It's very hard to test features
properly at this stage, so adding new ones is risky.

Paul, while I've got your attention, are you OK with droppping runAdding?
You're the person who most likly to have implemented it I think.

99% of my plugins support it, but it would have made my life much easier
if they didn't.

- Steve