This forum is read-only. Please post new topics in our Q&A forum.
Strange rule behavior
Moderators: florian, DvlsAdvct
Strange rule behavior
I've come up with a set of rules that elegantly solves a multi-range challenge for a single knob (incoming/outgoing: B7 66 pp), but it shouldn't work:
uu=pp-64
if pp>63 then pp=uu
if pp<=63 then pp=pp*2
This outputs values from 0-127 for the incoming range of 0-63, and then again for 64-127. (I can explain later why I need this).
I had originally included the doubling of "uu" for values over 64 (uu=uu*2), because, mathematically, it should be required. See below:
uu=pp-64
uu=uu*2
if pp>63 then pp=uu
if pp<=63 then pp=pp*2
HOWEVER, if included, the translator will not work correctly. This suggests to me that the doubling of pp (as in "if pp<=63 then pp=pp*2") occurs even if the incoming value is >63, which according to the rules should not happen.
I have made sure no other translators are interfering, so I cannot not explain this.
Any of you hardcore coders can explain to me why this is? Or is it a bug??
uu=pp-64
if pp>63 then pp=uu
if pp<=63 then pp=pp*2
This outputs values from 0-127 for the incoming range of 0-63, and then again for 64-127. (I can explain later why I need this).
I had originally included the doubling of "uu" for values over 64 (uu=uu*2), because, mathematically, it should be required. See below:
uu=pp-64
uu=uu*2
if pp>63 then pp=uu
if pp<=63 then pp=pp*2
HOWEVER, if included, the translator will not work correctly. This suggests to me that the doubling of pp (as in "if pp<=63 then pp=pp*2") occurs even if the incoming value is >63, which according to the rules should not happen.
I have made sure no other translators are interfering, so I cannot not explain this.
Any of you hardcore coders can explain to me why this is? Or is it a bug??
facebook.com/spacebar.max
- sjcaldwell
- Power User
- Posts: 175
- Joined: Tue Sep 20, 2016 11:05 pm
Re: Strange rule behavior
Not a good practice to make multiple mods to the same variable when doing comparisons. I easily get tripped up on this. I suspect that is what is happening.
However, you could probably solve this much simpler
pp=pp%64
pp=pp*2
Note that you will never get a value of 127 since when you multiply by 2 it is always an even number. If you want that you could add the following rule:
if pp==126 then pp=127
Of course with that you will never get a value of 126.
Going back to your original case, I think this would work but I haven't tested it.
uu=pp-64
uu=uu*2
if pp>63 then qq=uu
if pp<=63 then qq=pp*2
pp=qq
However, you could probably solve this much simpler
pp=pp%64
pp=pp*2
Note that you will never get a value of 127 since when you multiply by 2 it is always an even number. If you want that you could add the following rule:
if pp==126 then pp=127
Of course with that you will never get a value of 126.
Going back to your original case, I think this would work but I haven't tested it.
uu=pp-64
uu=uu*2
if pp>63 then qq=uu
if pp<=63 then qq=pp*2
pp=qq
Re: Strange rule behavior
Thanks for the quick reply!

Thanks!
The 3 rules I have work perfectly. I don't believe you could simplify further.However, you could probably solve this much simpler
It moves in increments of 2, yes. I could add a "pp=pp+1" or some such variant to shift it to odd numbers I guess. Does work fine as is, though.Note that you will never get a value of 127

Thanks. The use of qq seems to be unnecessary, thus redundant. Similarly, I'm not sure why it's..uu=pp-64
uu=uu*2
if pp>63 then qq=uu
if pp<=63 then qq=pp*2
pp=qq
Should be perfectly ok to do that, no?Not a good practice to make multiple mods to the same variable
Thanks!
facebook.com/spacebar.max
Re: Strange rule behavior
My curiosity is focused on why this works (in the way I described):
uu=pp-64
if pp>63 then pp=uu
if pp<=63 then pp=pp*2
It shouldn't!
uu=pp-64
if pp>63 then pp=uu
if pp<=63 then pp=pp*2
It shouldn't!
facebook.com/spacebar.max
Re: Strange rule behavior
This little video gives a visual illustration to help understand:

https://youtu.be/0jgA2dazGGQ
Thanks.

https://youtu.be/0jgA2dazGGQ
Thanks.
facebook.com/spacebar.max
- sjcaldwell
- Power User
- Posts: 175
- Joined: Tue Sep 20, 2016 11:05 pm
Re: Strange rule behavior
You re changing the value of pp in rule 2 before rule 3 executes. Using your rules in an excel spreadsheet I get this:Max Oepen wrote:My curiosity is focused on why this works (in the way I described):
uu=pp-64
if pp>63 then pp=uu
if pp<=63 then pp=pp*2
It shouldn't!
Code: Select all
Input Rule 1 Rule 2 If executed Rule 3 if executed
0 -64 0 0
1 -63 1 2
2 -62 2 4
3 -61 3 6
4 -60 4 8
5 -59 5 10
6 -58 6 12
7 -57 7 14
8 -56 8 16
9 -55 9 18
10 -54 10 20
11 -53 11 22
12 -52 12 24
13 -51 13 26
14 -50 14 28
15 -49 15 30
16 -48 16 32
17 -47 17 34
18 -46 18 36
19 -45 19 38
20 -44 20 40
21 -43 21 42
22 -42 22 44
23 -41 23 46
24 -40 24 48
25 -39 25 50
26 -38 26 52
27 -37 27 54
28 -36 28 56
29 -35 29 58
30 -34 30 60
31 -33 31 62
32 -32 32 64
33 -31 33 66
34 -30 34 68
35 -29 35 70
36 -28 36 72
37 -27 37 74
38 -26 38 76
39 -25 39 78
40 -24 40 80
41 -23 41 82
42 -22 42 84
43 -21 43 86
44 -20 44 88
45 -19 45 90
46 -18 46 92
47 -17 47 94
48 -16 48 96
49 -15 49 98
50 -14 50 100
51 -13 51 102
52 -12 52 104
53 -11 53 106
54 -10 54 108
55 -9 55 110
56 -8 56 112
57 -7 57 114
58 -6 58 116
59 -5 59 118
60 -4 60 120
61 -3 61 122
62 -2 62 124
63 -1 63 63
64 0 0 0
65 1 1 2
66 2 2 4
67 3 3 6
68 4 4 8
69 5 5 10
70 6 6 12
71 7 7 14
72 8 8 16
73 9 9 18
74 10 10 20
75 11 11 22
76 12 12 24
77 13 13 26
78 14 14 28
79 15 15 30
80 16 16 32
81 17 17 34
82 18 18 36
83 19 19 38
84 20 20 40
85 21 21 42
86 22 22 44
87 23 23 46
88 24 24 48
89 25 25 50
90 26 26 52
91 27 27 54
92 28 28 56
93 29 29 58
94 30 30 60
95 31 31 62
96 32 32 64
97 33 33 66
98 34 34 68
99 35 35 70
100 36 36 72
101 37 37 74
102 38 38 76
103 39 39 78
104 40 40 80
105 41 41 82
106 42 42 84
107 43 43 86
108 44 44 88
109 45 45 90
110 46 46 92
111 47 47 94
112 48 48 96
113 49 49 98
114 50 50 100
115 51 51 102
116 52 52 104
117 53 53 106
118 54 54 108
119 55 55 110
120 56 56 112
121 57 57 114
122 58 58 116
123 59 59 118
124 60 60 120
125 61 61 122
126 62 62 124
127 63 63 63
Re: Strange rule behavior
But am I really? Rule 2 only changes the value of pp "if pp >63". If rule 2 changes the value for incoming values below "63", the rule appears to not be working as it should. Right?sjcaldwell wrote: You re changing the value of pp in rule 2 before rule 3 executes...
(Thanks for the spreadsheet data. Incoming "63" and "127" should output "126" respectively, as you mentioned in your first response. Don't know why those numbers are off in your spreadsheet.)
facebook.com/spacebar.max
- sjcaldwell
- Power User
- Posts: 175
- Joined: Tue Sep 20, 2016 11:05 pm
Re: Strange rule behavior
Well if rule 2 changes the value of pp, after rule 2 pp my be lower than 63 and rule 3 will double the value of uu since you assigned pp to the value of uuMax Oepen wrote:But am I really? Rule 2 only changes the value of pp "if pp >63". If rule 2 changes the value for incoming values below "63", the rule appears to not be working as it should. Right?
...
If incoming pp <= 63 then rule 2 does not execute and rule 3 still doubles the value of the incoming pp
I suspect you were trying to evaluate the original value of pp in rule 3 and not the modified value (from rule 2).
PS.
Your 3 rules do not work perfectly, according to my evaulation. If you send a value of 127 I'll be dollars to donuts you will get output
of 63. (Not 126)
Re: Strange rule behavior
I see what you're saying. So,
I thought this whole time that the meaning literally is "if - then".
I take from your explanation that modifications to variables are always executed, even if outside the range of the rule's specifications. Is that true?
Re:
, even if pp <=63? What then is the purpose of "if"?rule 2 changes the value of pp
I thought this whole time that the meaning literally is "if - then".
I take from your explanation that modifications to variables are always executed, even if outside the range of the rule's specifications. Is that true?
Re:
Exactly right, it should!!! In fact, that started my whole quest. Because only if I added uu=uu*2 will (should) I get 126. But in practice, it behaves as in the video linked above! I.e.: It does indeed output 126 in this case.If you send a value of 127 I'll be dollars to donuts you will get output of 63. (Not 126)
Same with my evaluation, but in practice, they do! :-/Your 3 rules do not work perfectly, according to my evaulation.
facebook.com/spacebar.max
Re: Strange rule behavior
And lest we forget that this is all about music, here's a little improvisation I did a few minutes ago. You can observe the use of the translator in question as well 

https://youtu.be/kErIlrDMzOw


https://youtu.be/kErIlrDMzOw
facebook.com/spacebar.max
- sjcaldwell
- Power User
- Posts: 175
- Joined: Tue Sep 20, 2016 11:05 pm
Re: Strange rule behavior
There is no complex if then logic. If you change a variable on one rule it is the changed value that is analysis on the next rule.
To avoid this I use temporary local variables (in my example,qq) to avoid side affects.
In some cases you want these side affects as part of complex if/and/or else logic.
Check out florian's post on this subject in the tips area but in general you need to be careful in re-assigning variables in one rule that could affect future rules in the same translator.
However if you use local variables within a given translator, it will affect only that variable within that translator.
You can re-use that variable in another translator and the two will not interfere.
Beware though of global variables that are affected by all translators.
What is the pp output value when the input controller is set to 127?
BTW. From your video, looks like you are having way too much fun.
To avoid this I use temporary local variables (in my example,qq) to avoid side affects.
In some cases you want these side affects as part of complex if/and/or else logic.
Check out florian's post on this subject in the tips area but in general you need to be careful in re-assigning variables in one rule that could affect future rules in the same translator.
However if you use local variables within a given translator, it will affect only that variable within that translator.
You can re-use that variable in another translator and the two will not interfere.
Beware though of global variables that are affected by all translators.
What is the pp output value when the input controller is set to 127?
BTW. From your video, looks like you are having way too much fun.

Re: Strange rule behavior
I've messed with that too, until I realized that, by the end, the original variable (pp) is still being changed all the same, although in a different rule in this case.To avoid this I use temporary local variables (in my example,qq) to avoid side affects.
Your example with qq illustrates this:
uu=pp-64
uu=uu*2
if pp>63 then qq=uu
if pp<=63 then qq=pp*2
pp=qq <-----
that last line: if as you noted before, all previous calculations are applied regardless of incoming value, the addition of variable qq won't change the end result.
edit: I see I didn't consider your statement that
..regardless of "if"-constraints and your example with using "qq" to circumvent this does make sense. [/end edit]If you change a variable on one rule it is the changed value that is analysis on the next rule.
Link takes me to a post by metastatik, is that the right one?Check out florian's post on this subject..
The output value is 126 (in Ableton Live). I know it's mystifying.What is the pp output value when the input controller is set to 127?
Yeah, I sometimes feel having this much fun shouldn't be legal, lol.BTW. From your video, looks like you are having way too much fun.
Last edited by Max Oepen on Sat Dec 31, 2016 7:54 am, edited 3 times in total.
facebook.com/spacebar.max
- sjcaldwell
- Power User
- Posts: 175
- Joined: Tue Sep 20, 2016 11:05 pm
Re: Strange rule behavior
Your original codeuu=pp-64
uu=uu*2
if pp>63 then qq=uu
if pp<=63 then qq=pp*2
pp=qq <-----
that last line: if as you noted before, all previous calculations are applied regardless of incoming value, the addition of variable qq won't change the end result.
uu=pp-64
uu=uu*2
if pp>63 then pp=uu
if pp<=63 then pp=pp*2 <-- This will always evaluate to true and execute since modified pp will always be <=63 (sometimes a negative number) unless original pp was 127 in which case it output should be 63 (127-64)
The behavior of mine is slightly different. In your original you are evaluating the modified value of pp in rule 4, while mine evaluates the original value. For rule 4, yours is always executed because if original value of pp is <= 64 then it still is after your rule 3 modification (it will actually be a negative number) . If original value of pp is >63, it won't after you modify it in rule 3. Again, looks like you are always executing rule 4
Mine will only execute rule 4 if the original input value <=63
My results were slightly different (at least on paper). When I put in 127 I get out 126. Not sure why you are getting 126. Maybe I should load up BMT and look deeper.
Yes scroll down to logic section. I guess sometimes florian has others do his editing. He put this in after a discussion I had with him.Link takes me to a post by metastatik, is that the right one?
IndeedThe output value is 126 (in Ableton Live). I know it's mystifying.
Re: Strange rule behavior
Great discussion, thanks so much for your input, SJ!
facebook.com/spacebar.max