> I am curious: what feels “convenient” about it? To me it seems verbose, > intention-obscuring, and yes, horribly inefficient.
I guess the convenience in my mind is 1) not having to worry about malloc/free, and 2) the ease of being able to do [buffer copy]. Sent from my iPhone On Mar 2, 2015, at 2:14 PM, Marcel Weiher <[email protected]> wrote: >> >> 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 > ) 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]
