On Sun, Apr 23, 2006 at 04:26:03 -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.
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.
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)
Sure, but that doesn't require you to be able to load the shortnames from
the plugin binary.
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.
It can't speak OSC either, so the integers are just fine.
It has to be
in the struct, otherwise you don't know what functions to
call to get a particular plugin.
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.
They are, they have integers. The integers map to something very real in
the plugin structure. Shortnames are just shortnames, you can't map them
to ports unless they appear in the external data or you load and link the
plugin.
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.
Please dont use the word metadata, it's confusing, what's meta depends on
your context. Not all the data can be fiddled with without breaking
things. If you change the URI all your presets will stop working, if you
change the port indexes then the structure of the plugin changes, etc.
- Steve