[gmpi] Re: New Reqs 3.8 - Events
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 18 Dec 2003 13:06:10 -0800
>>>
I guess the question is whether the group believes that any performance
boost from supporting non-timestamped control-setting events would outweigh
the burden of supporting two different kinds of event timing models.
<<<
My $0.02:
I would prefer one timestamping model that could describe just-in-time
events as well as "streamed" events.
Yep, I think everyone pretty well agrees on that now.
(To me an event means a parameter
change or a note-on/note-off... isn't a note merely a kind of parameter?<g>)
Yeh, well, don't get me started...
Actually 'event' is the best superclass/group-name for these things.
DirectX supports 2 different kinds of event setting (one via SetParam, and
the other via envelopes), and it really gets complicated. You can get
situations where envelopes can fight with just-in-time changes, and it's not
clear who should win. Maybe that problem doesn't go away in a single
timestamped model, but at least with the simpler model you can say, "the
last one in, wins."
I think it would be good to look at this first from a user
perspective, not an API perspective. I mentioned the same problem
before vis-a-vis multiple control surface widgets targeting the same
parameter, and it's also true for real-time events targeted at a
parameter that's also being driven by a seq track, etc. etc. etc. I
asked whether plug pins could or should be able to designate their
own max update rates and preferred event sources, ignoring events
from any other source, and somebody else (Tim probably) suggested
this could be seen as a host issue, i.e. don't assign too many
sources to the same dest param. Ideas? Maybe pins can have hints
along the lines of "one source at a time", max update rate, that the
host can optionally honor?
That said, I also like the idea of shape events, to give a compact way to
specify smooth parameter transitions. Hopefully this can be made to work in
a timestamped model.
I'm sure it can. Generalize both kinds of events up to 'control
points' on a curve; simple param setting events are just jump-to
events, leaving room for linear control point types (plus eventually
other curve-spec styles like bezier, spline, etc.).
Note, adding parameter ramping events has an interaction with the
event lookahead buffer issue. You can have a rampAtThisRate event
without lookahead, and of course you can have a jumpToThisValue
event, but you can't have a rampToThisValue event.
-- 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:
