anti aliasing using sync interpolation using index
hi i am currently creating a scratching patch for max msp and am using the xb360 controller to control the scratching. i am using the index~ with a line~ object triggered by the controller object to create scratch the scratch is happening but it has a lot of aliasing i have been told by many people that anti aliasing using band filtering or sinc interpolation is the way to go to stop the aliasing but no one i know knows how to implement this in max if any one has any ideas or solutions would be greatly appreciated
thanks JPI
you could try this interpolating index object:
oli
cheers i will look into it i have changed my patch at the min to use groove and the speed of the controls rotation to get the speed and position of the loop which has seemed to work and has no aliasing but i will look into the iindex~ because i still want to go back and correct my old patch
thanks
While it will take different input, you may also want to experiment with [wave~] which includes interpolation.
JPI wrote on Tue, 03 March 2009 08:24.... it has a lot of aliasing i have been told by many people that anti aliasing using band filtering or sinc interpolation is the way to go to stop the aliasing but no one i know knows how to implement this in max if any one has any ideas or solutions would be greatly appreciated
thanks JPI
I'm not sure that you can actually implement this in max very easily, or in a way that is cpu efficient - You'd need multiple (probably at least 32 or more) index~ objects reading consecutive samples, with multipliers for each value to do either the interpolation / filtering - if you're filtering (rather than using sinc interpolation) you'd also need to interpolate again (doubling the code).
Reading the above It would seem that people might be confusing two different causes of aliasing. The type you've been experiencing is due to not interpolating your output samples when you need to read 'between' two samples. The other reason for aliasing to occur is because you are playing back sounds faster than they were recorded - aliasing occurs due to frequency content that is now above the nyquist frequency (half the sampling rate) wrapping round into the representable frequency range (ie. it appears lower down).
The first problem can be solved by using an object such as Oli suggests, or groove~, or play~ (which is driven in milliseconds, but allows you to access the buffer in whatever order/pattern you wish). These use cubic interpolation to generate their output.
The second requires filtering of the buffer to eliminate any frequency content that will alias. That is more complex and having spent a long time implementing an external to do soemthing like this (which is still not quite finished) I wouldn't advise trying to do this in max - aliasing of this kind is generally only a problem with speeds of 4x greater than recorded that has strong upper partials (e.g. harmon muted trumpet).
Regards,
Alex
cheers alex i knew it wasent the index as this was happening in play~ and groove~ as well which was my first thaught before i posted this thread i knew it was the the aliasing due to the effect of nyquist theorem on the speed of playback but i had been told that sinc interpolation could solve this but like you said it is very hard to sort in max one option i have found is to resample at 88.2 kHz and set the sound card to this sample rate then create a low pass filter at 44.1 kHz which theoreticaly should work will try that
cheers
JPI
JPI wrote on Tue, 03 March 2009 14:38one option i have found is to resample at 88.2 kHz and set the sound card to this sample rate then create a low pass filter at 44.1 kHz which theoreticaly should work will try that
cheers
JPI
You might want to try something with upsampling using poly~, which might save the cpu for anything in your patch that doesn't need to run at a higher sampling rate.
If you get something working I'd be interested to see it.
Thanks
Alex