#205

As per this comment from @Galapagoose

I’ve mentioned on that thread that the way that IF/ELIF/ELSE has been fixed so that the effects that @Galapagoose describes no longer works.

The fix isn’t perfect due to the way the language works. The major change is that the IF/ELIF/ELSE condition flag is reset whenever a ‘trigger’ event occurs. (A ‘trigger’ event being an actual trigger at inputs 1-8, a metro event, or a delayed command).

I’m also not entirely convinced that they way I’ve chosen to do it is right.

Some examples of how it currently works in 2.0b8:

1: Intermediate statements always run

1:
IF 0: 0        # do nothing
TR.P 1         # always happens
ELSE: TR.P 2   # else branch runs because of the previous IF

2: ELSE without an IF

1:
ELSE: TR.P 1   # always runs, as there is no preceding IF

3: ELIF without an IF

1:
ELIF 1: TR.P 1  # always runs, as there is no preceding IF

4: Independent scripts

1:
IF 1: TR.P 1    # pulse output 1

2:
ELSE: TR.P 2    # always pulses output 2, regardless of what happens
                # in script 1 (see example 2)

5: Dependent scripts

1:
IF 1: TR.P 1    # pulse output 1
SCRIPT 2        # will _not_ pulse output 2

2:
ELSE: TR.P 2    # will pulse output 2 if called directly, 
                # but not if called from script 1

Looking at these examples, I’m not happy that an ELSE or an ELIF will run without a preceding IF statement (i.e. examples 2 & 3) I believe that the change is fairly straightforward, and is also easy to write tests for. Unless I hear otherwise I will make that change.

#206

Only Ansible and Just Friends (which I could disconnect as I’m not actually running Just Type) - I can try plugging in just 1 device tonight if you think it might make a difference

Edit: should mention these are connected via the II busboard

#207

I’ve made the IF / ELIF / ELSE change (and fixed the PARAM issue @xeric reported). They’ll be in the next release (whenever that is).

Updated rubric…

1: Intermediate statements always run

1:
IF 0: 0        # do nothing
TR.P 1         # always happens
ELSE: TR.P 2   # else branch runs because of the previous IF

2: ELSE without an IF

1:
ELSE: TR.P 1   # never runs, as there is no preceding IF

3: ELIF without an IF

1:
ELIF 1: TR.P 1  # never runs, as there is no preceding IF

4: Independent scripts

1:
IF 1: TR.P 1    # pulse output 1

2:
ELSE: TR.P 2    # never runs regardless of what happens
                # in script 1 (see example 2)

5: Dependent scripts

1:
IF 0: TR.P 1    # do nothing
SCRIPT 2        # will pulse output 2

2:
ELSE: TR.P 2    # will _not_ pulse output 2 if called directly, 
                # but will if called from script 1
5 Likes
#208

Hi @sam, just for let you know, i am experiencing crashes whenever TI.PARAM is used, i mean not when i input the code but once i turn the knob:

1.

TI.PARAM 1
TR.PULSE 1

After that start a steady triggering of pahe 1, just turn TI/PARAM knob for a few seconds and boom :dizzy_face:

1 Like
#209

Is that in metro? I was also crashing when accessing TI.PARAM when triggered by fast(ish) clocks

#210

No in page 1 but it seems to be the same everywhere.

#211

@xeric and @martinmestres, do you have the same issue with TI.IN?

edit: also, have either of you tried it with 1.4.1, does that have the same bug?

1 Like
#212

I haven’t tried TI.IN yet or 1.4.1 – will check that out tonight and report back

1 Like
#213

No i used the last beta, I didn’t tried IN either, I will do that tonight and keep you informed of the results .

#214

Docs update…

docs.pdf (54.0 KB)
docs.html (20.4 KB)

I’m not entirely sure where I’m going with the ‘extended op documentation’ section yet.

The workflow is hand-written Markdown plus toml plus Python produces a combined Markdown file, which is then fed through Pandoc to produce the HTML and the PDF.

The Markdown files are pretty vanilla, e.g. the keyboard docs are the same as linked to earlier.

An example of the toml is:

[D]
prototype = "D"
prototype_set = "D x"
short = "get / set the variable `D`, default value `4`"

[DRUNK]
prototype = "DRUNK"
prototype_set = "DRUNK x"
short = """changes by `-1`, `0`, or `1` upon each read saving its state,
setting will give it a new value for the next read"""
description="""
Changes by `-1`, `0`, or `1` upon each read, saving its state. Setting `DRUNK`
will give it a new value for the next read, and drunkedness will continue on
from there with subsequent reads.
"""

["DRUNK.MIN"]
prototype = "DRUNK.MIN"
prototype_set = "DRUNK.MIN x"
short = "set the lower bound for `DRUNK`"

I don’t have a massive amount of control over the generated PDF (not without a lot of headache anyway).

I am however inviting recommendations for some open source fonts, I need a proportional one, and a monospaced one. The current document is done with Helvetica and Menlo which are a bit Mac only (and I can’t include them in the git repo). Both fonts will need bold, italic and bold+italic variants. The usual suspects are, Roboto, Source Sans/Code Pro, and Ubuntu (and other Bitstream Vera derivatives).

Once I’ve got things a bit more nailed down, I’ll start a new thread for those that wish to contribute (I’m not doing all of them on my own!!!). Contributions welcome from all technical abilities.

2 Likes
#215

@sam @bpcmusic

I ran some tests, the following script always result in crash (not instantly but in less than 30 sec):

TR.PULSE 1
RSH TI.PARAM 1 8

Exact same result with TI.IN 1 (or any TI.IN / TI.PARAM).

I tried this script with the last 2.0 BETA and 1.4.1 firmware => Crashed every time

No problem with Teletype’s basic PARAM and IN though.

Hope you guys will manage to fix that thing :heart:

1 Like
#216

Thanks so much for the investigation here. I’ll see if I can replicate with my road system and also check it out with the Ansible when I get back.

If anyone is interested in looking at this further - do you experience the same doing the read in the metro script? Maybe it still has something to do with how the TT handles triggers?

#217

Ok i just tried the same things on 1.4.1 using the metro script and i encountered no problem at all. So you might be on the right track :wink:

1 Like
#218

Interesting. If anyone gets to try it with the metro on 2.0 please report back.

It’s definitely worth seeing if Ansible has the same issues.

#219

Ok i installed back last 2.0

M.ACT 1
M 200

M

TR.PULSE 1
RSH TI.PARAM 1 8

All the TI.PARAM and TI.IN crashe (either instantly or in less than 2min). TR.PULSE is only here in order to give me a visual feedback.

1 Like
#220

Firstly, thanks for the feedback it is definitely appreciated, as well as all the other tests you’ve done (likewise to @xeric).

If you’ve got time, could explain what happens when it crashes? Does everything stop responding, i.e. the keyboard and the front panel button and the screen. Or is it more limited than that?

#221

I could try something on Ansible but did not understand what would be expected?

It has no PARAM, so I tried it with STATE and at least did not find any problems within 30 seconds by now.

Also what is RSH TI.PARAM 1 8 supposed to do?

#222

The RSH is a bit redundant. Really TI.PARAM 1 would be fine too. (The 8 is the second argument to RSH.)

The test we’re interested in is to try reading a value from Ansible (e.g. STATE or MP.PRE), do it in a trigger and in a metro, do it quickly for both. Does it crash? If not increase the speed…

Basically, i2c communications fall in to 2 categories, write only (e.g. TO.CV) and write then read (TI.IN and STATE on Ansible). There aren’t that many i2c ops in the later category. So knowing if the issue affects both Ansible and TELEXi, or just one of them tells us something very useful.

#223

Yes, but the line actually has no effect on anything, has it? Just for my understanding…

I can’t find a problem using Ansible with this script and trigger out 3 patched to 1:

M:
TR.PULSE 3

1:
CV 1 STATE 9
TR.PULSE 1

I have M running at 1 at the moment with a TR.PULSE 1 1 and everthing seems fine with the newest 2.0 beta (2.0b8:D28120A)

#224

Okay, now it crashed somewhere between M 7 and M 12, which is still pretty unrealistic. What would be a proper amount to let this run for some time?

1 Like