Anybody read this?

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumb er=5299036&contentType=Journals+%26+Magazines&sortType%3Dasc _p_Sequence%26filter%3DAND%28p_IS_Number%3A5446581%29

I can't tell if there's enough new stuff in there to warrant plunking down the $30 for a copy.

If you have a university in town you can usually go to their public library and even as a guest get access to these papers.

Unfortunately I'm nowhere near a real university but maybe I'll make up a list of papers to use the next time I am. It looks like there are several papers in that issue that are relevant for DSP coding.
Last edited by kuniklo on Fri Apr 27, 2012 2:31 am; edited 1 time in total

I took a quick look at the paper and I'd say it's not worth the trouble if you're looking for high quality methods. Not only does the quality kinda suck (ie the perceptual model of hearing assumes people are near deaf), it's yet another method involving leaky integrators and everyone knows how practical those are when you want to add a bit of modulation.

New stuff? Maybe a bit, and I'm not sure if BLIT-based hard-sync has been explained before, even though it's rather obvious... but new stuff worth actually using? Not really, unless you're on a super-low CPU or memory budget.

Thanks very much for the short review. I guess I'll save my cash and get back to wrapping my head around a sinc lookup table implementation.

Looks to me that you can achieve exactly the same results with polynomial BLEPs (just preintegrate the interpolator responses), but without the typical BLIT DC offset trouble.

is this thread from now, or ten years ago?

What was the reason to choose the sinc lookup (I assume you're doing BLIT?) against the closed-form expression for BLIT or using BLEP? To me the benefits of the sinc lookup in BLIT against the other two are not obvious.

The article is from 2010 Personally I'm still fascinated by the fact that you can 100% avoid inharmonic aliasing with BLIT. Pity there are DC offset and hardsync problems

Two reasons:

First, I wanted to see if a table lookup would be significantly faster. sinf seems to be fairly expensive on ARM chips.

Second, just to get my head around windowed sinc because I know it's also useful for resampling, variable delay etc.

why don't you use the squared parabolic approximation for sine/cos?

I haven't tried it yet but I should probably look into that too.

I'm porting some code I originally wrote for x86 and I'm now appreciating what a luxury it is to have such a fast processor.

OK, depending on the architecture you may be right. BTW, I didn't suggest using sinf, but rather custom minimax approximations of sine (which don't need to have 32bit precision as sinf). I'm just tending to stay away from table lookup on modern general CPUs, because the cache pollution gets more and more critical and difficult to predict

Actually I'm doing some testing now on an iPad 2 and a BLIT using sinf seems pretty comparable to a wavetable lookup, so maybe the closed form is ok. The last time I tested this was on an iPad 1 and saw more of a difference there.

I haven't tried some of the sin approximations though so that might be interesting.

blep is pretty much guaranteed to be at least twice as fast. just depends on exactly what you're using it for.