• 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: more AU info and plugins (should be "I need to share data")
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more AU info and plugins (should be "I need to share data")


  • Subject: Re: more AU info and plugins (should be "I need to share data")
  • From: Philippe Wicker <email@hidden>
  • Date: Sun, 22 Jun 2003 03:25:56 +0200

On Sunday, June 22, 2003, at 12:40 AM, Marc Poirier wrote:

First of all, how would share that pointer?

I do this with Set/GetParameter, private scope and ID, and a little
kludge (a union) to pass my pointer as a Float32.

But how? Your two audio components have no awareness of each other. How
does one know anything about the ComponentInstance of the other?

I just don't think that this example pertains to the topic at hand. What
we are talking about are components that *are* aware of each other via the
Component Manager (like a GUI component with respect to an audio
component).

Not completely clear on this point. I think of 2 approaches. In both cases the AU are linked with a framework which embeds a sample manager. This sample manager instance is created by the first initialized AU and destroyed by the last cleaned up AU, its address is saved in a global variable and may be accessed via an internal API. From here I may either use Set/GetParameter in the GUI components using the scope as a selector and the element as a parameter, or I can link the GUI to the framework which embeds the sample manager. In this case, the sampler manager is a kind of server providing services to all instances of AU and GUI. I don't need anymore the kludge around Set/Get. Components have no awareness of each other. The communication between AU and GUI can follow the rules. The first solution is easier to write but a little bit dirty, the second is more difficult but much cleaner and may be more flexible on the long term. By encapsulating the sample management, it allows to transparently change a RAM-based-implementation by a streamed-from-disk one. Finally I find this discussion really helpful :-)))


But anyway, it would probably be better for someone from Apple to
clarify this all than for us to continue to wittle out our best
interpretations...

I agree. Wether we use pointers or not, the earth will continue to
revolve :-)

Hmmm, I'm not sure, I don't see anything about that in the API docs... ;-)

Really nothing? We should file a bug then :-))

Philippe Wicker
email@hidden
_______________________________________________
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: more AU info and plugins (should be "I need to share data")
      • From: Marc Poirier <email@hidden>
  • Prev by Date: Re: more AU info and plugins (should be "I need to share data")
  • Next by Date: Re: more AU info and plugins (should be "I need to share data")
  • Previous by thread: Re: more AU info and plugins (should be "I need to share data")
  • Next by thread: Re: more AU info and plugins (should be "I need to share data")
  • Index(es):
    • Date
    • Thread