Hi. I am using an encoder and it’s working fine. I would like to have speed dependent behavior. In the sense, that if I move the encoder fast in a + direction, the value should jump up faster than the actual rotations registered from the encoder. Hope you know what I mean.
Basically, when moving the encoder slowly, I want to get a fine resolution. When I move it fast, more coarse resolution and add to the actual rotations that I have made.
Is there a node for that? If not, how would I go about making that functionality?
Another thing:
When using my encoder, I am using it along with a counter. And from there on, I want to limit the range of the output. Say -10 to +10. I have a map clip in between and set the Smin to 0 and the Smax to 10. I then set the Tmin to -10 and the Tmax to +10.
If I go above 10, the number don’t increase, but if I go for instance 5 “clicks” above 10, I still have to dial back 5 clicks until it the value starts decreasing.
There are basically 2 options for changing input rate based on speed of pulses:
time gap between each pulse
count pulses over a period of time
I could be wrong, but it seems like 2nd option would be a little easier & less likely to run into process/timing issues. Also, rather than calculate what to add based on time elapsed, you can multiply count by a speed factor & add to your stored number.
I’m guessing you are using a ‘count’ node to store value. You have a lot more control if you use a ‘buffer’ to store the “current” value. This allows you to clip the value before storing it, so there are never “5 clicks back” before updating current value as well as change how fast you change the value.
Every time the clock ticks, the stored value is updated based on how many INC/DEC pulses we have counted.
The defer node between clock and count nodes is to make sure we are done with current count values before clearing. There is some chance we will miss encoder updates between calculating new value & clearing counts. This defer may not be needed since new value should be stored before calculations cascade down from clearing counts. If you remove it & value quits updating, then add it back in.
You can change the clock-IVAL to increase/decrease how often value is updated. This will have an impact on your scaling factor (you probably want higher pow-EXP for smaller clock-IVAL times). For scaling factor, I used exponents; if there is only zero/one INC/DEC counted, the result will be zero/one, but value rises exponentially based on count. You can change the pow-EXP to change the scaling factor. Subtract DEC from INC, then add to current value to generate a new value. The new value is then clipped before storing.
The ‘defer’ node is needed between buffer & add because we are looping back up the code flow…this is a XOD requirement.
Hey there,
For speed-dependent behavior with your encoder, you can adjust the value increments based on how fast you turn it. Measure the time between pulses and increase the value more for faster turns and less for slower ones.To limit the output range and avoid extra clicks, ensure the value wraps around within your set range. If the value goes beyond +10, subtract the range to bring it back within limits, and if it goes below -10, add the range.
It seems this solution is very prone to crashing for some reason.
If I change the Pow exp value to anything other than 2, my arduino freezes up when moving the encoder back and forth.
My logic tells me that this is where I can change the speed of the speed dependent component. Correct?
That is the correct place to change the speed-dependent component. It work for me for 1.5, 2, & 3 (but I’m am using tweak to send pulses, not an encoder).
I added speed-counter to gweimer/utils — XOD as well as utils-example-speed-count to demonstrate its usage. It defaults to no clipping with MIN & MAX =0. It also only runs clock to time pulses after there has been a pulse, so updates don’t happen if there are no pulses for INC/DEC (well…I sort of cheated…updates don’t happen If INC & DEC pulse counts are equal, which uses several less nodes than checking if each is equal to 0. I guess it could be considered a bug since the next pulse will get speed-factor applied since count didn’t start at 0…).
I also added busses. If you’ve not seen them before, the triangles with labels on them are a bus. Busses with same name are basically linked together by invisible wires. This cuts down on wires that cut across multiple nodes so things are not so messy. Each bus can have multiple outputs, but only one input.
