WW/MP/ES teletype updates

Just for the record: I was able to reproduce this again by following the above steps.
The only difference between now and the above run was that this time, the first pattern I made did not exhibit the slow down. So I selected the second pattern slot, and did the above steps (linearize, accelerate a step or two, transpose a few times, and then let it play for a couple of minutes). Slow down and grid not-responsiveness occurred within less than a minute.

@ether @mrdave1981 @greenanother how about you?
Did you update?
Do you still see the slowdown/freeze issue?

BTW @tehn I am also pretty sure that @Galapagoose mentioned that he had seen this issue as well.

thanks for the update, will test!

Well, I wish this was not the case, BUT:

I went ahead and connected ES with newest firmware to the TT and the rst of trilogy. I initiated the factory scene for ES control, and changed one line to control transposition with the PARAM knob as follows:

X RSH PARAM 10
II ES.TRANS X

and connected a slow clock to input 5 to trigger the script.
Teletype froze immediately.
I could still control ES manually from the grid, but TT is frozen. And, as I type this message the Earthsea exhibits the slowdown symptom once more…

Again: wish the news was better, but I am afraid the firmware update did not really fix the problems I had with ES and TT implementation.

EDIT:

After further testing. TT freezes every time I send a trigger to various inputs that are supposed to control ES via teh factory scene. No changes to the code needed. TT works fine until I plug a cable in one of the inputs, and send it a trigger, which has no effect on ES, but freezes TT. This is totally repeatable on my system.

EDIT 2:

After disconnecting ES from TT and power cycling the case, I have selected a different scene on TT, which froze when I hit the TAB key. Aftr power cycling the case Teletype does not start up at all: black screen after multiple power cycles.
It’s weird: as if though it got “infected” through the ES connection???

In any case it is bricked now.

@laborcamp Sorry for the late reply (and sorry to hear about the current situation). I haven’t updated my ES, and don’t plan to until the problem is fully resolved. I’m confident that @tehn will eventually replicate the slow-down issue and resolve this. Until then, I’m going to take the measures I outlined previously to avoid crashes/freeze ups. @laborcamp please keep us updated with your TT situation, and anything else you uncover.

@tehn and @ether Glad to hear it! Hope this implies that there will be extra faceplates ordered for current owners that would like to swap out their existing faceplates for a reasonable fee?

edit: sorry, I didn’t reply to this as a linked topic (still learning to navigate)

@laborcamp haven’t updated mine yet - after reading the posts below it appears like the issue persists anyway.

@tehn good to know. I might have to order a 2nd MP for hacking purposes, and to help lower your stock.

ok i’ll be looking into the slowdown.

note that other bugs were solidly corrected!

@tehn Do you think that whatever causes the slowdown on ES is also causing the TT crashes? Or are these issues unrelated, based on your expertise?

@tehn by the way, thanks!

Yes, @tehn, thank you! Maybe I will try updating after all.

I was hoping that after few power cycles and some time, my Teletype would eventually wake up, but it didn’t.
Finaly I was able to de-brick it by re-fashing the firmware.
However, that erased all my scenes in the process.
(At least I am back up and runing!)

@laborcamp Good to hear that you’re back in the game! I finally got a chance to update ES to 1.7 and many of the bugs were indeed corrected, so thank you @tehn for that (and for putting up with my incessant emails/brain-storming).

I have; unfortunately, just experienced what I am now dubbing the “walk-away” freeze. That is: when I’ve been using the grid with ES and then go for periods of a bout 10-15 min. without touching the grid or knobs on ES (while working with other modules or just walking away to answer the phone), I come back to a frozen grid. If I then press a few buttons on the grid and wait about 5 min. or so, the grid becomes responsive again. Pressing the grid buttons over and over does nothing to release the grid from this frozen state (only waiting thereafter).

I wonder if this is somehow related to the slow-down issue or that it actually IS the slow-down issue, and the only reason I’m not always seeing it slow down to a frozen state is because I’m not playing the grid when it (the slow-down to a freeze) happens. Any thoughts on this from the community would be appreciated. I have no experience with coding, but empirically it feels like some kind of timing macro (which explains why perceptually it seemed like a powerbus issue to me/others initially).

i suspect the slow-down issue is related to the unresponsive grid issue.

i’ll take a look at the timing structures-- i suspect that changing the polling rates for a few different timers will solve the issue.

it seems like the slowdown issues in ES could cause some TT crashing, though it seems difficult to imagine. if ES is hanging somehow, TT should abort the II transfer.

do you get TT crashes arbitrarily when connected to ES without using the II command? i’m unfortunately reaching a point of data overload when it comes to bug reporting. i’ll start doing a better job logging issues into github.

edit: added issue here:

feel free to add information on the issue directly. i’m hoping to solve the ES issue before tackling a new revision of TT.

@greenanother What you are describing is the slowdown issue. I have now seen it many times and it always works out the same way. The patterns begins to slow down, grid becomes totally unresponsive, eventually grid freezes completely, the whole thing seems frozen, but eventually it accelerates back up. I think most of the time it does not quite reach back the proper speed though.

In any case: you are experiencing exact same thing I see in my setup.

After several instances I think that the TT crashes happen when it receives the trigger that executes a script with a II command.

Up till yesterday it was always related (in my case) to ES being connected.

But yesterday this happened when I tried using WW II command (sent you a PM with that), so that changed the picture a bit from my vantage point as not just ES problem, but something that has to do with the II functionality.

Ok @laborcamp looks like we’re getting warmer. I believe @tehn will get to the bottom of this. I accept that these issues will come up when there are so many variables involved (with devices that do things no other device can). I’m just glad the issues aren’t power related.

1 Like

ok-- i have frustrating news. i simply cannot reproduce the “slow-down” issue. my steps:

  • cold start modular
  • ES record pattern, turn on transpose, play it
  • TT load ES REMOTE scene
  • turn PARAM knob, hit WIN-6 to execute, works fine
  • add patch to TT input 6, works fine
  • tweak everything possible in an attempt to crash, still working. triple shape triggering with tons of slew while II messaging CLOCK and TRANS, really!

can i see a method for consistent crash/slowdown behavior? there’s nothing special about my hardware-- it’s the same batch that we send out to everyone else.

please post to this new thread: