7 Aug
2012
7 Aug
'12
11:28 p.m.
> 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 port
value). Written once,
> available to every plugin developer.
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".
Cool, I like it. I disagree that synthesisers are 'border cases' though ;)
The only real worry is that hosts will be unhappy of
the "bloat" added
to the library they are using.
Yeah, Host developers want the 'bloat' in the plugins, plugin developers
want the 'bloat' in the host.
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'?
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.
It's not a question of 'bloat' YES/NO. The code has to go *somewhere*, there
is only a tradeoff - HOST vs PLUGIN.
My choice was to have very lightweight plugins, and a more sophisticated
host.
P.S.
The one other reason you want the host handling the MIDI Binding...
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.
True, a plugin's parameters can be set by many sources:
* pre-recorded automation.
* The user tweaking the GUI.
* MIDI messages.
What if they all happen at once? Only the host is in a position to mediate.
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. The
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'.
Best Regards,
Jeff
7 Aug
7 Aug
11:50 p.m.
New subject: LV2 Achievement of GMPI Requirement
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.
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.
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 ?
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
8 Aug
8 Aug
3:12 a.m.
New subject: LV2 Achievement of GMPI Requirement
On Tue, 2012-08-07 at 21:50 +0000, Fons Adriaensen wrote:
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.
On Wed, Aug 08, 2012 at 09:28:39AM +1200, Jeff
McClintock 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
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.
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. 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. 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
11:59 a.m.
New subject: LV2 Achievement of GMPI Requirement
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.
Absolutely. This is exactly what I'd like to do. Is there a reason we
shouldn't implement this before we figure out the more complicated
scenarios?
Jeremy
9 Aug
9 Aug
4:39 p.m.
New subject: LV2 Achievement of GMPI Requirement
On Wed, 2012-08-08 at 05:59 -0400, Jeremy Salwen wrote:
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.
Absolutely. This is exactly what I'd like to do. Is there a reason we
shouldn't implement this before we figure out the more complicated
scenarios?
I have added the property midi:binding, i.e.
http://lv2plug.in/ns/ext/midi#binding , to the MIDI extension. As far
as specs go, this is all that is required.
It is not documented online yet because the docs are not uploaded until
release, but it is in svn and you can build those docs if you want, but
essentially they boil down to the example:
port midi:binding [
a midi:Controller ;
midi:controllerNumber 17
] .
Have fun.
-dr
24 Aug
24 Aug
9:53 a.m.
New subject: LV2 Achievement of GMPI Requirement
On Thu, Aug 9, 2012 at 10:39 AM, David Robillard <d(a)drobilla.net> wrote:
On Wed, 2012-08-08 at 05:59 -0400, Jeremy Salwen
wrote:
relevant plugins). However, what should be done for the case of plugins
with multiple MIDI inputs? Is this beyond the use-case of midi binding, or
should the extension be expanded to specify which event port it is
referring to?
Jeremy
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.
Absolutely. This is exactly what I'd like to do. Is there a reason we
shouldn't implement this before we figure out the more complicated
scenarios?
I have added the property midi:binding, i.e.
http://lv2plug.in/ns/ext/midi#binding , to the MIDI extension. As far
as specs go, this is all that is required.
It is not documented online yet because the docs are not uploaded until
release, but it is in svn and you can build those docs if you want, but
essentially they boil down to the example:
port midi:binding [
a midi:Controller ;
midi:controllerNumber 17
] .
Have fun.
-dr
Thanks, that's all I wanted. I'm going to add support to my host (and
8 Aug
8 Aug
2:49 a.m.
New subject: LV2 Achievement of GMPI Requirement
On Wed, 2012-08-08 at 09:28 +1200, Jeff McClintock wrote:
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.
> 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 port
value). Written once,
> available to every plugin developer.
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". Cool, I like it. I disagree that synthesisers are
'border cases' though ;)
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 only real worry is that hosts will be unhappy
of the "bloat" added
to the library they are using.
Yeah, Host developers want the 'bloat' in the plugins, plugin developers
want the 'bloat' in the host.
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'?
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.
It's not a question of 'bloat' YES/NO. The code has to go *somewhere*, there
is only a tradeoff - HOST vs PLUGIN.
My choice was to have very lightweight plugins, and a more sophisticated
host. The one other reason you want the host handling the
MIDI Binding...
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.
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.
True, a plugin's parameters can be set by many sources:
* pre-recorded automation.
* The user tweaking the GUI.
* MIDI messages. What if they all happen at once? Only the host is in a
position to mediate.
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. The
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
4272
days inactive
4289
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
David Robillard -
Fons Adriaensen -
Jeff McClintock -
Jeremy Salwen