• 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 automation questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU automation questions


  • Subject: Re: AU automation questions
  • From: William Stewart <email@hidden>
  • Date: Wed, 12 Apr 2006 12:36:46 -0700


On 12/04/2006, at 12:43 AM, Frederik Slijkerman wrote:

Hi all,

I've got two automation-related questions regarding AU plugins. We're currently rewriting our automation code to use Begin/ EndGesture notifications because Logic on Intel doesn't support the older notifications.

- What is the recommended way to deal with older hosts that still expect the
kAudioUnitCarbonViewEvent_MouseDownInControl /
kAudioUnitCarbonViewEvent_MouseUpInControl notifications? Should we send
Begin/EndGesture to all hosts, and MouseDown/UpInControl to hosts that
provide an event listener (possibly duplicating the Begin/EndGesture
notification), or should we only send Begin/EndGesture to hosts that do not
provide an old-style event listener?

I would send both if the host has registered this MouseDown/Up callback.


- How should we deal with preset changes? In our plugins, this simply
changes all parameters of the plugin. In our currently available AUs, we
send out MouseDownInControl notifications for all parameters, then change
the parameters and call AUParameterSet as well, and finally send out
MouseUpInControl notifications for all parameters. Is this correct if we
only change the notifications to use Begin/EndGesture, or is there a better
way?

Yes = don't do any of this.

The AU has no responsibility to notify of parameter changes provided it is publishing its parameters correctly. This is why the default implementation provided for preset handling in AUBase just goes and sets the parameter values directly.

When the host sets a preset, it is responsible to tell all potential listeners to re-evaluate their parameter settings. It does this by using the "Any Parameter" wild card. An example of this can be seen in the AU Hosting application in the SDK. If your view has a restore/ set preset UI, then you can do what this app does with its Restore Preset button.

Bill

By the way, the generic carbon view code in the CoreAudio SDK still only sends out MouseDown/UpInControl notifications, so we couldn't use that for inspiration. :-)

Thanks a lot!

Frederik Slijkerman
FabFilter Software Instruments

_______________________________________________
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


References: 
 >AU automation questions (From: "Frederik Slijkerman" <email@hidden>)

  • Prev by Date: Re: Coreaudio-api Digest, Vol 3, Issue 116
  • Next by Date: Fwd: Coreaudio-api Digest, Vol 3, Issue 116
  • Previous by thread: AU automation questions
  • Next by thread: Re: Coreaudio-api Digest, Vol 3, Issue 116
  • Index(es):
    • Date
    • Thread