Re: "Ramp Automation" and AU's
Re: "Ramp Automation" and AU's
- Subject: Re: "Ramp Automation" and AU's
- From: Gary Affonso <email@hidden>
- Date: Fri, 25 Jul 2003 09:47:27 -0700
Thanks for the excellent information!!
- Gary
On 7/24/03 11:45 PM, "Bill Stewart" <email@hidden> wrote:
>
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.
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.