linuxaudio.org

--=-vgh0TpAVe3IVNWk5Ar42

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

Content-Transfer-Encoding: quoted-printable
On Wed, 2012-08-08 at 09:28 +1200, Jeff McClintock wrote:

quoted text
> > > My concept with GMPI (not everyone agreed) was that MIDI was not

> > > required *in* the plugin.

> > >  I decided the *host* should provide that routine (mapping MIDI to po=

rt

quoted text
> value). Written once,

> > > available to every plugin developer. =20

>=20

> > This is almost exactly what I proposed as an LV2 extension in this

> > previous thread - " In practice, however, there are a few border cases

> where the plugin

> > would want to indicate its default MIDI bindings".

The plugin indicating it's bindings is the *only* thing to do here.

Otherwise, the host can just bind however it wants.
It is a simple idea much older than that thread, just nobody has done it

yet.  Doing it statically is trivial: just set properties on ports to

indicate their binding.
Static is not so useful though, and control ports suck for a slew of

other reasons anyway, so this has not been established.  To do it right,

and dynamically, the things mentioned in my previous reply need doing

first.
> Cool, I like it. I disagree that synthesisers are 'border cases' though ;=

)

quoted text
>=20

> > The only real worry is that hosts will be unhappy of the "bloat" added

> > to the library they are using. =20

>=20

> Yeah, Host developers want the 'bloat' in the plugins, plugin developers

> want the 'bloat' in the host.

>=20

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

t

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

it

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

>=20

> Which choice is more 'bloated'?

>=20

> 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 th=

e

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.

>

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

ere

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

>=20

> My choice was to have very lightweight plugins, and a more sophisticated

> host.

Indeed.  *Global* "bloat" is, by far, the most important consideration.

If there is a One True Software Quality Metric, it is certainly lack of

duplication.
That said, I don't think there would be any considerable bloat of any

variety related to the issues under discussion.
> The one other reason you want the host handling the MIDI Binding...

quoted text
>=20

> > On Fri, 2012-06-08 at 09:45 +0000, Jeremy Salwen wrote:

> > > Currently, a plugin writer is in a bit of a sticky situation: if the

> > > plugin supports MIDI CC events, then the internal parameters are

> > > hidden from the host.  You can do something where you have a switch

> > > which toggles between MIDI CC control, and Control Port control, but

> > > this is not a fun thing to do, and I think it is additionally

> > > confusing for the user.

>=20

> True, a plugin's parameters can be set by many sources:

> * pre-recorded automation.

> * The user tweaking the GUI.

> * MIDI messages.

I think reality is being slightly misrepresented here: to be clear, it

is not common in LV2 land for plugins to support parameters via MIDI CC

in this way, for all the obvious reasons you have mentioned several

times.  Apparently that is common in the VST world, which is why you

want to "argue" for it, but I find that quite strange.  Clearly mystery

MIDI parameters in plugins is crap.
Which is to say: Yes, that is stupid; and no, that is not common LV2

practice, nor will it ever be.  Preaching to the choir, Jeff :)
LV2 synthesizers typically use MIDI *for notes* for lack of a better

standard at the moment, but not for parameters.
> What if they all happen at once? Only the host is in a position to mediat=

e.

quoted text
> For example if you click-down on a plugins GUI slider - you don't expect

> that slider to continue jumping arround in response to MIDI automation. T=

he

quoted text
> human is in control until the mouse-up happens, then automation resumes

> control. This is a host feature, it can only be implemented of the MIDI

> message is decoded by the host, the plugin can't be changing it's own

> parameters 'in secret'.

This will be an issue to consider if people want a graceful migration

path to events, i.e. events can be used to control the same parameter as

a control port (which is essentially exactly the same issue, except not

MIDI).
Personally I think it's not worth the effort (and don't really think

backwards compatibility gunk belongs in plugins whatsoever).
-dr
--=-vgh0TpAVe3IVNWk5Ar42

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)
iQIcBAABCAAGBQJQIbd5AAoJEDZyeCqb82jzDwIQALI8WIq40mudpSWVKaqWR0Ok

hILTh/+4kzYqhCPVdrqeKNm1QG4ak3Fuqf2xKyVrRGeyyvC711ecy43WGO+Cksay

EFY/LKhPKYua7pnSW0tDSbPlYaMrLSTE7Hvg6Y/ExLce49R6yiQlXQRj5W2t+M1O

XkkhG2VEDaaWdYXAUAk7okq3Tr2mEuplvkUr4EvwL9D5dCxdn0fapLhm2pu4TS0t

a+OMPkjQTNJP1pfvp/8rKzWe9NoUv/9MULDtqOdrjga/MIQ7Nfp4XR9HQNl4Ro2b

1gBCrkgOEUpjnjsZP2Ty6HOEiHtLznNVwsDR7jkuNg9ClxFUzgj8o1cO9ndSm1Tc

vIxJSpWiDfY+lc/MpGq68GzxuIKmTZV5FjpgJVRrmDSILqCptkvPOILqzc2z5uen

b6/HWJ/WLU/e74lHgSXblhA4uibfuQ5kaQtY/+gDPVYB478f6jKcYiGJz3kzuXXA

XblpcoEH0koL2bwdjlGm4dtGkvbsUbt52UKaaFVZiBmu6AZQVZczJS4JFzPWYRKg

sw/chxjZZT6LmMX91DNnsYX3d7M9PHrnmAZZ/mFNqIiehuAe9bDiP02Vm7elInN4

ZKbBeX1K5K/GsUvOySa6q64KpCWidZJPPRbD9xIpAbgEtwx+0yiytYrkTjI8aUmN

T/Lc3YZX1ONfGkoCPijF

=i5Ur

-----END PGP SIGNATURE-----
--=-vgh0TpAVe3IVNWk5Ar42--