Re: Garageband 3/audio units odd behaviour
Re: Garageband 3/audio units odd behaviour
- Subject: Re: Garageband 3/audio units odd behaviour
- From: William Stewart <email@hidden>
- Date: Thu, 8 Feb 2007 11:57:12 -0800
On 08/02/2007, at 7:59 AM, Muon Software Ltd - Dave wrote:
It's not an architectural difference per se - either architecture
supports that approach (as does RTAS), it's simply that most
implementations of VST - and indeed AU - happen not to work that way,
most of the time.
...and therein is the essence of my point. GB3's behaviour is
unusual in the
wider context.
And arguably more correct. GB and Logic are apps that are primarily
built around sequencing events. If you have 10s of tracks with
plugins in each track, and only say 15 or 20 tracks are actually
active at any time, why should the other 60 tracks be consuming CPU
and probably taking away your ability to run as many AUs that you
otherwise could? That seemed to us to be a poor user experience,
particularly when with the addition of some information (latency and
tail times) a host could determine based on its events and timelines
when a plugin is meant to be active.
AULab is different - it doesn't have a time line as its purpose is to
be used in a "Live" context. However, if you mute a track then it
will stop sending events and will stop calling that chain (for
exactly the same reason - to not consume CPU resources when it isn't
needed). In the upcoming version in Leopard, we've also added patches
to this that enable you to have pre-set active and de-active tracks.
This is an even more important issue when you consider the
differences in CPU architecture - all of our current CPUs have to
trade off capability(speed), power consumption, heat generation. This
can have a major impact on your ability to do processing.
I know there are other reasons and approaches to this - but I think
there is alot of merit in the approach that the AUs through Logic/GB
take to this matter.
Thanks
Bill
In any case I have done what Stefan suggested and filed an enhancement
request. In the meantime, I'm going to take good note of Angus's
suggestion
and put some defence into the code so it can detect if the audio
thread
stops polling our render function.
Kind regards
Dave
_______________________________________________
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
--
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
________________________________________________________________________
__
_______________________________________________
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