linuxaudio.org

--=-5dUSFrE7Xq8q1//2diHi

Content-Type: text/plain; charset="UTF-8"

Content-Transfer-Encoding: quoted-printable
On Tue, 2012-08-07 at 21:50 +0000, Fons Adriaensen wrote:

quoted text
> On Wed, Aug 08, 2012 at 09:28:39AM +1200, Jeff McClintock wrote:

> =20

> > I think I good experiment is to imagine you have to write both an LV2 h=

ost

quoted text
> > and 100 LV2 plugins, and you have to write MIDI-binding code. Do you pu=

t it

quoted text
> > in the plugin OR the host?

> > -If a feature consumes 100 kB RAM and disk space, and it's implemented =

on

quoted text
> > the host side - that's 100 kB.

> > -If it's implemented on the plugins side, that's 100,000 kB.

> >=20

> > Which choice is more 'bloated'?

>=20

> 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

quoted text
> > plugins, then 6 months later discover a bug. Now if that feature is in =

the

quoted text
> > 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.

>=20

> Again if the code is an a shared library that is the only thing that

> will need to be updated.

> =20

> > It's not a question of 'bloat' YES/NO. The code has to go *somewhere*, =

there

quoted text
> > is only a tradeoff - HOST vs PLUGIN.

>=20

> 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

quoted text
>=20

> 1. a GUI element (e.g. a fader) which in turn controls a

>    parameter, or

>=20

> 2. does it control the parameter, updating the GUI as a

>    side effect.=20

>=20

> 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.

>=20

> 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 ?=20

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
--=-5dUSFrE7Xq8q1//2diHi

Content-Type: application/pgp-signature; name="signature.asc"

Content-Description: This is a digitally signed message part

Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABCAAGBQJQIbzsAAoJEDZyeCqb82jz45AQAKeZHNm0AIOI7C1try4OkdrK

oZfpB/RXkj7ZoMjPOKsNsNJENunxsbpWxhtqiRYhGIw4pJ7CJ22mklBEePN0y+57

ro4outsUY7YV9EPoTsv5LIkedEjDqjh562yghDApn/iD0aqGUu/Kpl9LgZlcSjTu

vSZ+WoCDFBQLteeUQPKzplYW+MlymNebHmcPwj1Im67EedVnyr6+HoJMh4YPXn9v

jvrCnXYRwE547EUebXvoX9+0sUadV2TsWzSBFHIy6GBa0YBgwe6I3gi7NLeVvm/w

z9MKrPTL0JkTKxOmMguSGm60sQBmNm8DjcO3EutMhrKKpidyEt/tGlwkJyFsWHiD

yBWEdSMJINOQ2MRfuaAq45YKL4WaPS74QTvUK3EOPj0W4xEYIi5QC+OUfadidFil

KckpPBYgUhHPaAi6uAUL0VEmLPaYhbrIA0Zdops53QgN8MGAvwd4agEuO39CQKOi

qBuIHETX8QZ7nmek7SopZByN4K/TG05Th0MdYhki8f5iXlqGZ8INASoBDdOmVak7

5CBZhrGkUkST27jse2tmJ6cnQa62M9+dZZ6GKPV0QTrW6EA6K1S2oGVilMhzMvHF

5ofrayWL6vD9rUhItR7bC5eolfDFDFNnheud24T+IctdBr/SO05xLx9dl4FzuqaX

XfKA3zkahkAxrWjcyFS9

=9VYz

-----END PGP SIGNATURE-----
--=-5dUSFrE7Xq8q1//2diHi--