#195

Super helpful! Saves me having to re-discover some of the above. I appreciate the time you took to do this. Thanks!

3 Likes
#196

I’ve just looked at the code, which has a slightly different description:

// shift-<enter>: duplicate entry and shift downwards (increase length only
// if on the entry immediately after the current length)

I don’t think this is really that useful in hindsight.

Perhaps if the index of entry you’re duplicating is less than or equal to the current length, then increase the length by 1.

The only downside to that is that if you’re not expecting <shift>-<enter> to increase the length you may get a nasty surprise, especially as you might not be able to see that the length has increased.

The other option would be to disable adjusting the length for <shift>-<enter> entirely.

#197

INIT commands are cool, and would have been one of the ops I added if I had a bit more time (and I still might do anyway). But they should be pretty straightforward to do.

One warning though, there are many different interpretations of what one should initialise, so I would suggest using more explicit naming, e.g.

  • INIT.VAR: reset all the variables back to power on defaults (esp. important as these are not reset on scene change)
  • INIT.CV x: reset all the attributes of a particular CV
  • INIT.TR x: likewise
  • P.INIT / PN.INIT: reset a pattern
  • INIT.ALL: everything
  • Telex…
  • TO.INIT.CV
  • etc

We will also need to think about how they overlap with the KILL op too.

I should get the ops documentation up and running this week, hopefully that will make it more obvious what INIT ops would be good, and more importantly what they should do. I find that I can end up forgetting about ops that don’t mesh with how I think (stack and queue ops are the ones for me).

1 Like
#198

Forgot to say, make sure you can compile the 2.0 branch before you get on the plane, there is an additional dependency on ragel now.

There is a section in the README.md in the 2.0 branch on adding ops, so if you get stuck while in mid-air (figuratively… not literally!) that should be able to point you in the right direction. Also make test in the tests to double check that everything has been entered correctly.

Bon voyage!

#199

I totally get if earlier shift+enter implementation wasn’t a feature anyone else had an affinity for and likely not something to get worried over for 2.0 release, so no sweat if it gets nixed. Just my 2 cents, but i found the original implementation pretty useful

It also seemed to pair nicely and mirror the shift+delete behavior of removing a value and subtracting a value in a way which I found intuitive and which could quickly add subtle or extreme variations to the loop + loop length.

while i’m on my soapbox, I have always expected after the shift+enter copied the value and extended the loop it would move the cursor to the new copy. That always seemed where I wanted to logically be after I made the copy.

all very tiny thoughts i’ve had in the midst of absorbing all the awesomeness of the new betas and telex updates. thanks for all your hard work

1 Like
Teletype 2.0 documentation
#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