does phasor~ really reach 1.
Hi all I was wondering about this.
In this patch I am demonstrating that
phasor~ doesn’t really reach 1. or does??
Thanks in advance
----------begin_max5_patcher---------- 781.3ocyXEsaaBCE8YxWgadNKBaBfYRUQ66XZZh.NAOQri.yZZqZ91GXCMoM gLafPyKf3hwbtGet2igWmXMcEeOIeJ36feBrrdchkkLTU.q5qsltMbeTZXtb XSi3a2RXhoyT2SP1KjwWUH.hDBCHxJXQG.4I7hzX.iK.j0qIQB.UMfGdX4xl mNkxHQ7BlbJP0AWyYBV3VhbZ+QFMLsY3zXYL9p+7MHpIHqXKkkRDR3AOFjWH ZhZWGcWFIuD6gBJm86rRLoRbGam41y.NHX0I65CfecBdxouHwCDM+8IKTDkP YaZchftKjWsnZtpdl2lLo5vrdxzwbRNXWRXNO6.HiDll9b0onDveCSKJuGbN .r7HIqGeB6.e9AlAOOXgO1C2N8.ckbqKVRKdRtBg6H6vHOUh6yHGk5ynTOvf LGdcMgZjhm2QTY7zb5FV4K8cszkDMPeoZAKOsPpYP1CrlQjPyqJIeJurFLTV KJkQFQT39JQtZwCD4qJdPphG6dQDjWhCOpCNII7uXRftdeiyQKBqJ08CjqZt MG6DXK6cJ3rKUU1AoYKM4PJLBCruXStyTtqBYazQ2hBPMKT8X4pkpYR7FhYE ylXKfziwTMptts.btafaYI7UYyYFvpdJEkysfUe7wCkdDFQqNFT0noPzwq+z p9sWQN3An8ZKDZTR4xpgB0ECeoscvnxnP4tbbcuELZy1aLTl51AY5MvJWwId 3dwLqS4k.1nz2ava9oxDc2R7YbVYNDJLouGDIIMrWuntV8Sc76PUm4ViPeE9 Cv2SViN3NHOtMtbMDjO79xkKnu8OFf1qMbixp5Nxvxtuemz.RNptE2UdONK9 ZMepoFnq+Wi4CztusWFDiDnuZyPpulrEiD4DH+6Se5eeImvp3ejax4EYQMXo 1oEbzNLljKnLoE5Iiw8CiIgFGSXm9Ukaow63TlnFBsrNoKhb0.QAiJhpJH9u PppqxHhInsFX5S.+Vio.cnoQEQHMPDbb0RZfHznhHcD2NiKhzRaOx8.zQbWs wzwDSXcvjeOvT4EuM4e.r7L4d. -----------end_max5_patcher-----------
[change~] reports direction change, so the left part of the patch is OK, and doesn’t show is [phasor~] reaches 1 or not.
Truth is [phasor~] doesn’t reach 1. But it’s tricky to see. Indeed, when I use [capture~] on the phasor~ on the right of your patch, I get the following values output by phasor~: 0.9997 0.9998 0.9998 0.9998 0.9998 0.9998 0.9999 0.9999 0.9999 0.9999 1.0000 1.0000 0.0000 0.0000
So, it seems that phasor~ does reach 1.
But with full 32 bit precision (for instance capturing with [capture~ f 44100 6], you get:
0.999751 0.999773 0.999796 0.999819 0.999841 0.999864 0.999887 0.999909
0.999932 0.999955 0.999977 0.000000 0.000023 0.000045
It actually makes sense that [phasor~] does not reach 1 if it starts at 0.
JFC is right: phasor~ never reaches 1. Try this if you want to detect the end of a cycle (beginning of a new cycle).
----------begin_max5_patcher---------- 387.3ocyU98SCBCDG+4xeEM8Yz.keHw3K92gYwTfNVMPKgVhSW19a2RAbtkI 1EQhuzld2UtO2WtbcmC.kJ1RkH38vmf.vNG.vXpy.X3L.UQ1lURjlvPosJkf ib6cwaqX7Rpx3y+nQQq5bq8lTuUS6SGJkvKPvUCtqIprMLdwyMzLUeDXuja8 b0ad8aiqedGVtAIQ5K2jf5Ls2woaw0xZgSeUe2wZQQ2ZRLhlWPOLYEtVvUR1 6lJwGq45RENdxB20dAv+t3tsvvoDfXzWXiSpLIC8XCiTNiRyCGfd2dQoAeMR y21SHYEbMv1HJQcebXPxThRzhHJ4zREYFZXlCUAm7ysJgKhpTugHEMGf9+S5 W7LZR7j8KAyqxrtTnqi+vII5DPTWynjDyPznIGkhsSDLWEUx3m+9gI6c1OUY jh1lrQvGlXAOBPNUpXbhhoeb4XLImDyFVdN03dTmpX40BFWMf.b0E+KYKQQV PT7hRTnEDEsnDEXAQgKJQXKHJ3WPj9vdmO.zw0AT -----------end_max5_patcher-----------
THANK YOU SO MUCH FOR THIS GUYS!
These little things will drive someone mad! MOSTLY due to MISINFO or lack of info, you sometimes get in the helpfiles (phase output (between 0 and 1).< -maybe it should have been written as [> 0.] and [< 1.] I guess.
These little things, will change the way one patches or more precisely in the way one sees the logic of things , so yes the way I will patch in the end.
This has everything to do with peek~/index~/multislider or Blackman & all flavor windows… and using this combo for amplitude env. and granular synthesis.
The reason is that I was wondering if I should use [line~ 0.] or [phasor~ ] to read the values inside [index~].
If I use [phasor~ ] I need it to behave like [line~ 0.] and STOP when it reaches the end of it’s cycle. That’s why I need to know WHAT THE VALUE IS to send a 0. to [phasor~ ]. THat’s why this topic ;-)
What would be the best way to accomplish this?
Endless thanks guys
Theoretically the end and the beginning of the cycle are at the same instant – so it is the same. In practice two things happen:
1 – the value has to get smaller from one sample to the next so it will not trigger until the *end* of one full cycle (it won’t trigger on the first cycle) – so you may prefer to think of it as the *end*.
2 – Most likely the zero or one value (beginning / end of the cycle) occurs in between samples – so you will almost always be a sub-sample late in triggering compared to the true point in time (unless it occurs exactly on a sample. Because it is always later you can be sure that the previous cycle has finished, so that might make you think of it as the beginning.
The second of these things is fairly irrelevant most of the time, and especially when you are triggering in the max domain (not in a sample accurate way) – as the timing will be comparatively way off anyway. The first of these might be relevant sometimes when you really care about whether you catch the first cycle.
What Alex wrote is true, but there’s one more (often crucial issue). The edge~ object is the object that translates from the MSP signal domain to the world of Max messages; it looks for change from 0 to non-zero (or vice versa) in the MSP signal and sends out a bang. But it can only do that check once per signal vector, so it’s really reporting the end of the vector in which the change(s) occurred. Thus it’s almost always not sample-accurate; it can be late by as much as one signal vector. That’s often accurate enough, depending on what you’re trying to do. If you need sample-accurate timing (as for moving through a window function) you’ll want to stay in the signal domain. The phasor~ is useful for cyclical (i.e. repeating) ramps, not one-shot ramps. For the latter (such as indexing a buffer with index~), see line~ or count~. See also the ab objects by Andrew Benson < http://www.cycling74.com/share.html>.