Hello,
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 <http://www.cocoabuilder.com/archive/message/cocoa/2008/10/5/219446
> 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@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
