phiol

Here is a little modified version of the (2-phasor-step-sequencer.maxpat)

My version is a little more direct I guess.

I Was wondering why [index~] creates an offsets.

The example patch demonstrates that this is correct with a [-~ 0.5] in the phasor~ output change.

I do understand that the indexes are written in integer form.

and that they are being fetched with phasor outputting floats.

But I was curious in knowing how [-~ 0.5] was correcting this?

Here is a little modified version of the (2-phasor-step-sequencer.maxpat)
My version is a little more direct I guess. 

I Was wondering why [index~] creates an offsets. 

The example patch demonstrates that this is correct with a [-~ 0.5] in the phasor~ output change. 

-----
I do understand that the indexes are written in integer form.
and that they are being fetched with phasor outputting floats. 

But I was curious in knowing how [-~ 0.5] was correcting this?
Why this value? 

Here is my patch:
Thanks a lot in advance. 

indexs-offset-corrected-with-0-5

I think it's just a variation of a programming trick to round up or down numbers greater than zero by adding or subtracting 0.5 and then truncating, which is what index~ is doing to its float input. The phasor outputs values from 0 to 1, which is remapped to the number of steps, say n, (0 to n), but you want it to go from 0 to n-1 to properly address index and have the right number of steps, so you need to subtract 0.5 before truncation.

{If you subtract 1 from the number of steps number box, before it goes into the *~, then you don't need to do the -0.5 round-down} 

I think it's just a variation of a programming trick to round up or down numbers greater than zero by adding or subtracting 0.5 and then truncating, which is what index~ is doing to its float input. The phasor outputs values from 0 to 1, which is remapped to the number of steps, say n, (0 to n), but you want it to go from 0 to n-1 to properly address index and have the right number of steps, so you need to subtract 0.5 before truncation. 

{If you subtract 1 from the number of steps number box, before it goes into the *~, then you don't need to do the -0.5 round-down} 


1st of all thanks for the response Terry.

Not sure if that makes it clearer for me though.

If I get what you said correctly, here is a patch demonstrating it.

And if so , you see why I am still confused

Is this what you meant?
And if so , you see why I am still confused

Now you've got me confused! but here's a patch to illustrate your previous patch in a graphical form... not that it really answers your question... maybe apply this graphical analysis to the original patch you posted to see what it looks like...

I might be way off here, but isn't the timing difference simply due to the integer truncation taking place at a different value, and therefore a slightly different time? It think it makes sense to me that there is a difference, but I'm not explaining it well.

The time difference should be directly related to the speed of the ramped signal right?

I might be way off here, but isn't the timing difference simply due to the integer truncation taking place at a different value, and therefore a slightly different time?  It think it makes sense to me that there is a difference, but I'm not explaining it well.

The time difference should be directly related to the speed of the ramped signal right?


>>I might be way off here, but isn't the timing difference simply due to the integer truncation

Yes I do clearly get that from the beginning,

The problem here is that truncation takes up the time of 1/2 and index value.

w.both values the -0.5 and the 0. get truncated value index 0 right?

so we can say that sorta conclude that (index 0) is 1.5 longer than all other indices.

NOW WHAT REALLY GETS ME is that with my ear the timing is correct only with the [-~ 0.5]. Without there is a unwanted new note.

But visually with [number] we clearly see than (index 0) is 1.5 longer.

Yes I could just use the [-~ 0.5] as a routine without questions and move on to other things, but this way I would loose the chance to learn something new to maybe apply and use in another situation.

Yes I do clearly get that from the beginning,
The problem here is that truncation takes up the time of 1/2 and index value. 

 -~ 0.5
w.both values the -0.5 and the 0. get truncated value index 0 right?

so we can say that sorta conclude that (index 0) is 1.5 longer than all other indices. 

But visually with [number] we clearly see than (index 0) is 1.5 longer.
------
Yes I could just use the [-~ 0.5] as a routine without questions and move on to other things, but this way I would loose the chance to learn something new to maybe apply and use in another situation. 

And plus we wouldn't have this forum ;-) 

Would you have a solution to avoid having [index 0 value] 1.5 longer than others and thus in return cause everything to have a phase offset of 0.5 in timing.

The last step/(index value)time, is 0.5 the time length of the others .

Would you have a solution to avoid having [index 0 value] 1.5 longer than others and thus in return cause everything to have a phase offset of 0.5 in timing. 

You have to add 5 rather than subtract 5, truncate and then modulo the ramped index signal by the number of index steps to produce a signal with all steps of exactly equal time.

The resulting signal will still have a phase offset of 0.5 relative to a simply truncated ramp though. I'm not sure how to get around the offset without using delays and making the concept messy and prone to malfunction in certain situations. 

The resulting signal will still have a phase offset of 0.5 relative to a simply truncated ramp though.  I'm not sure how to get around the offset without using delays and making the concept messy and prone to malfunction in certain situations.  


the problem already arises with the [phasor~], because it actually reaches 1. (when it already should be at 0. again).

here's one way to do it with the signal accumulator:

the problem already arises with the [phasor~], because it actually reaches 1. (when it already should be at 0. again).
So why not roll your own phasor ? ;)

here's one way to do it with the signal accumulator:


Ahh, but then you have to pay attention to how long the patch is running and all that rounding error bother unfortunately. You have to have a way of resetting the accumulator periodically without interrupting the index count.

An even better way, is to use Andrew Benson's [steps~] external :)

I think his stuff should be in the standard Max5 distribution - extremely useful!

Ahh, but then you have to pay attention to how long the patch is running and all that rounding error bother unfortunately.  You have to have a way of resetting the accumulator periodically without interrupting the index count.

and put a [trunc~] out of [*~ 16]steps to [snapshot 1] for visuals tracking alignment but now all this.

I had settled for ok [-~ 0.5] 
and put a [trunc~] out of [*~ 16]steps to [snapshot 1] for visuals tracking alignment but now all this. 

Maybe this is just to obvious and I,ve been up way to many hours,

But what is wrong with just replacing [-~ 0.5] with a simple [trunc~].

Maybe this is just to obvious and I,ve been up way to many hours, 

But what is wrong with just replacing [-~ 0.5] with a simple [trunc~]. 

index~'s offset corrected with [-~ 0.5]