#955

sorry - i should’ve been more clear - it’s just a proposal, not currently implemented.

1 Like
#956

Great :+1:t3: cool I will made from here. Thanks again.

#957

Ah ok I was believe it’s rule.
Yes it’s a good idea that you have, I hope it will developed, it can simplify things.

1 Like
#958

I’m trying to add probability to a trigger pattern but my skills are still poor.
Having a simple pattern:
1 0 0 1 0 1 1 0

and script 1 with:
X PN.NEXT 0
IF NZ X: TR.P 1

Script 1 is triggered by metro with $1

How can I add a PROB op to decide to read or not the 1 values in the pattern?

#959

My favored method of adding probability is to generate a random number in a fixed range and move a threshold around within that range. Then random numbers which fall above the threshold can be your triggers. I also shy away from conditional PREs and use the ternary IF operator ? instead, where possible.

But in your case, I’d use PROB Y: TR.P ? X 1 5. There is no trigger 5 to ping, so that gets ignored.

1 Like
#960

First lets do some spring-cleaning, shall we?

J PN.NEXT 0
IF J: TR.P 1

Or in one line:

IF PN.NEXT 0: TR.P 1

You go back to the two line version like this:

J PN.NEXT 0
PROB 90: BRK
IF J: TR.P 1

Or with RND

J PN.NEXT 0
IF && J ! RND 9: TR.P 1

Not sure this one-liner will fit (away from my teletype):

IF && PN.NEXT 0 ! RND 9: TR.P 1

If you set the pattern somewhere else (or don’t change it somewhere else), you can loose the “0”:

 IF && P.NEXT ! RND 9: TR.P 1
6 Likes
#961

@desolationjones and @a773 your ideas and explanation worked perfectly and introduced me some concepts I’m still missing with practical examples, many thanks! :pray:

1 Like
#962

you could also use the pattern values themselves to set the probability for each step:

PROB P.NEXT: TR.P 1

3 Likes
#963

Hi everyone,new teletype user here, with some trouble loading scenes. On a side note, when I first turned on my TT, I noticed a lot of constantly LED flickering lights on the TT. After a firmware update (see below), this has resolved. And the stock keyboard seems to be faulty as well. When I type a key, it keeps eternally repeating this letter.

So, I downloaded a few scenes from this forum, renamed them tt##.txt and put them on a USB stick (FAT formatted) and inserted that into my teletype. The teletype screen flickered briefly and that was about it. No request to overwrite scenes and no “read” or “write” message. I tried that with numerous USB sticks, to no avail. I then updated my teletype firmware from 3.0 to the newest one, which is 3.2. Still no difference. However, I managed to also get my default scenes wiped in the process, and now have no scenes at all. When I try to flash the firmware again, it does ask me whether I want to overwrite scenes, and I push the button next to the USB port on my teletype. Nothing seems to happen when I do that; the screen does not change until I reboot. I also downloaded the default TT scenes but can’t upload them to my TT as the USB method doesn’t work. What should I try next:

  1. Try a newer USB stick instead? Which one (could you provide a link to Amazon in the US?)?
  2. Maybe this is erratic behavior due to insufficient power in my rack (Arturia RackBrute)? Maybe I should disconnect a few modules from Eurorack power?

Thank you so much for your help! Marius

#964

This definitely seems worth trying, the behavior you describe sounds like quite possibly a power problem – seems like this could also result in supplying insufficient power for correct operation of attached USB devices.

#965

I did that: I disconnected several other modules and it still doesn’t work. I re-flashed TT 3.2 firmware, and it asks me to overwrite scenes at the end of the process. I push the button next to the USB port, and at first nothing happens. No confirmation, or read or write message. After a few seconds, I end up at the code entry prompt but the default scenes are not there. Any other ideas how to recover my default scenes and upload new scenes via USB? Thanks os much, Marius

#966

it will show that message whenever you flash a new firmware - this is normal. it’s just a safeguard to prevent overwriting scenes accidentally.

the default scenes are only included when you flash one of the official releases - are you using a beta version? if so, you can still get the default scenes by copying them via a USB stick. if you’re unable to read scenes from a USB stick, that sounds like a separate issue.

#967

Good to know that I shouldn’t be expecting default scenes with a firmware flash. So, that leaves me with having to figure out the USB upload problem. I will try a new USB drive next (I chose a 16 GB USB 2.0 off amazon - felt that was conservative enough). Will see what happens. Marius

#968

you should expect the default scenes after flashing - but only if you use the official release. where did you get the firmware file from?

#969

I got the official firmware from github (at https://github.com/monome/teletype/releases), which in turn was linked from the official monome firmware update web site. That all said, I solved the problem not being to upload scenes to teletype: it was the USB sticks. In a pinch, and after having tried all USB sticks available in my household, I used an USB SD card reader instead, and that worked flawlessly. Thanks, Marius

1 Like
#970

email help@monome.org for a new keyboard of it ends.up being dead. might want to test it on a computer to check.

#971

I’m not sure the exact effect of INIT is, hoping for help here!

Is it correct that INIT brings the teletype into the same state as just after reboot, and before any I script were run? And it won’t affect calibration and such?

#972

It looks like INIT will preserve all calibration data.

From init.c:

static void op_INIT_get(const void *NOTUSED(data), scene_state_t *ss,
                        exec_state_t *NOTUSED(es),
                        command_state_t *NOTUSED(cs)) {
    // Because we can't see the flash from this context, we cache calibration
    cal_data_t caldata = ss->cal;
    // At boot, all data is zeroed
    memset(ss, 0, sizeof(scene_state_t));
    ss_init(ss);

    ss->cal = caldata;
    // Once calibration data is loaded, the scales need to be reset
    ss_update_param_scale(ss);
    ss_update_in_scale(ss);
    ss_update_fader_scale_all(ss);

    tele_vars_updated();
    tele_metro_updated();
}
#973

Ah, cool thanks!!!

#974

Can someone explain what exactly muting scripts does?

My case: I have a bitwise operator in $ 8 (called by M), using a sequence to trigger scripts 1-7 using binary (hope this description makes sense lol). If I “mute” M the metronome stops as expected. However if I mute individual scenes nothing appears to change other than the script number toggling from illuminated to dimmed. For example, let’s say I have script 1 with TR.P 1 and and the my binary sequence is calling script 1 at step 5 every time. If I mute script 1 I would expect this trigger to not be active anymore but it is still sending the trigger.

To put it more simply, if I am triggering $ 1 and then I mute it, but continue to send it triggers, shouldn’t it stop responding to the triggers until I unmute it? If not, what is the use case of the muting?