[LAD] Android audio plugins

[David Robillard]

On Wed, 2011-06-29 at 11:59 -0500, Gabriel M. Beddingfield wrote:
[...]
> And this is what I'm wondering... could/should this be 
> done with an LV2 extension?

Sure; it is straightforward to define new LV2 port types.

(Warning: LV2 design tangent follows)

However, the more I think about it the more I resent the hard
distinction between port types.  Us still being stuck with the tinkertoy
control ports inherited from LADSPA are the most obvious effect of this.

If people want to start playing with alternative sample formats,
defining a different port type for each would pose a problem: you need a
separate plugin for every sample type.  Perhaps this would be okay,
since you'd only want one on a given platform anyway, but it seems a bit
weak.  A more dynamic way to allow a plugin to work with whatever
dynamically configured sample format would seem to be better... which is
yet another argument for what I increasingly think is the best way to go
with LV2 plugin I/O in general:

To me (with good ol' 20:20 hindsight), it seems that a single port type
that receives messages would be much better than the current
situation[1].  Messages would have a standard binary compatible header
which distinguishes the various types (much like the current provisional
atom extension[2]).  Separate units which communicate via generic well
defined messages is well-known as a solid computational model with many
advantages; it seems to map best to plugins (since many plugins are
stateful so purely functional ideas are out, anyway).

The plugin can simply list in the data that "this port supports such and
such message types", and - if necessary - the host could configure the
plugin to expect whatever types of messages it will be delivered.  In
this case, float audio, double audio, int16_t audio, or whatever.

Anyway, the above is a more general "how" discussion mostly of interest
to LV2 folks.  As for the pragmatic issue of sample formats at hand, the
answer is, as always: sure, we can do that.  It would break
compatibility with existing hosts, though.

[1] Actually, I think there are fundamentally /two/ primitive types of
ports based on the semantics of how they consume their value: "value
ports" and "message ports", but that's a tangential discussion.  Suffice
to say here that audio ports are messages because they /consume/ their
input, so nevermind values.

[2] http://lv2plug.in/ns/ext/atom/