Re: "Ramp Automation" and AU's
Re: "Ramp Automation" and AU's
- Subject: Re: "Ramp Automation" and AU's
- From: Bill Stewart <email@hidden>
- Date: Thu, 24 Jul 2003 23:45:39 -0700
On Thursday, July 24, 2003, at 07:19 PM, Gary Affonso wrote:
There's a thread raging over on the MOTU-Mac list regarding AU's and
something being termed as "ramp automation". It's not entirely clear
what
ramp automation is, the best anyone has done is to say that it's a more
finely grained form of automating an AU's controls/parameters than the
"other" (non-ramp) kind of automation available.
The problem is that it's been claimed that AU does *not* support "ramp
automation" while Motu's plug-in architecture (MAS and MAX-X) do.
This is
being touted as a benefit of MAS-X over AU (the only unique benefit
mentioned so far, by the way).
Hmmm.. well we had significant input from MOTU about adding this
capability to AU, and the shape (ha ha!) of this owes a great deal to
their input.
I think the thread has been put to bed with a recent post indicating
that
AU's *can* do ramp automation but that it's up to the plug-in
developer to
implement. But that answer came second hand from a non-developer so I
figured I'd ask here.
The questions:
1) What is ramp-automation exactly? How does it compare to non-ramp
automation? If there's a doc or a url somewhere that can more clearly
define this please just point me to it.
Not a great deal of docs..
You should look at the AUComponent header file's
AudioUnitScheduleParameter and its accompanying AudioUnitParameterEvent
Its mode of operation is fairly simple.
The host provides a start and end value of the parameter.
The host is required to reschedule the ramp each time it asks the AU to
render
It increments the sample count field to describe the progress through
the ramp
It is required to specify the duration of the ramp.
It is expected that the AU will apply an "appropriate" curve to the
ramping - the host walks through the ramp in a linear fashion (ie. it
just walks through the sample progress in a linear fashion)
We've had some discussion on this list about providing a way to specify
different curves for parameters, but as parameters are described in
units appropriate (ie. in logarithmic, linear, etc), there isn't a
basic reason (ie. this parameter should really ramp in a linear or
logarithmic fashion) - so I'd still consider this an open issue. We had
generally considered that curves would be approximated with the line
segments of the current API
How does it compare?
Others can comment on this in more detail - its a long answer..
"Ramping" is achieved in some hosts by setting parameter values and
rendering small amounts of samples, set a new value, render again,
etc...
At least with the AU specification, parameter values can be scheduled
intra-buffer, so this quantization of parameter values to buffer
boundaries is not a requirement (or even recommended) practise of AU
hosting... Personally, I think the most telling difference, is that a
ramp allows a change of value applied in a smoother manner, with an
ability of the AU to react differently to a ramp, than to individual
parameter changes.
2) Does AU support Ramp Automation?
Yes - in fact some significant amount of work was done in AUBase (ie.
the AU's public implementations) to support intra-buffer scheduling of
parameter change values and ramping. This was released in the Dec 2002
SDK (The API was first published in Jaguar - ie. 12 months ago)
The AU is required to indicate in its published parameter info struct
that a particular parameter can be ramped.
In 10.2.3, the MusicSequence API was revved to support parameter ramps,
with a new track type that takes parameter events. It interprets
parameter events as marking the start and stop of a parameter ramp, and
thus, fully supports ramped parameters.
We've implemented ramping on some of the parameters of our AU's
(notably I think at his stage the mixer params)...
3) Assuming support, are there versions of the AU spec in which
ramp-automation is not available? In other words, was it not
implemented in
an early version of the spec but maybe in a new (perhaps not yet
released)
version?
V1 units did not support parameter ramping (10.0->10.1). V1 units are
severely deprecated and anyone asking questions about implementing V1
units will be flogged! :)
4) Is it, indeed, an optional feature to implement at the discretion
of the
plug-in developer?
Yes
5) Any indication of how widely plug-in developers are allowing
automation
(ramp or not) of their parameters?
No idea - I suspect with hosts supporting this, that this will strongly
encourage developers to provide ramping support of their AU parameters.
I would hope MOTU would provide this with their AU support, but you
would have to direct that question to them.
Sorry for the somewhat clueless nature of this post, any info is
appreciated.
No problem - feel free to forward this post to the MAS list (and invite
people there to ask questions here if they want to know or comment on
AU issues - we generally don't tend to lurk on these lists, so I
appreciate your questions and chance to respond)
Bill
- Gary
Server Side Software
5614 8th Ave NE
Seattle, WA 98105
Voice: (206) 525-4786
Fax: (413) 683-2973
Email: email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.