Re: Logic Live mode/PDC
Re: Logic Live mode/PDC
- Subject: Re: Logic Live mode/PDC
- From: Stefan Gretscher <email@hidden>
- Date: Fri, 9 Jun 2006 02:32:47 +0200
On top of what Bill already said, some additional comments below...
Am 09.06.2006 um 00:03 schrieb William Stewart:
On 08/06/2006, at 9:47 AM, Tom Davies wrote:
This is more a question about Logic as a host than it is Core
Audio, but I
would imagine quite a few people on this list will have had
similar problems
to me, and so I hope someone might be able to give me some hints.
I've seen
some discussion in the Archives about this issue but couldn't find
an answer.
I am writing plugins that have a latency which a fucntion of the
MaxFramesPerSlice value. In Logic's "live" mode, the process calls
are made
with the hardware I/O setting, rather than the Process Buffer
Range value. if
it is lower.
No MaxFramesPerSlice call is made by Logic to tell us that this
change is
going to happen, so as far as our plugins are concerned, they are
still
running with blocksize of (eg 1024). This obviously defeatst the
purpose of
live mode, and I would like our plugins to adapt to the new, lower
blocksize.
The host should set max frames in an intelliigible way - for
instance, AULab will do this to have this value for each AU
coincide with the I/O size. For eg, if the client sets the I/O Size
to 64 sample framess, AULab will set all of the max frames to 64 -
and it will of course never call you for more than 64 samples at a
time.
Logic's rendering is more complex as it is dealing with both
rendering from pre-recorded tracks as well as real-time. But it
should (or could) adjust max frames to reflect which situation an
AU is running in and then you could reliably use this figure to
make the decision you need (including the latency you incur)
In Logic, switching "Live mode" happens during playback, depending on
the user interaction (e.g. track selection for instrument tracks).
Changing MaxFramesPerSlice requires to uninitialize the AU and then
re-initalize it, thus this process would break playback...
First question: is there a 'proper' way for a plugin to know it is
being called in Live mode?
No, because normally an AUs should not care about processing buffers
of varying sizes smaller than MaxFramesPerSlice.
By default it is called in "Live mode" - if a host is taking you to
an offline context (Logic's track freezing), then it sets the
offline property.
Tom was using the Logic terminology, not the AU terminology. In
Logic, certain tracks can be temporarily rendered at a lower latency
by reducing the buffer size used on a track to accomodate for playing
live instruments on this track. This so called "Live mode" depends on
track selection and can be changed by the user during playback. Both
the "Live mode" and the "Playback mode" tracks in Logic are rendered
in realtime, thus "Live" in AU terminology.
The workaround I have implemented is that our plugins check the
number of
samples in each process call against the 'official' blocksize, and
if this
differs, they re-gear themselves to the new incoming value. I have
found this
to be a valid approach, as I am yet to observe Logic make any
process calls
with a number of samples other than that specified in Process
Buffer Range,
unless it is in Live mode. Obviously, if Logic started calling our
plugin
with varying numbers of samples, then this approach would not work
at all!
Its possibly a fragile assumption. There's not restriction placed
on a host that it calls you in regular slices - and indeed if you
are up stream of an AU like a varispeed or the time pitch
(something you could be in AULab for instance), then you will see
irregular (both in time distances and frames/slice) calls. We
expect AUs to deal with this - and in the past most AUs that have
more complex situations (for eg, hardware accelerated) have an
internal buffering scheme to deal with this as you describe.
In general I don't think it is a good idea to be changing your
latency on the fly like this = ideally this should be set as a
value when your AU is initialised, and shouldn't change as a result
of the host calling you in a different manner. How is a host meant
to react to an AU that suddenly changes its latency just because it
calls you for a different number of samples?
Bill
Second question: Can I make this assumption? I know that the AU
spec allows
hosts to make process calls with any number of samples up to this
value, but
in practise, Logic seems to always call with a consistent number,
just as
Live!, and Cubase do (and FL Studio)/Sonar do not!)
No, you cannot make this assumption. Set Logic's preferences to
sample-accurate automation of plug-in parameters, automate some
parameters and you'll find that the buffers will be chopped and that
there's parameter changes between the buffers according to the
automation.
If this is a valid thing to do, I still have a further problem.
After the
plugins have re-geared themselves to the new lower blocksize,
their latency
have obviously decreased. However, Logic does not seem to make any
latency
inspections after putting a channel into Live mode, and so the PDC
is messed
up - it still thinks the plugin has the latnecy it did when it was
being
called with the larger blocksize.
Logic only adjusts the latency when playback is stopped - how should
it shuffle latencies while playing back without glitching?
Third question: Can I force Logic to have another look at the new
latency value?
No, because it would glitch.
Best,
Stefan
------------------------------------
Stefan Gretscher
plug-in development & 3rd party plug-in support
Logic Pro team, Apple Computer
email: email@hidden
phone: (+49)-4101-495-586
(Central European Timezone)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden