Subject: Re: Processing data maintained with Core Data



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 s...

uggest 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@xxxxxxxxxxxxxxx)

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/maillists%40codeha.us

This email sent to maillists@xxxxxxxxx



Privacy