Got a chance to test again tonight. Grid and OP-1 work fine after a reflash. QN still nukes the ES until the firmware is flashed.

Anything else that I should try?

Out of curiosity do you have a USB MIDI converter?

If so I’d be curious to know if the same problem occurs when you have the QN driving the ES indirectly via an intermediate pair of midi interfaces. I’m wondering if the QN generates more midi data than the ES can process (with the current timer configuration).

Given that you say you have to re flash the ES in order to get it working I’m also wondering if it is possible that the last note priority queue is overflowing and somehow corrupting memory.

As I mentioned in another thread if you could record a few seconds of midi data which would typically lockup the ES and send it to me (pm here is fine) I can try to reproduce the problem (and fix it if I can reproduce it).

I had another issue tonight. I was simply playing the Earthsea like a keyboard using a Grids (not recording arps or anything).

Occasionally, the “Edge” output would get stuck in an on state (so note on triggers wouldn’t fire). After about a minute, it would wake back up, but with massive slow down. Notes would trigger half a second late or clump together in weird groups. Finally, the Edge output got stuck again and wouldn’t seem to un-trigger.

I have seen this behavior on mine quite a long time ago. Do you have it connected to TT?

Yes. TT wasn’t controlling anything in the patch, but it is connected by ribbon. It was just hanging out and running the Triangle Mountain preset.

I am trying to transpose an arp on the ES from TT but both of them constantly freeze when the ES.TRANS parameter accidentally gets ES over an upper limit (which seems to be the first row of the grid).

Is it supposed to be like that? And what exactly is the upper limit for the ii parameters? I did not find something about that by now in the manuals.

BTW ES.CLOCK is still not working on mine…always skips single clock pulses…:joy_cat:

should be an easy fix

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

but i have an idea about this should be more generally fixed up.

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

of course, my code todo list is piling up…

1 Like

I have experienced this multiple times in the past.
Perhaps the issue persists, but I have given up on TT controlling ES partly because of this.
Would love to see a stabile ES/TT dialogue.

Having said that I have had my own insane issues with TT control in general, so this could have been related to other things?

Have a couple of hours to kill tomorrow. Might take a look at that.

value clamping should be one-liner easy. buffering is a little more involved-- i recently added i2c handling into the event loop for teletype, so at least there’s a model (although, tt is handling outgoing i2c in an event, not incoming).

yes, inexplicably. can you point to the other issue threads so i can use them as markers for debugging?

oh, hmmm, i will try to dig it out.
though a lot of it we communicated about directly, I think?

Oh…

Talking to ES was what eventually has made me getting TT cause I was afraid of the coding part before. And indeed I am struggling a bit with the syntax so I always need a lot of free time to dig into it, go through the manual and studies to find a way to work out what I planned (not that much complex stuff).
So yes, would be really great to have it stable - thanks a lot for looking at it!

:slight_smile:

How is the dialogue with Orca and MP then?

this is to say-- these features work perfectly on my system. so you may have no trouble.

The ES code is a little harder to grok than the WW. Am I right in thinking that the ES.TRANS parameter gets split into x,y offsets that get added to the current root position, with currently -4<x<4 & -6553<y<6553.

I know there’s already clamping in the manual transposition, but can’t seem to locate this in the code. A pointer would help!

Ah, is that it at line 532?

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.

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.

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?

i’ll investigate clocking consistency when i refactor the ii buffering

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