23 Apr
2006
23 Apr
'06
5:02 p.m.
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.
-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:
The advantage is the mentioned use case which your suggestion destroys.
The array can be static anyway, there's not really any "code" added. 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. 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.