#96

Ah, is that it at line 532?

#97

Unfortunately I donā€™t have the ability to help cause my personal coding experience stopped back in the 80ā€™s on a very, err, BASIC level but I wonder if there is any news on this.

#98

Not from me. Ive been away for the last week and while Iā€™ve had a chance to look at the code, Iā€™m some way for making the fix for the value clamping (I definitely donā€™t understand it well enough yet to tackle the buffering). I also need to get the soldering iron out before I can test anything.

#99

I see that fixing the teletype clock issue takes some time so I worked with es.reset some time now (itā€™s closer to the spirit of earthsea anyway) and noticed that even I use a way less busy frequency as for the clocking it skips events - meaning not every trigger going into teletype does reset and play a pattern on earthsea.

Or is this what everyone means by ā€œbufferingā€ that simply not every teletype command is being executed?

#100

iā€™ll investigate clocking consistency when i refactor the ii buffering

https://github.com/monome/earthsea/issues/10

#101

Great, Thanks! Remote is a little inconsistent to use as it is now. Firing off the slightly irregular Earthsea patterns on point would be so awesome! :grinning:

#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?