23 Apr
2006
23 Apr
'06
8:41 p.m.
On Sun, 2006-04-23 at 16:26 -0400, Dave Robillard wrote:
On Sun, 2006-04-23 at 19:39 +0100, Steve Harris
wrote:
In other words it's there because it's a unique identifier for the
plugin, used to reference it. I say port IDs need to be there for the
same reason. Ports should be first class citizens with a proper
identifier and all, IMO.
Anyway, putting IDs in the metadata implies that, well, they're
metadata, and can be fiddled with without breaking things. This is not
true. They are unique identifiers (along with their plugin's URIs they
define a URI) and as such are set in stone and must not change. They're
just not metadata.
But I want to emphasize the 'device' (or trivial host app, etc) over
arguments about word definitions etc. I really don't want to have to
fork LADSPA into an ABI incompatible derivative over something silly
like this.
For the sake of the record, it's been duked out on IRC and Steve
wins :). (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).
The RDF file is required to run the plugin anyway, since port type and
direction etc. is contained there, making my argument about keeping the
data file parsing off the 'server side' invalid.
The data file is not a "metadata" file, it's required to execute the
plugin at all (and I fully agree with this now, even if it does throw a
bit of a monkey wrench in some embedded development plans of mine; it's
for the greater good....)
-DR-
On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave
Robillard wrote:
Well, the plugin should be at least runnable without the metadata. Sure
you'll know almost nothing about it, but you should be able to run it
(eg in fixed code where you know the parameters and whatnot you're using
are fine). (No user interacting app could feasibly do so though)
The "somewhere" part is my point. This 'device' can not read metadata
files, yet it needs to know the port IDs. Therefore the port IDs need
to be in the code.
On Sun, 2006-04-23 at 19:23 +0100, Steve Harris
wrote:
I don't see how it affects the usecase. You /always/ need to read at least
some of the data somehwere to use the plugin. On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave
Robillard wrote:
> But anyway, why can't it go in the code? I want to keep the C part
> minimal as well, but this is a unique identifier, the sole thing that
> actually does belong in the code. I need this to create an app/device
> like the above. What's the better reason it's a bad idea? Plugins have
> a unique string ID, and I need ports to as well.
Theres no advantage to it being in the code, it means allocating an array
of strings, which means repeating the same code in every plugin. Also, you
can't get the strings unless you load and link the plugin, which is one of
the things were trying to get away from.
The advantage is the mentioned use case which your suggestion destroys.
The array can be static anyway, there's not really any "code" added. Are you
proposing to put the port index numbers in the metadata as well?
Otherwise you couldn't get at them without loading and linking the
plugin.
Of course, it's ladspa:index if the numbers aren't there then theres
nothing to link the port data to the float *.
So the plugin URI should exclusively go in the
metadata file as well?
Why is that in the code?
It has to be in the struct, otherwise you don't know what functions to
call to get a particular plugin.