• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Garageband 3/audio units odd behaviour
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Garageband 3/audio units odd behaviour


  • Subject: Re: Garageband 3/audio units odd behaviour
  • From: Jim Wintermyre <email@hidden>
  • Date: Thu, 8 Feb 2007 12:37:16 -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.

One could also argue that an issue with this approach is the CPU load sees a lot more jitter. This is a major issue when using a computer for live performance. If your app stops calling render calls whenever it thinks it doesn't need to, then simply rearranging the audio can now cause CPU overloads at places where it didn't happen before. Of course the downside to always calling the plugs is the higher host load, but the load stays more consistent. I guess it's more of an "external hardware" view of the world, which makes sense when performing live.


The "non-live" approach can also cause issues with plugins that process audio on dedicated external hardware :), which has to manage those resources.

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.

My $.02 on the merits of the other approach...

Jim
_______________________________________________
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


  • Prev by Date: Re: vDSP_conv very slow
  • Next by Date: Re: vDSP_conv very slow
  • Previous by thread: Re: Garageband 3/audio units odd behaviour
  • Next by thread: implementing an AudioHardwarePlugin
  • Index(es):
    • Date
    • Thread