30 Apr
2006
30 Apr
'06
9:39 a.m.
On Sun, Apr 30, 2006 at 11:37:28 +0100, Chris Cannam wrote:
On Sunday 30 Apr 2006 00:01, Dave Robillard wrote:
So, examples:
Making disconnected ports have sensible behvaiour, eg. making stereo
plugins work as mono ones, if only left in and out are connected.
Port groups that are identified, eg. marking left and right ins as a pair.
So hosts can offer sensible connection options, and distinguish from
sidechain inputs.
Randomisable control ports (Taybin has been after this for ages). It's a
nice way to experiemnt with complex plugins.
FFT data inputs, using a struct like { int num_bins; float data[num_bins]; }
much more efficient the constant moving in and out of PCM, and makes
plugins less complex.
We need a better API with which to build good,
useful things.
So what are those things, and how will LADSPA2 get us to them? I'm not
looking for perfect foresight here, just some inspiring examples. Just because one API is easier to extend than another,
doesn't mean that
it will necessarily happen easily or in a useful way (i.e. with
consistent enough coverage from hosts or plugins to be really useful).
The logarithmic hint discussion here is an example of that -- it's just
about the most trivial thing that can be imagined as an application of
an extensible API, yet it's ended up in a lengthy discussion with no
consensus so far.
Well, actually the LOG hint is just an example of something that LADSPA1
(arguably) got wrong, and theres no eaasy way to fix it in LADSPA1. The
reason it can't be fixed easily is that its far from trivial. Especially
seen as noone knows what it means ;)
You're right though, just building an extention mechanism is no guarantee
that people will use, but if you dont then they don't have the choice.
- Steve