20 Jun
2006
20 Jun
'06
1:48 a.m.
On 6/19/06, Jez Kabanov <jez(a)technetium.net.au> wrote:
Noticed you mentioned dssi gui's here. I'm interested in adding some
kind of dssi wrapper to khagan so gui's built in khagan can be used
for dssi's easily. It's on the todo for the next release
http://openfacts.berlios.de/index-en.phtml?title=Khagan_Todo however
since i wrote the todo i've got a full time job programming python and
my interest in touching a computer has waned and i spend my limited
spare time with my lovely washburn bass and 70's pawn shop acoustic.
If you'd like to add this kind of thing to khagan for dssi's and maybe
lv2 plugins that could be quite interesting.
Loki
The idea itself isn't stupid, but the implementation is.. let's say less
than wise.
(Consider my personal blatant bias, but...) I'd suggest taking a look at
LV2. There is a data file you can add all this information to (whatever
information you want to), without defining any APIs, changing any host
code, etc, etc.
You definitely shouldn't have to break binary compatibility of things
just to add some hints for hosts, this is the problem LV2 is meant to
solve...
-DR-
while i'm no expert in this area, i'm having some trouble
understanding
your rationale.
how is it breaking binary compatibility?
is binary compatibility even an issue?
shouldn't the host just look for the plugin and load it and check for
the existence of a symbol,
if it exists then call it, otherwise it doesn't and everything is just
as it was.
the host never need know anything about the binary structure of the
plugin except to know that there's a function called "ladspa_descriptor",
adding ladgui certainly doesn't stop old hosts from loading and using
the plugin,
i've modified nekobee to use ladgui and it runs exactly as it used to in
an unmodified rosegarden,
so how is binary compatibilty an issue?
whereas LV2 breaks compatibilty with old plugins (this seems like more
of an issue to me), adds a lot of complexity and requires the host to
use an additional liblv2 library.
- Jez