#186

Thanks a lot, @tambouri. It is definitely rewarding to see them out in the wild after so much work. Not as off topic as you think as the work that @sam has put into the Teletype firmware was a significant part of the effort that made the expanders possible. Especially all of the i2c-related enhancements that are in the 2.0 Beta branch. :slight_smile:

1 Like
#187

I’ve just had a look at my calendar, and I think come Saturday 20th of May I’m going to need to put my Teletype back in it’s case. It’s a slightly artificial deadline, but it’s come about as a result of needing to start tidying up the house before the baby arrives later in the year.

The practical upshot of this is that I won’t be able to do any more serious debugging of Teletype issues (crashes, i2c problems, etc) as access to the serial port will be too cumbersome. I’m hoping to get most of the documentation stuff sorted by then too.

(Fiddling with aliases and ops is very easy without the serial port, in fact it’s pretty easy to do without the Teletype.)

Anyway to that end I’ve opened up a PR to merge in the work that I’ve do some far, whilst I can’t promise that it’s bug free, I do believe it to have less bugs than 1.4 (they just might be different bugs).

There is a corresponding PR to libavr32 too:

(plus another to Ansible for the libavr32 change, Trilogy PRs to follow).

It’s probably time to starting thinking about an actual release now…, I’m not particularly fused about timescales myself as my Teletype is nearly always running the latest source code, but Telexes are now out in the wild, so the timing seems good.

I did see some talk about demo scenes based on the newer features.

Also, I should get most of the work done on the Python code for the documentation this week, then I’ll be asking for help to get it filled in (thanks @tambouri!).

2 Likes
#188

A small thing which I’m curious about in the pattern tracker. I want to say shift+enter previously extended the pattern range in addition to copying the selected pattern value, currently I’m only getting the copying, but the pattern length remains the same.

Per the key bindings page it seems like the intended behavior is still to increment the pattern length in addition to duplicating

shift+enter | duplicate entry and shift downwards (increase length as )

I found the combined effect really helpful, if that isn’t terribly difficult to reimplement or was something which was removed w/ intent. thanks!

#189

I’m going to be working on Aliases for the TELEX operators this week - most likely while flying back to LA on Thursday/Friday. Should go very quickly based on my glance at the code.

The only thing that will take time, I think, is to figure out the string of git commands to switch my upstream branch to your fork and make sure that libavr32 stays in sync (it keeps detaching whenever I do something simple).

Might just wipe my fork all together and simply fork your fork. I tend to get lost in git hell from time to time. :wink:

1 Like
#190

i am back in town as of now, though my brain is fried. i’ll get an understanding of this massive undertaking in the next few days.

thank you @sam, i look forward to learning a lot from this code. you’ve certainly eased entry for new people to contribute-- code that’s actually understandable!

3 Likes
#191

Any thoughts on creating a command to reset TO cv outs so all settings are returned to zero (namely OSC and ENV But slew and offset could be useful too). Since those settings appear to retain between scenes a single reset command would be very useful in saving initialization space.

Or would this be better solved by building a scene specifically for this purpose?

1 Like
Telex: Teletype expanders
#192

that’s a good idea. i’d appreciate having an INIT command (for both TT and TO) that resets all slews, CV offsets, etc. to zero.

1 Like
Telex: Teletype expanders
#194

Submodules are often detached (and that’s okay), you want them to point at a particular commit as specified by the parent repo, not a named branch. Just pay attention to git status in the parent repo.

You don’t need to switch your upstream branch to mine as such. It can be helpful to think of a git repo as a local collection of commits that’s a subset of some larger global collection of commits. What we want to do is to ask git to bring my commits into your local repo, to do so we use the fetch subcommand (which also updates the branch names that are used in my repo).

cd teletype
# add my GitHub repo as a remote
git remote add samdoshi https://github.com/samdoshi/teletype.git
# import commits in my remote that you don't have, and update branch references
git fetch samdoshi

(git fetch <remote> will not pull in unreferenced commits.)

You need to do the same for the libavr32 submodule, as when you checkout my 2.0 branch and do a git submodule update, git will expect the libavr32 submodule to have the relevant commit stored locally.

cd libavr32
git remote add samdoshi https://github.com/samdoshi/libavr32.git
git fetch samdoshi
cd ..

Now we need to checkout a copy of my 2.0 branch

# if you want a local branch
git checkout -b telex_aliases samdoshi/2.0

# or if you only want to play with the code temporarily
git checkout samdoshi/2.0

# don't forget to update the submodule, whichever you do
git submodule update

Eventually once you’ve committed some changes, you’ll want to push to your origin…

While I’m on the subject, here are some things for your .gitconfig (or .config/git/config)

[status]
    submoduleSummary = true
[url "git@github.com:"]
    ;; e.g git remote add gh:samdoshi/my_repo.git
    ;;     git clone gh:samdoshi/my_repo.git
    ;;     (git clone gh:samdoshi/my_repo also works)
    insteadOf = gh:

(apologies if you know all of this already)

3 Likes
#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