Content-Type: text/plain; charset="UTF-8"
On Tue, 2012-08-07 at 21:50 +0000, Fons Adriaensen wrote:
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
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
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
Given the choice between plugin and host, the answer is almost always
Given the choice between a shared library and otherwise, the answer is
almost always a shared library.
> Does a MIDI controller control
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.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----