Subject: [linux-audio-dev] LADSPA extension mechanism *proposal*
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Thu Apr 05 2001 - 14:10:52 EEST
Okay, I know I'm a complete newcomer here and I have no right to
propose anything, but I need this, and if I can't get it with
consensus, I'll just have to go my own way and do it on my own - a
hack for my own purposes not shared with anyone else.
If you remember my problem - I want a plug-in that plays a sample from
a .WAV file (say), and I need to pass the WAV filename on
instantiating the plug-in. All suggestions of using external config
files or whatever also amount to doing non-standard things to get
around the limitation of the LADSPA standard, so how about doing it
right ?
This is what I propose. We associate a list of tagged extensions to
each LADSPA_Descriptor. Each item in the list consists of a type and
a value. The type is a string, and the value is a (void*), the
meaning of which is dependent on the string.
typedef struct _LADSPA_Extension {
char *typ;
void *val;
} LADSPA_Extension;
The list of extensions is an array of these, with the final ->typ set
to 0 to mark the end of the list.
This is all just a round-about way of adding new members to the
LADSPA_Descriptor structure, but without breaking existing code.
These `extensions' could be used to associate new function calls, new
data structures, or whatever with the particular plug-in.
Only hosts that understand these particular extensions will be able to
make use of them - everything else will act as though they don't
exist.
For now, I propose only one extension type: "CMD". The value
associated with this is a function pointer:
char* (*CMD_function)(char *cmd);
`cmd' is an ASCII command-string for the plug-in, and the return value
is either NULL or a strdup'd string containing an error message or the
expected output from the command. I would expect that most commands
would execute without giving output.
[[ I was originally thinking of keeping the memory allocation out of
the spec, and passing a call-back function pointer that can be used to
report errors, but this would cause nasty problems in a multi-threaded
environment, so maybe returning a strdup'd string is better here. ]]
What command-strings are expected or accepted by a plug-in is
completely up to that plug-in. I would expect some consensus to arise
here as people try and make their plug-ins compatible with other
plug-ins. Also, for you GUI people, it would probably be easy enough
to associate command-strings with buttons through XML or whatever
mechanism you're planning to use.
For my basic sample-player, I just have one command: "load
<sample-file-name>", which must execute before activate() is called so
that the sample can be preloaded at a non-critical time. I anticipate
plug-ins I develop further down the line to make much wider use of
this interface.
The only question left is how to attach this list of extensions
(LADSPA_Extension[]) to the LADSPA_Descriptor. It would be ideal to
just have a (LADPSA_Extension*) somewhere in there, but I can't see
any way to extend the structure without breaking something (except
maybe through magic numbers ?), so I propose adding a new (optional)
function to the .so file:
LADSPA_Extension* ladspa_extension(unsigned long Index);
For each plug-in `nn', ladspa_extension(nn) gives the extension list
for that plugin (or NULL if there is none), and ladspa_descriptor(nn)
gives the main descriptor structure. If the symbol `ladspa_extension'
is not present in the .so file, then there are no extensions.
- - -
So there we are. Now, I don't want to force anything on anyone, and
if the consensus is that this is a terrible idea, I will drop it with
no bad feelings.
Also, if this seems workable, but needs completely changing, that's
fine with me, because it's the end result that's important to me, and
so long as the mechanism supports what I want to do, I'm happy.
I admit that this does introduce the possibility of everything getting
completely out of hand - new extensions being developed for everything
under the sun. However, the whole point of a plug-in architecture is
to share things, and sharing is encouraged by being compatible, so
hopefully this will keep things in check.
Thoughts ?
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 16:00:22 EEST