On Mar 27, 2009, at 08:08, Peter Castine wrote:
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.
Assuming that you want to avoid rewriting the existing C processing
code (which seems like a laudable goal), the key question seems to be:
what is the thread safety model of your existing code? Generating
audio from parameters and file lists held by a different thread seems
disaster-prone, so presumably your code doesn't do that, but you also
suggest you currently don't have 2 copies of the data, so maybe your
code *does* do that.
The other question that comes to mind here is: why Core Data? Core
Data may simplify your life if you have a very complicated (database-
ish) data model, or if you have very many (tens of thousands) data
model objects, or you have some very large (MB-sized) data model
attributes. If your data model is as straightforward as you make it
sound, Core Data may not add much value, and may well bring an entire
world of pain to your formerly sunny universe. (This list is littered
with Core Data survivors, living the wrecks of their lives one-to-one
relationship at a time. ;) )
Based on the information you've provided so far, I'd suggest you
snapshot your data model (into a C struct) and pass it off to your
background processing thread, where is can be used by your nice,
tested C code.
FWIW.
_______________________________________________
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
