a really weird problem with [overdrive~]

    Sep 09 2008 | 12:44 pm
    I just discovered a weird problem with overdrive~ in combination with a few things. The problem exists with the latest max 4 (mac and pc) and max 5 (I checked only pc) as well.
    -if and only if the incoming signal contains clicks (or abrupt changes)
    -if and only if the signal is routed through a [freqshift~ ] object (the shift itself is irrelevant, even shift 0 'works')
    -if and only if that signal is routed to an overdrive whose drive is controlled by a signal (not when it is controlled by a float)
    --> then the output becomes really dirty, even with drive = 1.
    i noticed the problem because this output can blowup biquads (resulting in a 'nan' output)
    you can check this situation for yourself with the patch belowing and trying out the various situations, you will find out that it will only result in a dirty output when you have clicked all three green message boxes
    placing a [bitsafe~] or [el.killdc~] object before or after the [freqshift~] doesn't help
    can somebody explain this to me? what is [freqshift~] doing to the signal (inaudibly) that causes an [overdrive~] to behave like this? does it mess up the phase for wideband (click) signals? And why is this only a problem when the [overdrive~ ] is controlled with a signal object?
    max v2;

    • Sep 09 2008 | 3:06 pm
      I can confirm with Max 4.6.3 on Mac OS X Intel, the output sound goes wild. Seems quite buggy to me.
      Did you check in the latest version of Max 5 (currently 5.0.4)? Some msp stuff has changed there, recently.
    • Sep 09 2008 | 4:14 pm
      thanks for confirming
      good point about the latest version, I still had to update to 5.0.4
      I just did and... the problem remains (at least on a pc running xp)
    • Sep 09 2008 | 9:31 pm
      This should be fixed for the next incremental update.
    • Sep 09 2008 | 9:51 pm