Re: [LAD] LV2 Achievement of GMPI Requirement

On Tue, 2012-08-07 at 21:50 +0000, Fons Adriaensen wrote:
> On Wed, Aug 08, 2012 at 09:28:39AM +1200, Jeff McClintock wrote:
>
> > I think I good experiment is to imagine you have to write both an LV2 host
> > and 100 LV2 plugins, and you have to write MIDI-binding code. Do you put it
> > in the plugin OR the host?
> > -If a feature consumes 100 kB RAM and disk space, and it's implemented on
> > the host side - that's 100 kB.
> > -If it's implemented on the plugins side, that's 100,000 kB.
> >
> > Which choice is more 'bloated'?
>
> If the MIDI-binding code is in a shared library (and it probably should
> be) then there's little difference between these two. Code is shared.
> Per-instance data isn't, in the first case the host would allocate it
> if it loads a plugin and in the second case the plugin would do it, but
> again the total size would be the same.

I am wary of plugins linking to libraries, for compatibility reasons.
Particularly, if this library is in the LV2 SDK, what happens if the API
changes?

Currently to avoid any and all binary compatibility issues, all utility
code in the LV2 package is just in static inline functions in headers.
Of course, this is very poor from a code bloat (as in binary size)
standpoint. Often the inline is desirable for avoiding function call
overhead anyway.

Of course, this is all pretty academic until somebody actually starts
using this stuff on an embedded platform. The amount of code we're
talking about here is nowhere even remotely close to relevant on a PC
(even on mobile there's generally more than enough RAM, they care about
binary size for download bandwidth reasons).

The proper UNIX thing to do, of course, is to have proper versioned
libraries with major versions parallel installable. However I do not
know how to reconcile this with everyone's sociological desire for a
single "SDK" without effectively making the spec API version and the
utility libraries API versions the same thing, which would be very bad.

Perhaps it is good enough if a plugin compiled against an old SDK will
work with a host compiled against a new one (which should be the case).
Upgrading the SDK may break compilation (if an old utility library has
been replaced), but you can either update your code, or build against
the old one. Preferably the former.

> > A very real scenario is you write this MIDI-binding support, ship 50
> > plugins, then 6 months later discover a bug. Now if that feature is in the
> > host - that's one fix and everyone is happy. If that bug is in the 50
> > plugins, already shipped to 1000 customers. Then you have a much bigger
> > problem.
>
> Again if the code is an a shared library that is the only thing that
> will need to be updated.
>
> > It's not a question of 'bloat' YES/NO. The code has to go *somewhere*, there
> > is only a tradeoff - HOST vs PLUGIN.
>
> Yes, and the choice should IMHO be made based on *operational*
> requirements.

Given the choice between plugin and host, the answer is almost always
host.

Given the choice between a shared library and otherwise, the answer is
almost always a shared library.

> Does a MIDI controller control
>
> 1. a GUI element (e.g. a fader) which in turn controls a
> parameter, or
>
> 2. does it control the parameter, updating the GUI as a
> side effect.
>
> In case (1) the midi controller can use the mapping (e.g. linear
> or logarithmic) of the GUI element, which may be a desirable
> feature.
>
> Also imagine that the plugin GUI and DSP code (and host) run on
> separate machines. For example the host is some complex rendering
> engine placed in a technical room while the plugin GUI runs on
> your on-stage laptop. To which one would you want the MIDI controller
> connected ?

MIDI, and more generally parameter everything, is plugin side. GUI is
not an issue. However, at least in LV2, both speak the same language,
so it doesn't really matter, assuming the library is done correctly.

A utility library for this would/should/could not actually tinker with a
plugin, GUI, or anything else. It would just take one POD blob as input
(a MIDI event) and write another POD blob as output (a control event).
This is extremely flexible, so both your 1 and 2 are possible, or
whatever else (e.g. a third process which reads MIDI and sends resulting
events to both the engine and GUI process, or whatever). A good example
of where POD messages (i.e. protocols) clearly beat APIs.

Cheers,

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev