Processing data maintained with Core Data


I've been scouring the list archive while I'm learning to use Core Data, which has been a big help with many questions. But now I have a question which I've not found answered elsewhere.

Brief background: I'm porting an audio generation system to Mac OS. The code for generating audio is in C and has run on a couple of other OSs. It's been reasonably straight forward to model the parameters for this system with Core Data, and I'm excited about getting CD to handle multiple Undo and all that sort of stuff for me.

Wwhat I'm not clear on is if there is a "best practice" for communicating the state of the object graph with the processing code (in my case, the audio generator). The data model consists of a main entity with something over two dozen parameters, and has a to-many relationship with a second entity that encapsulates information about soundfiles that are played back and mixed in real-time.

One obvious approach would be to modify the existing C code to access the parameters from the object graph each time through the audio processing loop. Aside from the fact that that would mean rewriting a big chunk of the existing audio generation code, I'm a bit leary of the overhead of using KVC/KVO from the audio processing thread. But a major rewrite would be sort of a deal breaker.

When I saw mogenerator, I thought this might be a useful tool for my task. I thought I could use this to override the default setter accessors to communicate changes in parameter settings to my existing code (and then call [super set<Key>]). But this would mean that I would have two copies of each property (one in the object graph and one in the back end code). In principle I avoid duplicate data, but maybe in this scenario it's not that evil. OTOH, there has been criticism of mogenerator, for instance <

> ff., especially from mmalc, who seems to be a respected contributor.

So, is there a better way to do what I'm after?

Thanks for your attention; hope the description is clear enough; as always, pointers appreciated as well as direct answers.

-- Peter

Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)

Help/Unsubscribe/Update your Subscription:

This email sent to maillists@xxxxxxxxx