#200

Just started playing with the beta 8 with my brand new TXi – it seems to lockup anytime I use a II command (either communicating with the TXi or Ansible) I’ve tried reinstalling the beta again to make sure everything went okay, and any non-II commands seem to function fine. I’ll try reverting back to 1.4 to see if that fixes it or not, but wanted to know if there’s anything else I should try. Thanks!

EDIT: My II cable connecting the TXi was reversed! SMH All is well

Telex: Teletype expanders
#201

I think I found a bug, unless a behavior has changed that I’m not aware of. In beta 8, the PARAM knob doesn’t update it’s values when in tracker mode. Immediately when I switch to scene edit or live mode, it behaves normally. (I have a script running a CV delay where PARAM determines the span of the delay taps):

T ADD 1 RSH PARAM 10
X SUB P.I T
Y SUB X T
Z SUB Y T
A SUB Z T

And just to double-check I used Ansible to output the PARAM value:

CV 5 PARAM

And tried that in both metro and script 1, both with the same result – PARAM is unresponsive until I leave tracker mode.

Thanks for all your work on this, let me know if you need any more information about this!

#202

Another bug just ran into:
Script 1

CV 1 TI.PARAM 1

This freezes with somewhat fast clocks (White Whale’s clock knob a little past noon). The rest of my scene is empty

#203

How many devices do you have on your bus beyond your TXi?

#204

Good catch. It’s an easy fix though.

A lot of the code regarding the editing modes was rewritten as part of the beta, the bit of code that passes the knob value to each of the modes has some logic in it based on the mode (e.g. when in preset read mode, don’t update the PARAM value as the knob is used as part of the UI at that point).

The same change was made for pattern mode, but it hindsight it needs to be made available to the pattern mode and update the PARAM value.

Phew. I must admit to having a moment of dread when I saw the email this morning.

#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