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
