Strange rule behavior

[Max Oepen]

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??

[sjcaldwell]

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

[Max Oepen]

Thanks for the quick reply!

However, you could probably solve this much simpler

The 3 rules I have work perfectly. I don't believe you could simplify further.

Note that you will never get a value of 127

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.

uu=pp-64
uu=uu*2
if pp>63 then qq=uu
if pp<=63 then qq=pp*2
pp=qq

Thanks. The use of qq seems to be unnecessary, thus redundant. Similarly, I'm not sure why it's..

Not a good practice to make multiple mods to the same variable

Should be perfectly ok to do that, no?

Thanks!

[Max Oepen]

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!

[Max Oepen]

This little video gives a visual illustration to help understand:


https://youtu.be/0jgA2dazGGQ

Thanks.

[sjcaldwell]

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!

You re changing the value of pp in rule 2 before rule 3 executes. Using your rules in an excel spreadsheet I get this:

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

[Max Oepen]

You re changing the value of pp in rule 2 before rule 3 executes...

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?

(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.)

[sjcaldwell]

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?
...

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 uu
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)

[Max Oepen]

I see what you're saying. So,

rule 2 changes the value of pp

, even if pp <=63? What then is the purpose of "if"?
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:

If you send a value of 127 I'll be dollars to donuts you will get output of 63. (Not 126)

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.

Your 3 rules do not work perfectly, according to my evaulation.

Same with my evaluation, but in practice, they do! :-/

[Max Oepen]

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

[sjcaldwell]

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.

[Max Oepen]

To avoid this I use temporary local variables (in my example,qq) to avoid side affects.

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.
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

If you change a variable on one rule it is the changed value that is analysis on the next rule.

..regardless of "if"-constraints and your example with using "qq" to circumvent this does make sense. [/end edit]

Check out florian's post on this subject..

Link takes me to a post by metastatik, is that the right one?

What is the pp output value when the input controller is set to 127?

The output value is 126 (in Ableton Live). I know it's mystifying.

BTW. From your video, looks like you are having way too much fun.

Yeah, I sometimes feel having this much fun shouldn't be legal, lol.

[sjcaldwell]

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.

Your original code
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.

Link takes me to a post by metastatik, is that the right one?

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.

The output value is 126 (in Ableton Live). I know it's mystifying.

Indeed

[Max Oepen]

Great discussion, thanks so much for your input, SJ!