play~ change speed


    Feb 24 2016 | 12:00 pm
    Can please somebody explain me the red parts in the following patcher. I asked my teacher already 10 times and I know what delta~ and +=~ do in theory, but I don't understand why he is using the objects to change the speed in realtime. why do I first need the difference between the actual and previous sample to change the speed with play~?
    Max Patcher
    In Max, select New From Clipboard.
    Please help Thanx P

    • Feb 24 2016 | 12:20 pm
      I think I understand now....but if anyone wants to add comments, you are welcome :-)
    • Feb 24 2016 | 12:25 pm
      Hi there are numerous ways to get play~ to vary playback speed. This method is unusual (and a little heavy-handed), but I'm guessing your tutor is planning to extend the method later, in ways that I obviously can't predict (perhaps to make pitch/speed either independent or correlated?). BUT, she/he is using the delta/difference signal as a trigger source, so that pitch/speed changes don't interrupt the phasor and cause glitches; +=~ and %1~ bring that value back into the 0. - 1. range (?). Which is then re-scaled by the total ms value from info~.
      But you already knew this anyway? Attach a couple of scope~ and number~ objects to clarify things; and when you get a definitive answer, I'd be interested to see it!
      Brendan
    • Feb 24 2016 | 12:36 pm
      It's like you say: phasor~ reads thru the buffer. delta~ gives the difference between the current value and the previous value and because it's a phasor, we get steady delta~ values of e.x. 0.1 except when the phasor goes from 1 to 0, we get a -1. Now we choose the playback speed (with the *~ and line~ object). If we choose '1.' there, the +=~ object will rebuild axactly the same phasor~ ramp, e.x. 0.1 + 0.1 = 0.2 0.2 + 0.1 = 0.3 etc. 1.0 - 1.0 = 0. and it starts again.
      If we would choose for the multiplication a factor 0.5, the delta~ values are devided in 2, so we get 0.05 instead of 0.1 and the +=~ object needs twice as much time, to reach the value '1.' again, so the 'buffer has to be stretched' with a factor twice hence the playback speed is half as fast as the original speed. That's how I see it, no? The more I think about it, the more I think it's a very cool solution :-)
      Peer
    • Feb 24 2016 | 1:34 pm
      Hi Peer I really love these open internal dialogues. Many times I have solved a problem just by stating it on the forum! And you've explained it waaaay better than I did
      Brendan
    • Feb 24 2016 | 1:54 pm
      Thanx for this comment Brendan. That gives me hope that I understood it ;-) And yes, I have the same experience with the forum. And what also happens often: I think about sth for hours and don't find the solution, then I post it on the forum and 5 minutes after the post I find the solution myself...strange, isn't it?