posted 26 May 2013 15:57            

Can't think of a way off the top of my head.

posted 26 May 2013 18:21            

Direction is the change in values current and previous state i.e. If it's greater than the last reading, it's up, and if it's less than the last, it's down. There may be other ways of getting a one tick delay in capytalk, but one I know works is pasting a constant module into the hot param field of another module. So if you use a Constant with !RotVal in its value field, and paste that modules into another field with !RotVal - [Constant] L, then if the result is positive then !RotVal is increasing, negative the value of !RotVal is decreasing and zero means the !RotVal is not moving. Putting it in brackets and adding the "sign" key work will give you the three states (-1,0,+1) if you only want the direction and not the amount the rotary has turned.

If you need the rotory to remain true, even when it move past 1 and raps round to 0, then that a bit harder. You need to detect big jumps and assume it has then crossed the line and then compensate. It could be done like this.

| IncDec |

IncDec := !RotVal - [Constant] L.
IncDec := IncDec - (IncDec gt: 0.5).
IncDec := IncDec + (IncDec lt: -0.5).

"Only add the following line if you are only interested in direction not speed"

IncDec := IncDec sign.

That's the first problem. The second problem is the running count that accumulates. This requires feedback (at tick rate) to keep the value that was there at the last tick. The way to do this in kyma control rate is sound to global controller as the transmitted value can be picked up in another constant pasted into the S to GC, so that one tick later it can be used in the equation that makes the next transmitted value.

So we can put !Value as the GeneratedEvent in the sound to global controller. We can then put the code above into the value field followed by

( [Constant2] L*100) + IncDec

and put !Value*0.01 in the Constant2s value field.

The *100 and the *0.01 increases the range of the value else the constant2 would clip it to -1 +1.

You may want to scale IncDec before the last line if you want to vary the sensitivity of the rotory.

I hope I've got this right and I hope it makes sense and I hope it works.

posted 26 May 2013 20:25            

RotaryToCount.kym

I think I followed about half of what you said, but I've taken the bit about the constant and rigged up something that almost works - see the attached file.

You are right: if I move the rotary too fast it doesn't track the changeover as the 0 to 1 (or vice versa) threshold is crossed. I'm not sure I follow the bit about how to adjust that.

Also, I'm using the rotaries on a Behringer BCF2000, and when I'm decreasing the value, sometimes the controller I'm calling !Increasing triggers momentarily. I'm not sure if the Behringer has a little jitter and temporarily sends a value higher than the previous even though I'm going in the decreasing direction. That's not as big a deal as the 0/1 changeover not being detected, though.

If you have a chance to look, let me know if you see any improvements that could be made.

posted 27 May 2013 05:37            

EternalRotory.kym

I've attached a copy of what I was trying to explain.

The first example doesn't seem to work as it looks like multiplying a number by 100 followed by multiplying it by 0.001 doesn't give you exactly the first number you thought of. Hence the value very slowly starts to drift down. May be SSC has a method of compensating for the tiny difference? BTW the Cappy has problems with the scale of StoGC feedback even when you are not multiplying up and down.

The second example does seem to work but is limited to +/-1 value range, so I've added a scale to the rotary so that you can multiply the value up when you need to use it.

I'll try to explain how the jump compensation works. First we are sending out the step differences from tick to tick. If we add all these differences together (accumulate them) we know the position of the position of the rotary. Imagine we were going up in steps of 0.1 each tick then the second tick is 0.1 - 0 which gives 0.1. The third tick is 0.2 - 0.1 giving 0.1. The fourth tick 0.3 - 0.2 gives 0.1.

The tenth tick is 0.9 - 0.8 giving 0.1 but the eleventh tick is 0 - 0.9 giving -0.9. In this case we still want 0.1, so by adding 1 to -0.9 we get the 0.1 we want. We know that it is very unlikely that someone will turn the rotary down by more than half a rotation within one tick (1ms), we can therefore say that, if the output is lower than -0.5, we need to add 1 to the output to get the more likely value that the rotary has changed by.

The reverse happens in the downward direction so if the value is greater than 0.5 we need to subtract 1 to make it right. It doesn't matter what size the step is adding 1 or subtracting 1 can put it right.

I hope this makes sense

Pete

BTW I too have the Behringer and it is giving out noisy step info. You can smooth this, but only after the final output where you use the result. Smoothing anywhere else will stop it from working. This is because, if the jump from one to zero gets smoothed, it is the same as someone slowly turning the rotary all the way back down again to the other side.

posted 27 May 2013 13:23            

I understand much better now - I had misinterpreted a couple of things in my attempt to patch together what you described in the first post.

Now I have something that's workable for my project, although still a bit fiddly and jittery (even with smoothing the result) with the Behringer. And I've picked up several Capytalk things that I hadn't realized and/or considered before. So success!

The one thing that bothers me with this solution, and I think it would take a completely different approach, is that there isn't a 1:1 correspondence with how much you turn the rotary knob and what that translate to in the result. I realize that that is because it depends on what messages are received by the Pacarana - obviously the Behringer, or any controller operating at control rate, isn't going to send every value, but will do a lot of skipping.

What I had initially envisioned was that, as I turned the rotary from 0 to 1, that the resulting count would go from 0 to 1, and as I continued from 0 to 1 again, that the resulting count would to from 1 to 2, etc... Again, I think that will have to take another approach.

posted 28 May 2013 17:22            

In theory it should have a 1 to 1 relationship. If you use just the on screen rotary in example 2 you see that it starts out that way. There is an oddity thats stopping it from being 1 to 1 and we are looking into that.