Roman Thilenius

many people probably never became close friends with [edge] and [sah~], and whenever i have to use sah~ i have to run the helpfile to remember how it works.

here is one of the reasons, it is an old problem of mine, which never got solved.

grafik.png

phasor_issue_16.zip


many people probably never became close friends with [edge] and [sah~], and whenever i have to use sah~ i have to run the helpfile to remember how it works.

here is one of the reasons, it is an old problem of mine, which never got solved.

any ideas?



many people probably never became close friends with [edge] and [sah~], and whenever i have to use sah~ i have to run the helpfile to remem

resettable-phasor

I'm not sure what the problem is here? When I run the patch, the scopes all seem to do what I'd expect them to do.

ah yeah, maybe the spike doesnt occur in later versions of the scope object with these settings, i should have tried that myself.

but you can hear the clicks, too; or record a bit of it in a buffer.

or can you tell offhand that my method (which i once copied from someone) is correct?

thats what it produces (and it is not a graphics glitch)


ah yeah, maybe the spike doesnt occur in later versions of the scope object with these settings, i should have tried that myself.

but you can hear the clicks, too; or record a bit of it in a buffer.

or can you tell offhand that my method (which i once copied from someone) is correct?

thats what it produces (and it is not a graphics glitch)



Ah! Didn't know I was looking for a spike. But, I still can't reproduce it here (Max 8.1.5). Which output is producing the spike in the graph above? Tried both the raw phasor outputs and the right-most rescaled phasor outputs, it seems OK as far as I can see.

I'm debugging by writing into a buffer~ and looking at that. I also wrote a gen~ equivalent of it. Both are in the patcher below. 

Ah! Didn't know I was looking for a spike. But, I still can't reproduce it here (Max 8.1.5).  Which output is producing the spike in the graph above? Tried both the raw phasor outputs and the right-most rescaled phasor outputs, it seems OK as far as I can see. 

I'm debugging by writing into a buffer~ and looking at that. I also wrote a gen~ equivalent of it. Both are in the patcher below. 


somehow i am afraid that it is yet another bug in a max 4 object.

or i made a fundamental error with the method i use. but then why it only happens sometimes? i see no pattern.


the spike appears on reset.

somehow i am afraid that it is yet another bug in a max 4 object.

or i made a fundamental error with the method i use. but then why it only happens sometimes? i see no pattern.



it is a bit like click~ would be a blit or something else which could have inter-sample time positions (well actually you wouldnt even do that with a blit)

it just doenst make sense. clicks sends "1" - in this case at sample 1 of the next vector after you pressed the button - and that should reset the phase to 0 within the same sample. but sometimes it seems to be reset to a bit less than 0. , then resulting in a spike to 1. because of the !-~ 1.


it is a bit like click~ would be a blit or something else which could have inter-sample time positions (well actually you wouldnt even do that with a blit)

it just doenst make sense. clicks sends "1" - in this case at sample 1 of the next vector after you pressed the button - and that should reset the phase to 0 within the same sample. but sometimes it seems to be reset to a bit less than 0. , then resulting in a spike to 1. because of the !-~ 1.


Okay, if it is Max 4... Do you have to use Max 4 for this project? Because in Max 8 I'm not seeing any spikes at all. In Max 4 I can't really help, as I don't have a copy here. So the rest of this is just guesswork. It could be something of a floating point error somewhere in the sah~ part of the patch whereby some subtraction is getting a number very slightly below zero and this is getting wrapped. It could be strange behaviour of [%~]. Who knows.

- Remove the [!-~ 1.] and replace the [+~ 0.] it goes into with a [-~ ]. 

(BTW click~ is really not doing any kind of blit here, it's literally 1 sample of value 1 in a sea of samples of value 0.)

Okay, if it is Max 4... Do you have to use Max 4 for this project? Because in Max 8 I'm not seeing any spikes at all. In Max 4 I can't really help, as I don't have a copy here. So the rest of this is just guesswork. It could be something of a floating point error somewhere in the sah~ part of the patch whereby some subtraction is getting a number very slightly below zero and this is getting wrapped. It could be strange behaviour of [%~]. Who knows.  

Some random ideas that might help:

- Remove the [!-~ 1.] and replace the [+~ 0.] it goes into with a [-~ ]. 
- Add a [+~ 1] before the [%~ 1] 
- Replace [%~ 1.] with [pong~ 1 0. 1.] 

(BTW click~ is really not doing any kind of blit here, it's literally 1 sample of value 1 in a sea of samples of value 0.) 

you´re right, it works as intended in max 7 / 32

i suspect there is something wrong with the modulo object in max 4.x

until now it was one the few objects without issues.

sometimes i wish they all would be open source so that i could correct them.


you´re right, it works as intended in max 7 / 32

i suspect there is something wrong with the modulo object in max 4.x

until now it was one the few objects without issues.

sometimes i wish they all would be open source so that i could correct them.


you´re my hero, that one actually works:

Remove the [!-~ 1.] and replace the [+~ 0.] it goes into with a [-~ ]. 

i always thought that it cant work to reverse the direction because it would remove the true 0.0 - which will of course be required for catching yet another nonzero to zero transition somewhere later (it´s a phase signal!) - but it seems it doesnt?

the modulo seems to be okay, replacing it makes no difference; so i think it is 

doing some tests later in a real life context. it will especially be interesting to see if it still works within the last octave to nyquist.


you´re my hero, that one actually works:

Remove the [!-~ 1.] and replace the [+~ 0.] it goes into with a [-~ ].  
Add a [+~ 1] before the [%~ 1]

i always thought that it cant work to reverse the direction because it would remove the true 0.0 - which will of course be required for catching yet another nonzero to zero transition somewhere later (it´s a phase signal!) - but it seems it doesnt?

the modulo seems to be okay, replacing it makes no difference; so i think it is sah~ what causes those random spikes.

doing some tests later in a real life context. it will especially be interesting to see if it still works within the last octave to nyquist.


resettable phasor