On Tue, May 22, 2012 at 2:25 AM, Jeremy Salwen <[email protected]> wrote:
>
> It's not clear to me what is legal for an LV2 plugin to do with an input
> control port. Once the input port has been read, is it acceptable to use
> that location in memory as temporary storage in the "run" method? Is it the
> host's responsibility to re-fill the value of the parameter before every run
> call? Is it the plugin's responsibility to keep input-ports bit-exactly the
> same?
>
> What about transformations of the input which leave the value logically the
> same? For example, normalizing boolean inputs the values 0 and 1?
>
> The documentation is silent on this matter.
Common sense dictates that this is a bad idea. Input means input.
Here's a relevant quote from the LADSPA documentation:
"Plugin writers 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 (see LADSPA_PROPERTY_INPLACE_BROKEN).
However, overlapped buffers or use of a single buffer for both
audio and control data may result in unexpected behaviour."
The way API documentation works, unless something is explicitly stated
as being permitted, you can never assume that it is. Even if someone
on the ML tells you it's OK that doesn't matter because everyone else
who read the API doc will have assumed it was *not* OK and coded
accordingly.
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
