Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...

The Filter's view allocates a block of memory that points to an array of typedef struct FrequencyResponse (defined in Filter.h)

When retrieving the values for these, the view passes a pointer to this block of memory and sets the size of the property to be the allocated size of this memory. The AU then sets the frequency response values into that memory.

In this scheme, there is no assumption that a view and its AU are running in the same address space. Some code can intervene in the middle of this process and pass the memory to/from the view/AU. The AU does not hold onto this pointer for later use, so it has no assumptions about it except as some address to write data too when it is called.

As a side note, the property is also implemented as an "on demand" property - the AU is not precalculating these values and storing them in local memory, but rather when queried the AU does the work, writing the results of that work to the supplied memory location.

All of the standard AU properties are implemented in this manner - the AU will either use the passed in value or copy the struct (for instance SetFormat) so that there are no dependencies or questions of ownership.

By "passing pointers" what is being referred to is the deliberate passing of a pointer (for example a this pointer) between the AU and the view and then what happens to the usage of that pointer. For instance, a View retrieves the this pointer from the AU, then proceeds to make method calls on this this pointer (or directly access data members). To take the example above, it would also be problematic if the AU having been given a pointer from this property call, would then turn around and cache this pointer internally and at some later time read or write to that memory. In both of these cases, the code that uses the pointer after the call completes assumes that the pointer is still valid, that the pointer is always in the same address space, etc..

Bill


On 20/06/2006, at 8:46 AM, Robert Abernathy wrote:


In a couple of my AU's, I use properties to pass data (in both directions AU->UI and UI->AU depending on the situation). I just pass a struct. It works really well. If you take the care to pass the data in formats like CFSwappedFloat64 and decoding with CFConvertFloat64SwappedToHost, you might save some possible future pains with your processes running on two different processor architectures as well. I'm not sure how legit it is to do this, but I save my properties to the presets using Save/RestoreState and using these calls was needed for the presets to work with universal binaries.

The property mechanism is pretty clean and just works once you get all of the calls and notifications set up.

Rob


On 20 Jun 2006, at 16:22, Richard Burnett wrote:

I'm confused, this is what the 'Filter' example is doing in the CoreAudio SDK. Specifically, I believe it is passing a pointer from the UI class back to the AU and then setting values in memory being pointed to.

It would seem to me that probably a lot of people do this, and what the property feature of the AU api would be used for, since it is specifically passing a void pointer.

Now, I agree, that I too would REALLY like to be able to run distributed AU's, as I run Digital Performer 5. How far is this feature off? 10.5?

What would be the suggestion? Not use properties and just keep two copies of my data, one in the AU and one in the UI and update them both on any changes from the host or UI?

Rick



Please don't - AUs are generally designed so that the view code and
the processing code can live in separate address space or even on
separate machines, and exchanging pointers between UI and core breaks
this design.
Consider an environment like Logic Nodes where the audio processing
can be distributed to remote machines for utilizing additional CPU
resources, while the UI is working on the main machine - there's no
way to exchange pointers there.
(Logic Nodes are currently limited to Logics built-in plug-ins, but
there's a strong user demand to open up this technology for AUs as
well.) 

Best,
Stefan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/coreaudio-api/rob% 40musicunfolding.com

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:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden

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:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden

This email sent to email@hidden
References: 
 >Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue... (From: Richard Burnett <email@hidden>)
 >Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue... (From: Robert Abernathy <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.