8 Nov
2009
8 Nov
'09
3:06 p.m.
On Sun, 2009-11-08 at 19:13 +0100, fons(a)kokkinizita.net wrote:
On Sun, Nov 08, 2009 at 10:45:50AM -0500, David
Robillard wrote:
I assumed this object would be an auxiliary thing, because that's all
that makes sense.
Making an LV2 plugin that doesn't actually use the LV2 methods doesn't
make any sense. It could technically have those fields but have them
not do anything and theoretically be a "valid" LV2 plugin I suppose, but
it's a completely braindead and pointless thing to do anyway, so who
cares...
If the motivation for this is the fact that this class already exists,
then simply make the LV2 methods call the methods on that object. The
"bypass LV2 entirely" thing you describe is crazy. No point in using
LV2 at all, that way. At best it's just being a huge pain in the host
author's ass for no reason.
-dr
On Sat, 2009-11-07 at 23:09 +0100,
fons(a)kokkinizita.net wrote:
Yes. Please rewind a few messages and read again.
The idea was an extension that requires the host
to obtain a pointer to a C++ object from the plugin.
This C++ object (derived from some base class which
is part of the extension definition) then provides
all other information (ports, process method, etc.).
This would bypass all LV2 methods, but still be an
LV2 plugin. On Sat, Nov 07, 2009 at 12:52:52PM -0500, David
Robillard wrote:
Huh? An LV2 plugin in the code sense is a shared library with a
lv2_descriptor function that returns a struct LV2_Descriptor (just like
LADSPA). This wouldn't be an LV2 plugin at all.
In spirit, no. But technically it would be a
perfectly conforming plugin.