23 Apr
2006
23 Apr
'06
2:16 p.m.
On Sun, 2006-04-23 at 18:59 +0100, Steve Harris wrote:
So things like this could be provided just by setting a HostFeatures
flag that implies a certain library is linked and available for use?
That works.
(I'm not particularly attached to the idea either way, just a thought.
It allows the host to provide things to the plugin in general which
could be a good thing considering the change is so minimal).
-DR-
On Sun, Apr 23, 2006 at 11:44:03 -0400, Dave Robillard
wrote:
Perhaps, well it's not critical, appending /filename will always work
under Linux, its just a bit untidy. I used SHOULD incase the host has some
trouble removing it for some reason, but I can think why it would have.
So yes, MUST would be OK by me.
Yeah, anything that lessens what plugins have to deal with is the Right
Thing.
The path
of the directory/bundle is passed to instantiate(). This is
neccessary to make it actually useful. It could have been passed to other
methods, but that seemed most appropriate.
"The BundlePath parameter is a string of the path to the plugin's
.ladspa2 bundle directory, it SHOULD not include the trailing /."
Might as well s/SHOULD/MUST/ so the plugin doesn't have to deal with it.
If it's just SHOULD there's not much point in wasting space mentioning
it. Just an
initial thought: how about adding a similar parameter for a
host-provided-things directory? This in combination with the
HostFeatures would allow a host to provide almost anything to plugins,
like a realtime memory allocator lib, some kind of shared memory scheme
for a GUI extension, etc. etc. Much more extensible without having to
break the ABI. Thoughts?
Hmmm... providing a lib that way is a bit late, setting LD_LIBRARY_PATH is
more convienient. Given that we dont have anything to put there currently
I don't feel really motivated.