23 Apr
2006
23 Apr
'06
1:16 p.m.
On Sun, 2006-04-23 at 17:04 +0200, Florian Schmidt wrote:
On Sun, 23 Apr 2006 13:39:52 +0100
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
Couldn't it be done as an extension using the "features" parameter to
the instantiation function? If the host supports fixed buffer sizes it
can pass "FIXEDSIZE" or something in the features array, and the plugin
can add some sort of flag in the TTL file that says that it wants to be
called with a fixed buffer size. No need to add it explicitly in the
LADSPA2 specification.
Then, when the plugin sees that the host has the "FIXEDSIZE" feature, it
will know that the buffer size will always be the same. Hosts that don't
support this extension will ignore the flag in the TTL file and will not
pass the "FIXEDSIZE" feature to the instantiation function, and the
plugin can then either return NULL from that function, or switch
automatically to less efficient code that does not need a fixed buffer
size.
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian
Schmidt wrote:
I tend to disagree as it is kinda orthogonal to the other proposed
changes. What time other than a major version change is better to add
such a feature?
Aw hell, i'll try to get this into DSSI 2 then ;) thanks for taking the initiative on this! I would
like to see a way for
the host to pass its native buffer size to the plugin though. I know,
this is really kind of contrary to how LADSPA is supposed to work (i.e.
the run () function should be able to handle an arbitrary number of
frames), but it has some serious advantages for fft-based algorithms.
And i think it should be possible to merge the two approaches somewhat.
Thats a new feature. It'll have to wait til after 2.0 as far as I'm
concerned.