[gmpi] Re: 3.15 MIDI
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 18 Jun 2004 13:29:39 -0700
> See VCA subgroups. You turn it up so far, you want all those plugs
to turn up in the same way.
The obvious implementation of this (to me) is that you route the audio
streams into a mixer, and make one adjustment on one gain control. All
the component streams necessarily increase together. I don't think that's
what you're speaking of, is it?
No, that's a wholly unnecessary extra gain and mix stage. Buffer,
multiply, control, routing... yuck. Cycles do matter.
> Or, you have a row of faders onscreen, all lined up at 0 dB, you turn
two of them down the same amount, and they keep the same relative
volumes.
If I have a row of faders on the screen, they're almost CERTAINLY going to
be either all in the same plugin instance or in multiple instances of the
same plugin.
Not in my experience. E.g. remote mixing consoles, virtual or real,
driving internal volumes.
> If different plugs interpret volume control parameters differently,
without exposing a map, then all this stuff fails. QED.
I *really* am having a hard time seeing how someone would line up an array
of different plugins, and then expect them all to work exactly the same.
No soft-synth system works like this. No hard-synth system works like
this. No musician I know works like this.
We must just live in very different worlds, then.
Now, could we make it work? Probably. And you're correct, it would be
really nice. I love consistency. Natural ranges make it easy, in some
fashion. Assuming all volumes are measured in dB, a change of 2 on one
knob keeps it's semantic value when applied to another volume knob. That
rocks.
The *easiest* way to do this is to put forth a GMPI-endorsed standard
format for knobs like this (volume is just one example fo a class of
knobs, I think). A standard range and a standard units and a standard
datatype. Just for example, we could say that all volume knobs should be
float, measured in dB, and have the range -144.0 dB to +144.0 dB.
We're not in 0.0 - 1.0 land, so the range would not be relevant. But
if we were in 0.0 - 1.0 land, there's also the fader curve to
consider...
We
might say that they have a standard response curve, if we want.
...and there's lots of experience and taste variation in that, so
finding agreement might take some time.
Then yes, everyone who implements a volume knob will work the same. That
rocks. We could even put out sample code for this knob, so no one would
have to worry about. Double rock.
OK, so you agree. Great. But mandatory is unenforceable, and could
limit innovation, which is why I proposed OPTIONAL, and letting
parameter inputs that follow this convention announce the fact via
metadata stapled to the parameter input.
> >I didn't say that the 4 gain stages were necesarily EFFICIENT, but they
>are useful. :)
Nice way of avoiding the issue. You agree about the inefficiency, or not?
I'd assume that it is ridiculously inefficient, especially when I normally
use 2 of them. However, I don't know how the host works internally, so it
may wel be that the host-internal gain stages are actually clumped
together into a single gain stage, but presented as two knobs for logical
use.
Yes, well, note how if the host didn't use dB-based parameters, that
wouldn't work.
I can't say that they are or are not. I'd also assume that if
gain == 0, then the whole gain stage would be skipped, but I can't prove
that. So the short answer is, yes, a naive implementation of 4 gains
tages is obviously inefficient.
>And if we're going to suggest having an trim per output,
>why not just put that in the host.
a) Because that would be different
As you've said, I think, different does not imply better or worse.
b) Because that would be less efficient
It would?
Extra gain stage.
> c) Because that would always burden hosts instead of burdening only
the plug developers who want their plugs to work that way
I didn't mean to imply that every host would do it.
?? -- What you said was:
If *every* plugin (or even a good majority)
is going to do something the same way, then do it once in the host.
Plugins don't need their own volume knob, because the host can provide one
that is consistent across all instruments.
Guess either you misspoke or I misread.
If we were to mandate
a trim for every output, then it would make more sense to mandate it from
the hosts.
No, because then plug-related parameters would be going to two
different places, most to the plug and just this one to the host.
Plus the efficiency issue of the extra gain stage.
I don't think you're suggesting we mandate it. If a plugin
thinks that a trim per output is a good feature, then they should
implement it! If a host thinks it is a cool feature, then they should
implement it. If you end up with a host that has a trim per output and a
plugin that has a trim per output, there is no harm done (assuming a gain
stage of 0 has negligible CPU/memory hit). This is the sort of thinsg
that is a feature, I think.
d) Because this group will not approve that as a host requirement
e) Because some host writers will be lazy and not do it
f) Because some plug hosts will want to be more efficient than that
g) Because with the same plugs, this basic functionality could be
present in some hosts but absent in others
Right, as I mentioned above, I don't think this is the sort of feature we
would mandate, be it in the host or the plugin.
>Plugins don't need their own volume knob, because the host can provide one
>that is consistent across all instruments.
See a - h above.
I'm not suggesting we abolish it or outlaw it, just that it's not strictly
required.
Yes, that's what I said too.
In the simplest possible plugin API with the simplest possible
plugins, you probably want the host to handle it. GMPI is not
that API - GMPI is full-featured. Plugin authors and hosts
should both be free to implement anything they want. As long as you don't
require plugins to have gain adjustment, then there is no argument.
Yes, that's what I proposed.
> >Plugins don't need a per-output trim, because the host can do that.
See a - h above.
Again, as long as you don't require it of plugins, then it's simply a
feature.
>(most) Plugins don't need to handle MIDI, because the host can do that.
Looking forward to some engagement with the proposed goals I posted.
Yes, I have read it, and I am working on something.
>Of course, I'm not trying to be religious :)
Then there's a possibility you may be failing, since what I mainly
Hrm, well I apologize for that. I'm really not firmly in any camp. I am
firmly NOT in some camps, but I've really got no vested interest in
killing GMPI, nor in pissing people off. :)
than to well-known ordinary basic audio engineering architectural
principles.
I want to do better than whatever exists, wherever possible. Sometimes,
it doesn't (seem to) matter whether we do better. Here's a case where I
didn't really put too much thought into it, and my first assumption was
wrong. I'm happy to be made a fool of, as long as we move forward. :)
I'm sorry I was harsh, and glad you are coming to appreciate the
architectural advantages of a coherent gain model.
> >only useful as a measure of gain, and that's just a relative measurement.
Again, you say that as though it's unimportant, which is quite
incomprehensible to me.
Sorry again, I don't know where the idea of volume mattering in terms of
actual dBFS came from.
I'm not sure how we came to talk about volume, or really what we're
arguing about...
We're discussing whether the basic GMPI parameter model as detailed
to date is as well suited for its task as we previously thought, vs.
whether there are any problems buried in the assumptions that have
been made about it. We are doing that now because the discussion of
MIDI control of plug parameters brought the issue of what control
means, in a detailed sense, to light. And we just found and plugged
a hole. (I think note events and pitches/key numbers/scales is
another hole, BTW.) We're on topic, just forced to go deep by the
nature of the problem.
-- Chris G.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
