A draft of some PROB tweaks I made for teletype

Monome
#1

Hello All,
I built a firmware release based on me branching the latest for you all to play with if you want some probability tweaks

  • PROB can now use an ELSE Conditional
  • PRB is an alias of PROB
  • new OP WTOSS x ( 0-100) (alias WT x) works similar to PROB but returns a 1 if true or 0 if false

example/

// Simple PROB with ELSE
PRB 70:  TR.P 1
ELSE: TR.P 2

// Simple WTOSS (90 % chance triggering gate one ... if not, get 4
TR.P ? WT 90 1 4 

// Combining for Cascading

PRB 30: TR.P 1  // 30 % chance triggering gate 1
ELIF WT 70: TR.P 2 // now a 70% chance of triggering gate 2
ELSE: TR.P 3 // If no successful of probabilities then trigger gate 3
6 Likes
#2

What hapens if I have an IF statement before PROB? Is the ELSE adressing the PROB or the IF?

#3

Nice, I could see myself using these all the time! My vote for a PR!

1 Like
#4

It is a toplevel modulator, so that is why I added a WTOSS (WT). You can do something like:

IF EQ X 100: TR.P 1
ELIF WT 80: TR.P 2
ELSE: TR.P 3
#5

the ELSE would be addressing the PROB in your statement based on the order of operations.

#6

This is a tricky change because it modifies the behavior of existing scripts. Consider:

IF A: B + B 1
PROB 30: B - B 1
ELSE: SCRIPT B

Currently, the ELSE is triggered if the IF doesn’t fire. Your change would cause PROB to take over the else-state and now ELSE is controlled by the PROB.

I think WTOSS is a great idea and that by itself would allow you to accomplish the same thing; just use IF WTOSS instead of PROB, and now you have access to ELSE in a backwards-compatible way. Not quite as terse, but it doesn’t change behavior of existing scripts, and it also keeps the IF/ELSE, EV/OTHER pairing neat (following that pattern, PROB should get its own unique paired “other case” operator, but I don’t think it really needs one if you have something like WTOSS.)

4 Likes
#7

Yeah, that’s exactly why I asked, the way ELSE is set up right now it doesn’t need to immediately follow the IF statement, and changing that would constitute a breaking change which seems to be a nono for updates.

I think WTOSS is a lovely addition and I agree with @Dewb, if it’s introduced then the requirement for ELSE to work with PROB is fully substituted, unless I’m missing something.

Also +1 to PRB as an alias for PROB

1 Like
#8

Thanks @djwglpuppy for the nice addition!

+1 for PRB.
+1 for WTOSS.

Regarding PROB/ELSE: I agree with @ParanormalPatroler and @Dewb 's concerns. Also, I agree, using IF WTOSS in combination with ELSE would work.
However, for purely “code aesthetic” reasons, I also like Dewb’s idea of giving PROB a paired “other case” operator, following the pattern of IF/ELSE and EVERY/OTHER. That way, no existing functionality would be broken or changed (just a new OP introduced), and it would follow the existing convention nicely.

Admittedly, the difficulty is to find a good matching word.
REMAIN, REST, FAIL, …?

1 Like
#9

PROB/IMPROB ? :sweat_smile: + 20 characters

1 Like
#10

Maybe NOTP :person_shrugging:

#12

PROB/BROP like how Bourne does it is an idea.

Bothers me a little that it doesn’t fit with the other pairs in that way but it does work.

3 Likes
#13

ooohhh, i really like PROB/BROP :+1:

3 Likes
#14

Just came to the hilarious realization that it should be PROB/BORP which I like a lot more because it sounds funnier.

2 Likes
#15

my partner said the same thing this morning over breakfast lol

1 Like
#16

Chiming in to say that I’m in favor of these new ops, as I experience the need for them very often.
Also, PROB / BORP sounds ok to me.

1 Like
#17

BORP and BROP should be both present. Either as aliases or pick one to be a sort of elseif.

(Just because I like how both sound)

2 Likes
#18

This is turning into onomatopoeia … :sweat_smile:

Since PRB is the alias for PROB, it would BRP for BORP.

4 Likes
#19

Burp is now a mathematical term. Nice.

2 Likes