23 Apr
2006
23 Apr
'06
4:40 p.m.
On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave Robillard wrote:
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.
- Steve