#102

I don’t know if investigations have already lead to an yet unpublished improvement on this one - I just noticed that it is the very same with Meadowphysics: Every now and then a command is not executed. Didn’t notice that before since it is not as obvious as with ES.CLOCK or a ES.RESET

So this seems to be more of an issue with Teletype then with Earthsea?

#103

that’s a good call, probably teletype.

have you tried the newest newest tt firmware? it has a new i2c handling system, so perhaps that either fixed or broke the issue at hand

https://github.com/monome/teletype/issues/55

#104

Yes, I updated all modules when I was at it with Ansible (about 2 weeks ago).

Teletype says 1.2.

Not sure if it is possible to read the firmware version of the other modules somehow but the update procedure seemed to be successful. Shall I try again?

#105

ok, so i’ve updated ES to buffer II data and then process it in the event loop.

i’m not necessarily expecting an improvement as i’m starting to suspect it’s a TT issue, dropping packets possibly.

here it is anyway, an intermediary update.

es-1.9-1.zip (45.6 KB)

it’s at line 543 now (probably the same line you pointed out):

if(x<0) x = 0;
else if(x>15) x=15;
if(y<0) y = 0;
else if(y>7) y=7;

i can’t see anything wrong with that. and i’ve had a very hard time replicating the failure with ES.TRANS. any tips on making it crash?

#106

Yep, that’s an easy script

ii es.trans x
x add x 1

with a running loop started on earthsea - than just wait until x goes over the top row in earthsea and both are deep frozen.

#107

clamping fixed. was an issue with trying to update a non-existent LED on the grid and hosing memory

here’s an intermediary release

es-1.9-2.zip (45.6 KB)

4 Likes
#108

Yes, seems so - still drop outs from teletype using clock as well as reset plus I have had them on MP from too trying tt-remote.

Clamping does work good now though!

:slight_smile:

#109

I just had a few freezing experiences on the new earthsea firmware either when hotplugging the grid while in tt clock mode (4 times, plugging in or out does not matter) or when typing es.mode 1 on tt with the grid plugged in (1 time) it also stutters when plugging the grid in while clocked from tt.

#110

@tehn I just did a short test with the former firmware es-1 with the same effect: plugging/unplugging the grid when in clock remote mode leads to not recognizing the grid after a few trials. Sometimes, not always, it is still running and accepting commands from tt though.

#111

…therefore I cannot break it anymore by transposing over the grid range - maybe it is not possible to downgrade? I might better leave it as I don’t understand those things.

#112

I could not stop it and noticed that there is a pattern in a part of this behavior.

I clocked ES from tt and every 6 minutes apart from the occasional missing single shots the clocking totally breaks down for a short moment as in this snippet:

Just in case this helps somehow to figure it out.

Ansible 1.3.0 - ii for kria/mp/levels/cycles
#113

@tehn

The actual eartsea firmware presented on the i2c debugging thread is called 1.9.0 and it does the clamping freeze again while the one above, that fixed it seems to be called 1.9-2.

Could it be that something went wrong here?

#114

no, just bad version management. 1.9.2 etc were betas, hastily posted to this thread.

#115

Ah, I understand - so there is a chance to get the clamping fix in the main firmware too?

#116

clamping fix is in the newest firmware. it’s just a version mislabelling for these thread posts.

#117

Hm, but it does not work…
:confused:

#118

I wonder if there is any news on the left Esrthsea remote bugs (clamping/slow down)?

#119

so i just had a little patch / scene going with ES in TT clock mode. running one pattern on a lively, but not terribly fast clock for around 20 minutes. every now and then i’d notice ES holding a note a little longer than normal. didn’t happen very often and didn’t really bother me as i enjoy the variation :slight_smile:

then TT and ES locked up. i switched the grid over to MP and it wasn’t giving any led feedback (they’re all on the i2c bus). rebooted the case and TT remained blank. another restart - this time with a longer wait & i also disconnected the MP trig that was pinging the TT / ES clock script.

back to life!

so i reconnected MP to the TT/ES clock and it started back up. but in less than a minute it locked up again.

retried this a few times and it’s consistently locking up within a minute.

that’s my bug report!

////////

side note / question: i noticed ES clocking requires two pulses to advance to the next note. is this the normal, intended behavior? i found that it made my MP patterns lose their vibe, so i set up the TT clock script like so:

II ES.CLOCK 1
DEL 10 : II ES CLOCK 1

could this be contributing to the bug? i’m also curious to learn of the functional advantages that might come from 2 pulses per note advance vs 1.

#120

The double clocking is normal behavior. I understood it as following the open time frame of Eartsea where pauses between the single notes are an event also. And every cöock triggers an event. Simply sending a double clock per script helps to get straigjt and im time sequencing.

I am experiencing the occasional reconnevting freeze up too.

#121

yeah that was my thinking too. but then, isn’t an external sequencer/clock source already defining the time between notes? also could the double clock script be to blame for locking up the i2c bus?

i tried my same setup again this morning and it ran for 30mins without locking… sooo…??