[gmpi] Re: New Reqs 3.8 - Events
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 17 Dec 2003 20:13:05 +1300
On thing that's awkward about VST parameter changes, is the need to
'de-zipper', or smooth them.
e.g. the user is moving a volume slider and recording the 'events' for
automated mixdown.
The trouble is, you don't know the 'sample rate' at which events arrive.
When you receive one event, you don't know how much time you till the next
arrives. So it's difficult to provide good smoothing that works well in
different hosts.
Ramped events might be one solution to this problem. A continuous control
movement, broken down into short ramps (to approximate the original curve
whatever) would allow all plugins to provide good de-zippering (and the
results would be consistant accross different plugins).
Parameter change events are just another sampled signal, to reconstruct that
signal properly we need some indication of the event frequency, ramps are
one way to do that.
Best Regards,
Jeff
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, December 17, 2003 7:41 PM
Subject: [gmpi] Re: New Reqs 3.8 - Events
> On Tue, Dec 16, 2003 at 09:46:08PM -0800, Chris Grigg wrote:
> > Ah. Sorry, your meaning wasn't clear to me... and still isn't. A)
> > Are you saying this is only an issue if we make ramped events a
> > requirement, or is it still an issue even without ramped events? B)
>
> I think it only matters if we define ramped events. It's there now to
> differentiate from ramped events, mostly.
>
> > This sounds an awful lot like what I just asked about, i.e. is what
> > we're really saying that some controls want to be able to set their
> > own maximum rate of change per unit time? If it's this, then it's an
> > issue independent of ramped events.
>
> That's a separate issue. My first inclination is that this is the
plugin's
> choice to implement. Right? Wrong?
>
> > >How about 'immediate events' for the term? Or just a 'SET' event as
> > >opposed
> > >to a RAMP event? That was how designated them in XAP discussions.
> >
> > A) I thought we weren't agreed on whether ramp events are needed yet,
> > so how can we do this before that?
>
> Well, we should probably put a requirement it if we do define ramped
events.
> If we decide not to do ramped events, then maybe it is extraneous.
>
> > B) I know this is the Events section, but please address the
> > possibility of ramping as a trait of how a control responds to
> > events, not just as an event type. Doing this would allow controls
> > to protect themselves from control surfaces whose natural actions
> > (throwing a switch etc., large param changes, etc) might be so
> > drastic as to mess up the signal absent a bit of smoothing.
>
> I added a small bit of text saying that a (SET, NOW, Instantaneous,
> whatever) event might actually be subject to a fast smoothing. This is
> different than ramped events, though. A ramped event is more like saying
> "Mr. Plugin, please set parameter X to value Y over the next Z samples".
> The plugin can then smoothly interpolate the change, rather than receiving
a
> series of closely spaced discrete events.
>
> Now - do we need something like that? Doesn't AU have it?
>
>
> ----------------------------------------------------------------------
> 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
>
>
>
----------------------------------------------------------------------
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:
