> > I am working on a DSP tool, and to be honest, performance is not really > *that* important to me. It feels to me like working with buffers of > samples as plain C arrays is more trouble than it's worth
Hmm…in what way are C arrays “more” trouble? For what you are doing they are easier to read, easier to write, more concise and vastly more efficient (2-3 orders of magnitude, so factor 100-1000. For all those shouting “premature optimization is the root of all evil”, Knuth’s paper with that line says that leaving 10% on the table should be considered criminally negligent). Of course, objects are also convenient and give you nice namespacing for complex functionality. Why not combine the two? Use MPWRealArray ( https://github.com/mpw/MPWFoundation/blob/master/Collections.subproj/MPWRealArray.h <https://github.com/mpw/MPWFoundation/blob/master/Collections.subproj/MPWRealArray.h> ) to encapsulate the notion of an array of reals. You will need to teach it how to create an array of reals that’s a hamming window, but that’s easy, vDPSP has a function built in: @implementation MPWRealArray(hammingWindowed) +(instancetype)hammingWindowOfSize:(int)size { MPWRealArray *a=[[[self alloc] initWithCount:size] autorelease]; if (a ) { vDSP_hamm_window( [a reals], size, 0 ); } return a; } @end Once you have the hamming window, you can just multiply the two together (if I understood correctly): MPWRealArray *hamming=[MPWRealArray hammingWindowOfSize:coreAudioBufLen]; MPWRealArray *audioData=[MPWRealArray arrayWithReals:coreAudioBuffer length:coreAudioBufLen]; [audioData multiplyBy:hamming]; This is one of those few applications where the ability to define binary operators like in Smalltalk would come in handy, so in Objective-Smalltalk, this would looks as follows: hamming ← MPWRealArray hammingWindowOfSize:coreAudioBufLen. audioData ← MPWRealArray arrayWithReals:coreAudioBuffer length:coreAudioBufLen. result ← hamming * audioData. Concise, clear, and fast. > And after I wrote this, I wondered-- would other objective-c programmers > find anything here offensive? A little, maybe. But I am considered “old school" > The fact that core audio initially gave me a c buffer, and I copies all > those values into an NSArray, and then this class expects that array and > creates a new mutable array, fills it with data from the other one, and > then copies it to stop it from being mutable.. This code is clearly not > efficient-- but it feels "convenient”.. I am curious: what feels “convenient” about it? To me it seems verbose, intention-obscuring, and yes, horribly inefficient. > Would you argue that I should in fact be using C arrays since they are > light-weight, fast, etc... ? After all, I am dealing with a buffer of > samples, which potnentially could be as many as 50k elements. I would argue that you should be using C primitive types when you are dealing with C primitive types. Wrapping them up individually in Foundation objects gains you absolutely nothing, and costs you dearly in writability, readability and efficiency. Cheers, Marcel
_______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
