Hi,

I hope I'm putting this question into the right section.

I'm attempting to compare a number over time. (The number is coming from a rotary encoder on an Arduino, which is being sent to pd through oscP5 Processing library.)

Basically, I want to use the rotary encoder to control the speed of an audio track. However, the rotary encoder sends values between 0-15.
I want to check the speed of the rotary encoder by seeing how much the numbers change in any direction.

So my thinking is that if I take the number of the rotary encoder (say its 4) and store it, and then a second later check the current number of the encoder it (say its moved to I will then know that its turning at a rate of 4. I can then get the track to play at a rate of 1 (normal speed). If its only turning at a rate of 2, I can play the track at 0.5.

I've attached a patch where I'm trying to compare a number over time, but I don't know if it will be any use.

http://www.pdpatchrepo.info/hurleur/timerNumberTesting.pd

something like so? I assumed it's only going forward and an integer, if it's floating point you could probably figure something out with fmod, if it's going backwards you might not being able to tell if they're going backwards or forwards

http://www.pdpatchrepo.info/hurleur/timerNumberTesting.pd

If I understand correctly, the actual numbers from the encoder/Arduino are not relevant, it is just the rate at which they change.

So just counting the number of bangs that arrived in the last second is what you want?

http://www.pdpatchrepo.info/hurleur/timerNumberTesting2.pd

You might also want to look into [delta].

Hi All,

sebfumaster, your patch is excellent, just what the doctor ordered. Unfortunately the numbers go backwards (ie decrease) as well so it only works if the rotary encoder is going clockwise, but I can try and figure something on Arduino, unless you have a better idea?

electrickery, I've tried making sense of your patch but can't seem to.
You're right to say that the rate of change is all that matters, but I don't see this effecting the bangs per second?

are the numbers coming in at a certain constant rate? basically the problem is a form of aliasing. consider the problem like this: lets say you have the value 1. the next time a number comes in it's a 2. there's no way for the computer to tell if you went backwards or forward to get to that 2, or twice forward around the circle for that matter. The solution may be to treat the numbers of the rate of change in the range from 8 - 15 as instead -8 - -1.

if the numbers aren't coming in at a certain constant rate, I would go with electrickery or llorona's suggestions: measure the amount of time it takes to get from one number to the next, and use a negative value if that number is less (wrapped) than the previous number

I've attached another version, though I'm sure there's a more efficient way to do the mod-ing and wrapping and such

http://www.pdpatchrepo.info/hurleur/timerNumberTesting.pd

Ah ok, how electrickery's patch make a bit more sense. I'll look into it some more.

Your explanation of the aliasing problem was also enlightening.

Your latest version is great, much appreciated.

What I'm thinking of doing from here is to have a load of [sel] objects that then set the speed for the audio track. Its a bit messy looking, but it did the trick on the last patch you sent on to me.

I'm not sure if its kosher to link to external sites here, but this is a video has some footage that shows how I'm using the [sel] objects http://museumexp.wordpress.com/2014/01/12/rotary-encoder-controlling-audio-speed-in-pd/
If you dont like external linking, let me know and I'll take it out!