degrade~ problem in 6.0.7

    Oct 25 2012 | 11:21 am
    i encountered a problem with degrade~ when changing from max 6.05 to 6.07 - it seems to behave differently, in fact i think it behaves not as it should: there's a dc offset in 6.07 where there wasn't any in 6.07, and i get completely different sonic results from the same patches. this is quite hard to describe, so i've prepared a small test patch making the problem more obvious.
    (btw this is NOT the known degrade~ bug discussed here:
    i realize not many people will have both 6.05 and 6.07 running simultaneously, but if anyone does, please take a look/listen!!! the whole thing drives me crazy, & i can't figure out what's going on here...
    btw both 6.05 and 6.07 running on WIN XP/SP 3.
    thanks everybody! rstaudi

    • Oct 26 2012 | 1:19 pm
      hello again!
      alright, i should probably clear something up here. although the change in degrade~'s behaviour seems to have happened between max 6.0.5 and 6.0.7, it didn't change from max 5 up to 6.0.5, which means you can also reproduce the change by running the appended patch first in max 5, then in max 6.0.7 (or vice versa)!
      also, i know about the argument bug, this is about something completely different - the problem i'm talking about is kind of hard to explain: it seems to me degrade~'s bit reduction function doesn't work properly when handling low amplitude signals! where its output is silence, i.e. constant zero in max 5 up to 6.0.5, it's NOT in 6.0.7 when processing the exact same signal stream, using the exact same arguments! the patch i've made is kind of self-explanatory, you simply have to turn on audio, click a message box, and voilà! you can both see AND hear the difference degrade~ shows in handling signals with very low amplitude!
      i have reproduced this difference on two computers, both running WIN XP/SP 3, using both internal sound and ASIO via my MOTU 828mkII usb. please give it a try! this change in degrade's functionality is very dramatic for me as it concerns a lot of my patches that do not work properly anymore, and i'd hate to have to downgrade to 6.0.5!
      thanks a lot, everybody! rstaudi
      here's the new and improved degrade~ test patch: just compare the results you get with values >= 113 and wonder!
    • Oct 28 2012 | 6:37 pm
      and it's me again!
      sorry. i don't wanna be obnoxious about this, but as i explained above, the topic is dear to me!
      however, as a last attempt, two pictures to show you what's going on here with degrade~: - the first one shows the above posted patch (or a part of it, actually) in max 6.0.5: you can see that the input signal (the upper scope~), in this case a cycle~, is multiplied by a very small number and fed into a degrade~ which outputs silence (viz the lower scope~)! - the second shows the same patch and signal path in max 6.0.7: here there is an output, & clearly it's NOT silence! => so what has changed here? any ideas?
      come to think of it, i do actually think that only now (max 6.0.7) does degrade~ behave as expected, truncating everything to 2^3 steps in the example patch - however, it couldn't have been buggy before, it's behaved like in the first picture since max 5.0!! was there simply some kind of limitation to the range it could handle? something to do with the transition to 64bit audio maybe?
      thanks again! rstaudi
    • Oct 29 2012 | 3:34 pm
      Found a solution as it was happening to me. Plugin a new float number box into the sampling rate input and an integer box into the bit depth input and when you make a change to both it will start working again. I have reported it as a bug. best P
    • Oct 29 2012 | 5:03 pm
      hey guys we're aware of this and our engineers are currently looking into it
    • Oct 29 2012 | 6:10 pm
      thanks, guys, but i think there's been a misunderstanding. this is NOT about the argument bug already discussed here:
      in fact i think i know what the "problem" here really is:
      i guess degrade~ was simply still working with 32bit single precision up until max 6.0.5 and is only now working in 64bit?! this would explain everything since in 6.0.5 it would simply ignore anything below 1.19209289551e−7, i.e. the lower limit of a single precision (23bit) mantissa (if i understand wikipedia correctly...), whereas now it accepts anything down to, well, a very very small number!
      can anybody confirm this?! please!
      best, rstaudi
    • Oct 29 2012 | 8:32 pm
      What Tom said