Jason Charney

My patch sends triggers bangs received from an iPhone compass (using C74 app as input). As the compass turns around and around, it sends out integers and resets to 0 after going around one revolution. I can't quite figure out how to have the direction reverse as it completes a full revolution, so that way instead of jumping to the first bang it simply changes direction as the iPhone continues spinning in the same direction (and also change direction if the spin changes direction).

My patch sends triggers bangs received from an iPhone compass (using C74 app as input). As the compass turns around and around, it sends out integers and resets to 0 after going around one revolution. I can't quite figure out how to have the direction reverse as it completes a full revolution, so that way instead of jumping to the first bang it simply changes direction as the iPhone continues spinning in the same direction (and also change direction if the spin changes direction).
Any ideas? Thanks!

reversing-direction-of-modulo-input

Thanks for this excellent example - I like the [select] instead of split, much sleeker.

However, it doesn't wrap in the way I need - it still has a 1:1 relationship between degree input and note output (so when it goes back to zero, it hits the first bang on the left).

Basically, I'm trying to figure out how to get it to reverse direction and move down when it gets to the last bang (select 15). So I can keep turning the iPhone in the same direction but the bangs will go up, then down, then up, then down respectively. That way there's not a huge jump in register when the 0 -> 360 (or 360 -> 0) degree threshold is crossed (since they trigger notes laid out sequentially).

Terry,
Thanks for this excellent example - I like the [select] instead of split, much sleeker.
However, it doesn't wrap in the way I need - it still has a 1:1 relationship between degree input and note output (so when it goes back to zero, it hits the first bang on the left).
Basically, I'm trying to figure out how to get it to reverse direction and move down when it gets to the last bang (select 15). So I can keep turning the iPhone in the same direction but the bangs will go up, then down, then up, then down respectively. That way there's not a huge jump in register when the 0 -> 360 (or 360 -> 0) degree threshold is crossed (since they trigger notes laid out sequentially).


OK I misunderstood-- I didn't realise the data wraps between 0 and 360--

you'll need to use bucket to compare the previous value to the current value to establish direction (ie going toward zero or toward 360) AND whether it has 'jumped' and then either subtract the current value from 360 [!- 360] or simply pass the value according to the result of that logic.You may or may not need to do some data smoothing first as well.

OK I misunderstood-- I didn't realise the data wraps between 0 and 360--
you'll need to use bucket to compare the previous value to the current value to establish direction (ie going toward zero or toward 360) AND whether it has 'jumped' and then either subtract the current value from 360 [!- 360]  or simply pass the value according to the result of that logic.You may or may not need to do some data smoothing first as well.


Here's an attempt. I've been trying to wrap my brain around this and just can't figure it out. I just need the boundary values to trigger a state change so that I'm either adding or subtracting from the input. This attempt works with the counter moving up but not counting down because I'm testing the high value but not the low value, I assume. It still goes to the other boundary of the modulo before reversing direction. Can anyone help me perfect/streamline this?

here's an adaptation of your patch-- but surely there's a simpler way to do it .... I added a direction-sensitive switch which helps, as alluded to in my previous post

Reversing direction of modulo input