• 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: AU hosting: automation, presets and GUI updating
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU hosting: automation, presets and GUI updating


  • Subject: Re: AU hosting: automation, presets and GUI updating
  • From: William Stewart <email@hidden>
  • Date: Wed, 4 Nov 2009 12:08:28 -0800

Its your host app that is the problem.

There are two things that the host needs to do that I think you aren't doing.

(1) AudioUnitSetParameter is not sufficient when you change the value of a parameter with views around. You should look through <AudioToolbox/AudioUnitUtilities.h> - there are two alternatives there:
- AUParameterSet (which both calls AudioUnitSetParameter for you, and does the AUEvent listener notify)
- Call AudioUnitSetParameter, then AUEventListenerNotify


(2) When you set a preset on and audio unit, you have to also send a notification that parameters have been changed. These easiest way to do this is to use the following code:
// notify parameter listeners that they should re-scan unit
AudioUnitParameter changedUnit;
changedUnit.mAudioUnit = mAudioUnit;
changedUnit.mParameterID = kAUParameterListener_AnyParameter;
AUParameterListenerNotify (NULL, NULL, &changedUnit)


The background to this is that we separate the direct implementation of changing the state of the model (the audio unit with its parameter values) from the notion of control and views updating their state, etc.

Any audio unit that responding "correctly" when your host is NOT doing the above is actually doing more work than it needs too and ends up causing unnecessary thrashing on the system as the AU event notification system is being pinged twice (probably more if the code is not really tight)

There are some tech notes on this topic and the AUHosting examples we ship show you what to do with presets (2) above. The demo code for the AUFilter, etc, shows how a view uses (1) to set parameters on its audio unit (which is the same as what the host does when automating). AULab is also a good test bed (as already mentioned)

Bill

On Nov 4, 2009, at 6:10 AM, Paul Davis wrote:

On Wed, Nov 4, 2009 at 8:15 AM, Olivier Tristan
<email@hidden> wrote:

If I were you I would check if the same issue happen in AULab (regarding
factory presets). Always a good test.

We've already had users who have confirmed that the plugins behave differently in Logic and at least one other host. But I'll check AULab as well, thanks. _______________________________________________ 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

_______________________________________________ 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
  • Follow-Ups:
    • Re: AU hosting: automation, presets and GUI updating
      • From: Paul Davis <email@hidden>
References: 
 >AU hosting: automation, presets and GUI updating (From: Paul Davis <email@hidden>)
 >Re: AU hosting: automation, presets and GUI updating (From: Olivier Tristan <email@hidden>)
 >Re: AU hosting: automation, presets and GUI updating (From: Paul Davis <email@hidden>)

  • Prev by Date: Re: AU, plugin tempo, musical time information
  • Next by Date: Re: AU hosting: automation, presets and GUI updating
  • Previous by thread: Re: AU hosting: automation, presets and GUI updating
  • Next by thread: Re: AU hosting: automation, presets and GUI updating
  • Index(es):
    • Date
    • Thread