On Sun, 2009-11-08 at 19:13 +0100, f...@kokkinizita.net wrote: > On Sun, Nov 08, 2009 at 10:45:50AM -0500, David Robillard wrote: > > > On Sat, 2009-11-07 at 23:09 +0100, f...@kokkinizita.net wrote: > > > On Sat, Nov 07, 2009 at 12:52:52PM -0500, David Robillard wrote: > > > > > > > This wouldn't be an LV2 plugin at all. > > > > > > In spirit, no. But technically it would be a > > > perfectly conforming plugin. > > > > 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). > > 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.
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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev