phiol

phasor~ doesn't really reach 1. or does??

In this patch I am demonstrating that
phasor~ doesn't really reach 1. or does??

does-phasor-really-reach-1

[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

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.

[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 

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.
Jean-François.


JFC is right: phasor~ never reaches 1. Try this if you want to detect the end of a cycle (beginning of a new cycle).

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). 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?

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). 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. 

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?
using [delta]??  

Just looked @ your patch, yes this is the routine I've using for over 1.5 year

But one last question would remain: Does it signal the end or the beginning of a cycle ?

Just looked @ your patch, yes this is the routine I've using for over 1.5 year
for tight triggering,great stuff! 

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.

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*.

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 .

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 .


If in practice [phasor~], [delta~], [<~ 0.], [edge~] does not trigger on the first cycle would changing the comparison operation to [>~ 0.] trigger the first cycle?

I think one problem with my post above is that the [>~0.] could cause a trigger on both the beginning and end of the cycle since delta would change at the beginning of the phasor cycle with its initial ascent and at the end of the cycle with its signal descent back to zero.

does phasor~ really reach 1.