[gmpi] Re: Reqs 3.8 Events - ramped events
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 12 Jan 2004 17:48:17 -0800
On Mon, Jan 12, 2004 at 09:53:26AM -0700, Mike Berry wrote:
> GMPI hosts shall provide translation facilities for connections between
> plugin controls which share a primary type but differ on secondary
> characteristics (such as ramping support).
I'm no longer conveinced we even need this requirment at all. If we mandate
that hosts allow ramped outputs to send to a non-ramped input, we force
every host to insert ramp->point converters. Better, I think (I know I
flip-flopped on this a bit), is to assume all real-number inputs are capable
of some semblance of ramps. If your input LEGITIMATELY is not capable of
ramps, you may want to consider a non-float type, or just handling ramps as
points. If you *should* be ramping but aren't, your plugin will just sound
worse than it could.
What think?
As for the case of very long ramps, I've had a read of the AU docs. It
works like this:
you must send a ramp event each buffer, but they all refer to the same ramp.
They use a start-time and a duration. To quote a bit from the CoreAudio
docs:
For instance, you have a parameter that you wish to ramp from a value of
0.5 to 0.8. You want this ramp to last for 2000 samples, and at the time
you want this to start, it should start 400 samples within the current
buffer. We'll also assume that we have a render buffer size of 512
samples. This situation would be scheduled like this:
startOffset durInFrames startValue endValue
First Schedule: 400 2000 0.5 0.8 - 1st buffer
Second Schedule: -112 2000 0.5 0.8 - 2nd buffer
Third Schedule: -624 2000 0.5 0.8 - 3rd buffer
Fourth Schedule: -1136 2000 0.5 0.8 - 4th buffer
Fifth Schedule: -1648 2000 0.5 0.8 - 5th (last)
The scheduling first indicates where the ramp event should start. The
second and consequent schedule events (done before each consequent
buffer), indicate with the negative number how far into the ramp we are
for the next render cycle.
The curve that is applied to a ramped parameter is determined by the
Audio Unit itself. This allows the host to just specify the progression
of the curve in a linear manner (as described above). If a host wishes
to apply a non-linear curve, that can currently be approximated through
smaller line segments. This may change in the future with the additions
of standard properties to allow an Audio Unit to have particular curves
applied to ramped parameter values.
It may not be perfect, but it's interesting.
----------------------------------------------------------------------
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:
