Subject: Re: [linux-audio-dev] LADSPA extension proposal (quick action wanted)
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Thu Dec 06 2001 - 16:48:46 EET
On Thu, Dec 06, 2001 at 09:13:45AM -0500, Paul Davis wrote:
> imagine, but its not clear how you would write the data to the control
> port: it can't be done atomically, and you don't want the plugin
> working with a partially overwritten data set. so, i can easily
Yes, I see the problem now. The only solution I can see is that the host
will have to hold the new array until the plugin has finished its
run() function and then update.
NB. this is potentially also an issue for single float parameters, in many
situations you have to ensure that a parameter is safe before doing maths
on it != 0.0 for example. I try to avoid changing the port itsself, but
there is nothing that requires that IIRC.
> 2) GUI descriptor
I think I prefer a system where DSP parts are GUI agnostic, and the GUIs
live in thier own directory and can be asked what plugin(s) they support.
It would for eg. be possible to build a GUI that could render any port
set, as hosts do now. Or one that globbed all the guis into one rack-style
window, like Reason.
OTOH the concept of a preferred/recommended gui could be useful.
I would like to bring up the idea of port default values again too.
The hints LADSPA_HINT_DEFAULT_ZERO, LADSPA_HINT_DEFAULT_ONE,
LADSPA_HINT_DEFAULT_MIN, LADSPA_HINT_DEFAULT_MID and LADSPA_HINT_DEFAULT_MAX
seems to cover every case I know of and allow hosts to start plugins in a
sane state, without requireing users to fiddle about for ages to get to a
good starting point. I suppose an alternaltive would be
/usr/local/lib/ladspa/presets/<n>/default.xml
Per-plugin versioning could be worth considering too.
- Steve
This archive was generated by hypermail 2b28 : Thu Dec 06 2001 - 16:44:48 EET