[gmpi] Re: gmpi Digest V1 #65 topic: Inter-parameter linkages
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 13 Apr 2004 19:57:17 -0700
On Wed, Apr 14, 2004 at 12:37:32PM +1200, Jeff McClintock wrote:
> Agree totally, Parameter values are stored in the host. The host may
> provide the user a simple interface for setting parameters ( a host-provided
> GUI ).
Well, there really can't be "parameter memory" can there? There is never
a "current" value of a parameter, just a value at a certain time (since
"now" will loop once for each plugin).
Example:
- Assume buffers of 128 samples
- Plugin A runs
- Plugin A sets param P to value N0 at time offset +0
- Plugin A sets param P to value N1 at time offset +63
- Plugin A is done
- Plugin B runs
? What is the current value of param P at time offset +0? It must be N0,
but if you think of a param as a variable in memory, it is not. It has
already been overwritten.
It's just confusing to me to think of a parameter as a variable in memory.
There is no "current" value of a parameter. Parameters may well be in
flux at any given time.
Further, ramping is supposed to be handled by the DSP, or so we had
basically discussed. Isn't that akin to a DSP changing it's own params?
we can take ramping out of plugins altogether and make it a
host-feature...
> > the downside to this model (and its not much of a downside) is that
> > the plugin has to provide *all* the necessary information about the
> > parameter to the host.
I think this is the rigth thing to do anyway.
> - The Actor is in a position to randomise the parameters.
The only place this fails is on continuosly variable actions. Doing an
ongoing randomization which never ends is not possible unless the actor is
called repeatedly with no input.
It also gets confusing for long-term events. Back to morphs. Imagine
that you trigger a morph between two presets over 5 seconds by pressing a
morph switch in the UI. The actor would receive this event and would send
a stream of events which are due WAY outside the current timeslice. This
is probably OK. We can build all that into the host to discard those
future events in case of a jump, but what about the more complicated case.
Imagine that you trigger a morph between two presets over 5 measure by
pressing a morph switch in the UI. The actor would receive this event and
would send a stream of events which are due WAY outside the current
timeslice. Now change the tempo. All those events need to be changed.
Yuck!
Now let's go further and assume you want to trigger the morph by a MIDI
note. How?
Assuming that gets solved reasonably, what happens when you send a morph
on C0 (morph to patch B) then send a morph on D0 (morph to patch C). You
have a lot of queued up events to sort through and discard.
All because we have introduced a future.
Actors work well for instant changes: linked knobs (L and R gain on some
stereo plugs is a great example we missed - they may or may not be linked)
or clipped knobs will work pretty well.
----------------------------------------------------------------------
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:
