Crackling Audio after Processing

    Jul 10 2011 | 8:17 pm
    Hey folks,
    Ive hit a bit of a brick wall with a patch im working on. Its basically an ambisonic panner which allows me to pan signals in realtime. The issue is that the signals produced have a horrible distorted quality which isnt really noticable on something like a sawtootch wave but on sounds like sine waves and piano its extremely noticable. Below is an example of the kind of processing involved.
    The faster I pan (or in this case the less time the line takes to ramp) the more apparent the crackling becomes.
    Is there some way of eliminating this distortion while keeping the amplitude changes produced?
    Any help would be much appreciated!

    • Jul 10 2011 | 9:21 pm
      Does this work? It sounded like 'zipper noise' to me, which is why I send the [cos] output as a signal:
    • Jul 11 2011 | 12:02 am
      Hi Mick,
      Are you aware that your algorithm produces negative numbers at a certain point to control the volume? They should be all between 0. and 1.
    • Jul 11 2011 | 3:46 am
      Hey Jan,
      Thanks for the reply, one of the principle ambisonics works on is the that there are out of phase signals generated to stabilise the soundfield. I dont think the negative values are the problem. Ive got a feelin the problem is related to the movement between the values. Its as if the wave is being chopped up. Below is another version with just positive valus for the signal.
      Any Ideas?
      Thanks in advance
    • Jul 11 2011 | 3:57 am
      @ Brendan,
      Thanks for your reply to! fraid that had no effect. when I put the line ramp time to 1000 an even make sure the values are positive still sounds like a zipper.
      It should just sound like a couple of dips in volume
      Thanks again for the reply
    • Jul 11 2011 | 8:13 am
      Hi Mick,
      I didn't know that with the out of phase approach so indeed than it shouldn't be the cause.
      Here I added a [line~] object at the and of you number generating part to have smooth ramp. Maybe this can help.
      there is also the possibility to to play around with the ramp time in the message box.
      A third Idea would be to build the who number generating part as a signal - part.
    • Jul 11 2011 | 11:19 am
      I got zipper noise too; I ripped this from the [pan2] helfile, see if it, erm, helps:
    • Jul 11 2011 | 12:25 pm
      Jan thats brilliant, works a treat! Thank you so much! Now over to the Java forum to find out how to translate this to a nice efficient mxj object.
      Thanks again,
    • Jul 11 2011 | 12:42 pm
      de rien .. ;)
      And here is is my unrequested smarty-pants extra:
      ... the trick is that the max scheduler, that takes care of messages etc. is relatively slow. It's fasted possible pace is 1 message/number per millisecond. Therefore you get jumps in the numbers with which you regulate your amplitude.And these become your clicks...
      The 'slick' version would be to to the whole calculation with a signal instead of floats by using the MSP equivalent objects like [line~] [*~] [/~] [cos~] etc.
      Unfortunately the [cos~] works slightly different from the [cos]: it takes only input values between 0. and 1.
      As i don't know about the math behind the ambisonic theory I just added the little 'hack' at the end of your algorythm to smoothen the values. If you plan to translate this into Java it would be worth to do realize it in signal format first.
    • Jul 11 2011 | 12:57 pm
      Yeah I was thinkin it had something to do with that. Your right it would be much neater doing all the processing with msp objects. The problem id have is that some calculations using if object would be needed to keep the values between 0 and 1. So it would probably require less efficient processing than your solution.
      Hack or no it works perfectly!