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

Property notification questions


  • Subject: Property notification questions
  • From: Chris Reed <email@hidden>
  • Date: Wed, 12 Feb 2003 14:36:19 -0600

Hello everyone,

I have a question concerning property notifications coming out of audio units. Basically, I'm wondering what approaches other people have taken. I have code that works perfectly fine, but it just seems more complicated than necessary.

First, I am using private propeties to communicate information between my audio unit and its edit view. In this particular instance (I'll just pick one to make it easy to talk about), the property tells the playing state of an instrument/voice (playing or not playing) so the edit view can show graphic feedback when a note is triggered.

The problem here is that the notifications for this property are triggered from within the buffer rendering code, called inside an ioproc thread. Obviously, calling AUBase::PropertyChanged() is a bad idea here because that directly calls the property notification listeners and lets them do anything they want.

So I am creating a separate thread at audio unit initialisation time and passing any property changes to that thread in a nonblocking manner. The thread then pops items out of the queue and asks the audio unit to inform its listeners for that property.

Now, in my edit view property notification listener I would like to update the interface. But making any Control Manager calls will cause weird things to happen if it's not in the main event loop thread. So I create a one shot run loop timer with a delay of 0 (to fire immediately) and install it on the main thread's run loop. In the timer callback I can safely update the GUI.

Like I said, this all works fine. But it seems too complicated.

One thought I had was to have the property notification listener set the run loop that it wants to be called back on (just like parameter notifications). This would avoid having the listener callback installing a run loop timer itself. Or we could even skip the whole notification thread thing and install the run loop timer directly when the notification is triggered--but that would probably be bad for a realtime thread.

The only problem with the above idea is that AudioUnitAddPropertyListener() does not have a run loop argument.

How were property notifications supposed to work? What approaches are other people taking? I really really don't want to install a repeating timer and poll to update the GUI.

cheers
-chris
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Property notification questions
      • From: Kurt Revis <email@hidden>
    • Re: Property notification questions
      • From: Bill Stewart <email@hidden>
  • Prev by Date: Re: Troubles with MIDI input
  • Next by Date: Re: AU standard incomplete?
  • Previous by thread: Re: The Plugin Settings Approach
  • Next by thread: Re: Property notification questions
  • Index(es):
    • Date
    • Thread