#1285

Cool, first reaction, it it works and fits in your tt, why bother?

But here are some (more constructive) input:

  1. As far as I can see, you’re not reading T anywhere, so you can remove it entirely with this line replacing your first two lines of #M:

    M * 2 LAST 1

  2. Regarding #1, seems like you’re trying to have a 33% chance of K being 12, 7 and 0, however those lines will not give you that. Something like this (untested) should be similar (will have 33% chance of each of 0, 7 and 12):

    K * TOSS 12; K ? RND 2 K 7

Hope that helps :slight_smile:

2 Likes
#1286

Yes, on TT everything works fine, but I would love to learn more and to be more elegant while coding :slight_smile:

  1. You’re right. Still, I can’t understand why t f I wrote those T 1 on $ 3 and $ 4
  2. Yes, that is what I’m trying to have on $ 1. I will try the ternary if, BUT just to understand what you wrote:
  • K can be 0 or 12 at every trigger
  • then you wrote K is (? RND 2 K 7), and RND 2 can be 0, 1 or 2, so
    if K is 0 or 12, and RND is 0, then K is always 7
    if K is 0, and RND is 1 or 2, then K is always 0
    if K is 12, and RND is 1 or 2, then K is always 12
    But still I can’t perfectly master the logic… I think I can’t write nothing similar at this moment. Sorry but the ternary if drives me crazy :exploding_head:
    :smiley:
#1287

First, let’s put it on two lines (as you know semicolon separates commands on the same line):

K * TOSS 12
K ? RND 2 K 7

TOSS is randomly 1 or 0 (basically the same as RND 1), multiply by 12 and you get either 0 or 12, so after the first line, K is either 0 or 12 (50/50 chance).

The second line possibly overwrites K, possibly keeps it’s current value (either 0 or 12, from the first line). RND 2 returns either 0, 1 or 2, and since true in tt is non-zero, RND 2 has 66% chance of being true. If it’s true it put’s K in K (keeps K’s value of either 0 or 12), the other 33% of the time it puts 7 into K. These 33% of the time will “eat” equally into the 50/50 of the previous value of either 0 or 12, effectively reducing the chance of K being 0 from 50% to 33%, same with the chance of K being 12. So K will end up with a 33% chance of being 0, 12 or 7.

Obviously there’s some rounding missing here (33 + 33 + 33 is not 100), so to be exact: one 3rd of the time (33.3333333333333…% chance) K will be 7, one 3rd of the time it will be 0 and one 3rd of the time it will be 12, which I imagine it even better than 33% :slight_smile:

Did that help?

6 Likes
#1288

Seems perfect! great explanation, thank you.

This saves me a lot of lines to try something is in my head: the train of incoming triggers on 1 will have its output time on tr out 1 kinda smashed, with the Param knob setting the power of the destruction of the original timing. Today I will try to work it out

1 Like
#1289

Reminds me of this example of sequential probability calculations from the Discord chat:

Prob 25: M 500; BRK
Prob 25: M 350; BRK
Prob 50: M 1000; BRK

Somewhat counterintuitively, this gives 25% chance of M 500, 18.75% chance of M 350, 28.125% chance of M 1000, and 28.125% chance no change to M. Whereas this:

PROB 50: M 1000; BRK
PROB 50: M 500; BRK
M 350

gives 50% chance M 1000, and 25% each to M 500 and M 350.

2 Likes
#1290

Here’s an approach I’ve used in the past that’s a little more generalized. The setup is this:

  • A list of weighting values in the pattern buffer, of whatever length you want N, where N is the number of different values you want to choose from randomly but weighted to suit
P.N 0; P.END 6; P.I 0; A 0          // setup, for 7 weighted values in P
L 0 P.END: A + A P I                // first, get the sum of all weighting values
B RND - A 1; A 0; O 0; P.I 0        // pick the random based on the sum, initialize for the while
W >= B A: A + A P.NEXT; O           // while random > running total, add to the total, increment O
A O                                 // here, O is the resultant weighted random choice, 0-6

So the idea is, each weighting value in P represents the relative amount of weight that value will have in the randomized result. If you’re hardcoding it, you can set them to percentage numbers, as long as they all add up to 100. But you don’t have to use percentages, you could use counts or however you want to think about it, the resultant output value will treat all of the values as 100% and choose a random value that is weighted to the degree you want, assuming the RAND function has a well distributed output.

For instance, if you take the 7-element example here, and fill the P buffer with: 1 1 1 10 1 1 1, then it should pick 3 as the result approximately 10 times as often as it picks any of the other values.

4 Likes
#1291

Is there a description somewhere for how to interpret the pattern & grid data as saved with a script exported from Teletype?

I get that the second part of the #P is the contents of patterns, and I’m guessing that the first part is pattern lengths, wrap, and start / end (?) but what’s what?

#P
0	0	0	0
1	1	1	1
0	0	0	0
63	63	63	63

The grid data under #G - I’m completely in the dark there, though. :thinking:

Edit: I’ve saved a script that has this at the bottom:

0	0	0	0	0	0	0	0	7	0	0	0	0	0	0	0
0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0

What does the “7” mean? Why is it there?

1 Like
#1292

Brilliant script. Thanks for sharing!

#1293

Hi all,

I’m having a really odd issue. I have a Teletype running firmware 3.2.0, and an Ansible running 3.0.0 (both flashed successfully this morning). I’m just getting into i2c comms and was playing with the Ansible commands from Teletype.

All of the commands work as expected (e.g. KR.PRE, ES.PRESET, ANS.G.LED), but when I try to use any of the MP commands (e.g. MP.PRE to return the current preset number) I get the UNKNOWN WORD error thrown back at me (e.g. UNKNOWN WORD: MP.PRE).

When I first hit this I thought it might have been a firmware issue or I was running an older version of something, which is why I reflashed the firmware, but it has persisted. I checked the Teletype source code to be triple-sure I was entering the right command, and it all looks to be correct.

All other i2c behavior on the bus is totally normal, all Teletype and Ansible behavior is normal, and if I put the Ansible into Teletype extender mode it all works as expected.

Any help would be greatly appreciated.

#1294

You’re looking for ME.PRE

they’re all ME according to this

1 Like
#1295

Ah! That is exactly it, thanks so much!

Turns out I was consulting https://monome.org/docs/ansible/teletype (which still lists MP as the namespace for those functions). It doesn’t look from the Ansible repo that the docs are being generated programmatically so I might ping @tehn on this one as a heads up. Happy to submit a PR if there’s an open repo with the Ansible docs in it!

#1296

if i recall, MP is the standalone meadowphysics trilogy module.

ME is meadowphysics mode on ansible.

will check on the docs.

#1297

no, the ansible docs are not programmatically generated so this is indeed a typo. fixing now.

1 Like
#1298

the grid data section stores current button states and fader values. first you have 16 lines of 16 digits each (since for buttons it’s just on/off) for 256 available buttons, followed by 4 rows of 16 values for 64 available faders. you must’ve used a grid fader in a scene - it will keep that value unless you move the fader or reset all controls with G.RST.

for patterns the first 4 rows represent:

length
wrap
start
end

1 Like
#1299

Aha! 20 characters of :bulb:
Thank you!

#1300

And yet these aren’t saved with the Scene, right? Why is that the case? I can use I to initialize my grid with specific functionality (thank you sooo much for the very helpful tutorials on GitHub, they are great) but I can’t save a pattern of buttons.

#1301

button states and fader values are definitely saved with the scene. do you mean button and fader definitions? these are not saved automatically, the idea is that you would put the ops that initialize them in your init script.

#1302

Just so that I understand, let’s say I’m following your Simple Step Sequencer example, trying to turn the internal grid into a trigger sequencer. I know I have to place the grid ops definitions for the buttons in Init so that the scene initializes them, but can I save the current trigger pattern (essentially the on off state of each button) with the scene, so that my trigger sequences are there when I load the scene?? I guess these would be values on each grid point, so those would get saved after all, and it’s just a matter of Init to apply the proper grid ops to take advantage of the values!
Makes sense.

#1303

yes, button states and fader values are saved precisely because otherwise something like a trigger sequencer wouldn’t be very usable if you lost your patters each time you power cycle, and they are restored whenever you load a scene. the only exception is SCENE.G op which is intended to be used precisely when you don’t want to restore button states / fader values.

when you initialize grid controls, that doesn’t reset their state, which is why you can reinitialize them in the init script each time a scene is loaded. if you do want to reset values it’s easy enough to do with G.GBTN.V or G.GFDR.V (which will set the button state or fader value for the whole group) or just looping with G.BTN.V / G.FDR.V.

1 Like
#1304

Hey all, this is my first post here so I hope I’m doing it right. I’m trying to update the firmware on my TT, and I can’t get the bootloader to start. I’m using a USB A to A cable, and I’ve tried loading it without a cable at all and nothing is happening. I’m sure I’m just missing something, any help?