[gmpi] Re: Draft reqs - Parameters - Modulation?
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 24 Dec 2004 18:12:33 -0800
Sorry for the long latency - I've been out of the country. I'm back and
on a mission to wrap up reqs.
On Sat, Dec 11, 2004 at 05:37:53PM +0000, Angus F. Hewlett wrote:
> Now, in an API I designed for something we're doing in-house, we found
> it very useful for parameters to have both a static and dynamic state,
> to support realtime modulation in a flexible way without messing with
> the settings the user wants to persist for the plug.
This *sounds* right, but is it really? I mean, fundamentally - what's the
difference between a MIDI knob that I turn and an LFO plugin that turns it
for me? To the plugin there should not be a difference. Howevre, as you
point out - the value that gets 'persisted' is debatable.
> A) plug-ins that wish to support this kind of thing expose multiple
> parameters for the same fundamental thing (say Filter Cutoff, stateful,
> and Filter Cutoff MOD, non-stateful)?
Is this similar to a modular synth where a knob controls a parameter
unless a wire is plugged in? This means that *only* those plugins that
really care what state should persist will be affected. But it impacts
the user experience.
> B) in general, the host is the arbiter of all modulations, so a host
> doing a lot of modulation keeps a modulation-neutral state for the
> plug-in around (updating it when the user makes a persistent parameter
> change), and makes sure that the neutral state gets persisted.
This is cleanest from the point of view of the plugin and the user, but
the most work for hosts. However, with gestures, it is easy to
distinguish a user event and an non-user event. So the host can track
this. Maybe this is a suggestion, or is it a requirement?
* Hosts should track user originated events and non-user originated events
seperately. For stateful parameters, only user originated events should
be considered for state save operations.
(if this is a req, rather than a reccomendation, 'should' can be replaced
with 'must')
> C) non-stateful, additive parameter-modulation events for
> otherwise-stateful parameters are potentially useful, and should be
> considered as a requirement.
This may be useful regardless of this problem. We've already got some
language about normalized parameter control (to achieve LFO controls and
such). Should we consider adding scalar control?
- Normalized control means that the sender controls the receiver by
providing an exact percentage. The receiver's new value is that
percentage of it's scale. Example: Sender sends 0.5 to receiver.
Receiver's range is 0-100. Receiver's new value is 50.
- Scalar control means that the sender controls the receiver by providing
a multiplier against the receiver's current value. The receiver's new
value is it's old value multiplied by the scalar. Example: Sender sends
1.2 to receiver. Receiver's current value is 50. Receiver's new value
is:
(50 * 1.2) = 60
NOTE: This could be defined another way, to make it linear across a
receiver's range, call it additive scalar control. The delta can be
calculated as:
((scalar - 1.0) * receiver_range)
Example: Sender sends 1.2 to receiver. Receiver's current value is 50.
Receiver's range is 0-100. Receiver's new value is:
(50 + ((1.2 - 1.0) * 100)) = 70
So I am all for B, and C might be useful. What think?
----------------------------------------------------------------------
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:
