Hi everyone,
Finally got a chance to look at ladspa.h, to
evaluate the feasiblity of modifying sfront to produce
sa.c files that would function as LADSPA plugins.
The easily-doable approach would let sfront
create plugins that could only create a single
instance -- that is, the first call to:
LADSPA_Handle (*instantiate)
would return a non-NULL value, but all
subsequent calls would return a NULL value; the
void (*activate) and void (*deactivate) methods
would be set to NULL.
This restriction is necessary because at
present, the sa.c files sfront creates manipulate
state stored as global variables; this was done
purposely, to remove one layer of indirection on
memory accesses. There's no technical hurdle to
optionally encapsulating this state in a dynamic
form, but supporting this option would be a
multi-month effort, and at present no other sfront
application domain requires it. So, I doubt it will
happen in the near term ...
So, the question I have for LADSPA users is,
is an sfront option that creates a plugin that can
only be instantiated once a useful thing? Or is the
consensus "don't bother, its too limited?" The
general idea is, a user would build up a signal
processing chain in SAOL, then use sfront to create
a plugin for the entire chain, and then instantiate
once in the application.
Let me know, if there's no user interest in
a single-instanced LADSPA, I won't spend cycles
doing one ... there are enough audio and control
drivers in sfront that no one uses already :-).
--jl
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
