Teletype devs: please help me fix this: SC.TR.P partly broken?

First some background:
I heavily use a teletype + er-301 combo with i2c. What might set me apart from other users (and could explain why no one else seems to be bitten by this) is that my music uses a lot of fast triggers, my metro typically runs in the 100 ms range, with lots of things happening. If you wanna see examples of my scripts and hear how it sounds it’s documented here:

The problem:
After a while sometimes some triggers for the er301 (I almost exclusively use SC.TR.P) get’s delayed or are missed. The funny thing is it’s exactly one (or more?) metro cycle. It’s not at all consistent, but when it happens it follows the same pattern, so something that should trigger every other M is missing the 2nd in a loop of 8. Also a reboot of both modules (they are in the same case obviously, so always reboot together) gets things back to normal. I’s very hard to reproduce but certain things (like saving on the teletype while its running, changing the order of triggers or the order of scripts fired from M) seems to sometimes trigger the problem. I’ve found no other way of getting things back to normal besides robooting (tried loading other scenes on the teletype, reloading quicksave on the 301).

Things I thought of:
Am I stressing the teletype with all my busyness? Am I putting too much stress on the i2c bus?

So today it happened again and this time I had time on my hands to resist rebooting and continuing making music but experiment with the combo in the broken state. First I switched all i2c between teletype and 301 to patch cables. There’s still i2c involved since some of those connections were made via a txo (SC.TR.P → TO.TR.P). Interestingly the problem went away, but (expectedly) came back as I switched back to i2c between the two.

Here it comes: calling “L 1 100: SC:TR I 0” (a quite heavy operation even in my world) as the last thing in the M made everything run as expected!!! During my experiments it seems that setting SC.TR.TIME is not working (at least not in my current bonkers state).

So I looked at the teletype code (that I mostly don’t understand) and in src/ops/er301.c I see this:

static void op_SC_TR_TIME_get(const void *NOTUSED(data), scene_state_t *ss,
                          exec_state_t *NOTUSED(es), command_state_t *cs) {
ERSet(TO_TR_TIME, cs);


I have no idea, but what’s up with the NOTUSED?

So it seems something is off with SC.TR.P. It’s almost like the teletype ends up in a state where it “forgets” to take the pulse down after the trigger is done. It seems it’s not possible to read the pulse length with TO.TR.TIME (as can be done with TR.TIME, but that’s maybe to be expected?

My guess (I think I even read this) is that the implementation of the SC opcodes were modeled from the TO opcodes, and the implementation Brian did on the 301 is modeled after the code on the txo. And also I’m guessing that in this process something went wrong.

I’m hoping the teletype devs would please have mercy on me and help me out here! I’m willing to do anything to get to the bottom of this, since it’s a problem at the core of my music making! Where should I look to hack something in the firmware to remedy this? Maybe someone more knowledgeable regarding the teletype firmware could take a look, maybe it’s just an easy oops-fix? Any input highly appreciated!

Sorry for the long post, but I’m really excited, since this is the first breakthrough I’ve had with this problem that’s been haunting me since I got the teletype almost a year ago.

If I’m understanding you right, you’re saying:

  • SC.TR.P x sometimes does not clear (set to low) the trigger on the ER301. This results in a rising edge for the next trigger being missed because the trigger is already high.
  • Changing your usage of SC.TR.P to TO.TR.P and using a patch cable from TXo’s trigger output to the ER301 fixes the problem - triggers are cleared after each TO.TR.P command.

Does this sound right? Can you provide a single scene, as minimal as possible, that demonstrates the issue?


No, and believe me I’ve tried, actually the only thing I will be spending time this entire day is (yet again) try to come up with a scene + quick save that shows the problem. It seems to strike at random, possibly only when interacting with the teletype in certain (unknown) ways. Any chance you would have an idea where to look in the source without such a test set?

It seems like the attached combo will trigger the problem, first a simple rhythm, then it speeds up, let it run for a while, F1 will slow back down to check it rhythm is bonkers or it needs to run some more, F2 will go fast again.

It’s not a real world example, but it should make the problem appear after an hour or two. If it doen’t sound off after a few hours, try loading WITHOUT REBOOTING an actual set of real life quick-save/scene, and I’m pretty sure it won’t sound like you expected. (15.2 KB)

1 Like

Any resolution to this? I’m experiencing similar issues with multiple streams of quickly firing TR.SC.P messages between Teletype and ER 301. 120ms interval for metro.

It would be great to know what the processing capacity of the Teletype is actually and suspect I’m exploring the limits with some of range of things I’m tasking it with.

This was fixed in an er301 firmware a few years back…

Edit: april 2020

1 Like

Okay thanks for that.
I’m definitely experiencing these kinds of drop outs though. Substituting a CV cable for the virtual i2C resolves this so its definitely a similar i2C bus bandwidth issue. Nice to know something was done and i’ll head over to O|D to read up on what (OD) Brian may have sorted there.