Subject: Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
From: Paul Davis (pbd_AT_op.net)
Date: Thu May 30 2002 - 14:18:20 EEST
>i guess it is safe to say that '*DataLocation = default' is simple:
>it is simple to implement in a plugin for sure. it is reasonable for
>hosts not to care about the default value at all. it gets the
>efficiency bonus for being capable of expressing any value from the
>valid range while saving many lines in <ladspa.h>. it makes, as conrad
>parker showed, the dynamic creation of sane values possible if you
>stretch the meaning of 'to connect' a bit, and above all: it is
>easy to explain and understand.
all good.
the problem has been, always, to define *when* the plugin does this
operation. lets see what's available:
* before loading: impossible, no plugin object exists
* right after loading: impossible, no plugin object exists
* before instantiation: impossible, no plugin object exists
* after instantiation: impossible, specific port has
no memory location assigned to it.
* when first port is connected: impossible, specific port has
no memory location assigned to it.
* when the specific port is connected: possible (1)
* when activate() is called: possible (2)
* when run() is called: possible (3)
(1) is the current "use connect_port()" proposal.
(2) would work, but would throw away any use of presets by the host
before activate() is called
(3) as (2), plus throws away presets used between activate + run
I therefore don't see any point in time other than (1) that the plugin
can set the default.
So now the question can be rephrased differently:
given that the plugin can only set the port to default value at one
point in time, whereas the host can do so at any time, does it make
more sense for the host or plugin to do this?
Let me mention a different, more complex solution, just as a
contrast. My current understanding of VST is that a plugin always
comes with at least one program (we'd call it a preset right now), and
the host loads that program before using the plugin. LADSPA's problem
with this is that we haven't defined programs/presets as part of the
API at all - the existing implementations use their own methods for
storing/loading presets, and thus plugins can't really define a
"default preset".
The "defaults" changes are a step towards that, but they *only* define
a default configuration. The plugin can't come with more than 1
default, for example.
It might be worth stepping back to look at the broader picture here
for a minute to make sure that we're not solving just a small detail
of something that really needs the whole solution.
--p
This archive was generated by hypermail 2b28 : Thu May 30 2002 - 14:06:43 EEST