Subject: Simple Plugin API: In/Out Ports
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: ti helmi 29 2000 - 16:30:54 EST
Just a thought on a potential compromise:
We could keep the separation of in and out ports, but explicitly allow the
*host* to elect to make the plugin use the same buffer for both an input
and an output by simply passing the same buffer to two calls to
connect_port(). This would make the API compatible with frameworks that use
'in-place' processing. However this has to be supported by the plugin
writer. We could make this obligatory or merely very highly recommended.
I'm erring on the side of 'very highly recommended' (for a reason, think
through use of buffers in a stereo mixer plugin). If we added the following
to the LADSPA header in the main section and the plugin properties section
would this be enough?
/* ... Plugins should be aware that the host may elect to use the same
buffer for more than one port and even use the same buffer for both input
and output. However, overlapped buffers may result in undefined behaviour.
... */
...
/* If this flag is set it indicates that the plugin may cease to work
correctly if the host elects to use the same buffer for both output and
input. This should be avoided as enabling this flag makes it impossible for
hosts to use the plugin to process a buffer 'in-place'. */
#define LADSPA_PROPERTY_INPLACE_BROKEN 0x2
...
#define LADSPA_IS_INPLACE_BROKEN(x) ((x) &
LADSPA_PROPERTY_IS_INPLACE_BROKEN)
This means that the plugin designer can make the call to break in-place
processing if he/she wants/needs to keep things simple, but is made aware
that he/she is doing a Very Bad Thing. It doesn't actually make the plugin
fundamentally incompatible with in-place programs as they can always
introduce a temporary buffer and memcpy - but this could be more efficient
than comparing a bunch of buffer pointers, and at least this becomes the
plugin writer's choice.
For me, the idea of this API is to write something that will work with as
many existing (and upcoming) programs as possible without real trauma. I
deally no one should need to memcpy. The solution above at least reduces
the memcpy scenario to unusual plugin coding.
Thoughts anyone?
-- Richard
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST