Re: Transport start/stop for Effect Units needed
Re: Transport start/stop for Effect Units needed
- Subject: Re: Transport start/stop for Effect Units needed
- From: Bill Stewart <email@hidden>
- Date: Fri, 16 May 2003 11:05:18 -0700
On Friday, May 16, 2003, at 01:42 AM, Paul Kellett wrote:
Chris Rogers <email@hidden> wrote:
Paul,
What type of action are you wanting to do in an AudioUnit effect
which relies on knowing exactly when the transport starts?
We already have AudioUnitReset() which hosts should be calling
in most conditions before the transport is started.
If the transition from "AudioUnit processing audio with transport
stopped" to "AudioUnit processing audio with transport running"
is always marked in some way the AudioUnit can pick up, that's ok.
AudioUnitReset() is designed to allow the AudioUnit to reset
its internal state, clearing filter memory, delay buffers, etc.
But that sounds like it would be bad for someone performing live,
who then presses "play" on the sequencer to seamlessly bring in
some backing - so doesn't want the current audio to be muted.
This is really a matter for the host app to deal with - ie, there is
most often more than just one effect that is involved in the whole
process of rendering lets say a track...
So - the host should be "preparing" you for usage after a period of
inactivity, and this would be done before it would be needed for real
time response - and most of the host apps do have logic around to deal
with this situation...
In many respects audio units are expected to be somewhat naive about
state and its up to the host to provide them the support they need
(like calling AudioUnitReset when something about the host's time line,
mute/active state, etc, has changed - ie. these are all user actions...
In that light as well, you can view Chris' suggestion - ie. if the user
is interacting with your units view to cause some significant change in
the state of what your audio unit should do, then your view should tell
the unit this - either with a call to AudioUnitReset to clear any
processing state, or some private property to provide a more fine
grained notification.
(Whilst on the topic:) - this is an area we've looked into and we'll be
discussing some of our thoughts about this at WWDC)
Hmm, maybe we mean different things - by "transport" I mean the
host's song position timeline which can be running or stationary,
and can instantly jump from one position to another.
I'm just curious to know what specific types of operations you
need to do in the AudioUnit at this time and if it's somehow
separate from our concept of "reset"
Triggering audio events in sync with the host's bars and beats.
I just want to make sure there is enough information available
that I don't ever miss a beat when I should have triggered
something.
Thus the music time callbacks that Chris described previously.
Look at HostCallbackInfo in AudioUnitProperties.h - Logic supports both
of these callbacks
Bill
Paul.
_______________________________________________
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.