Haven’t tried to reach John lately, thus don’t know about his availability.
Did you hear back from Wayne Nelson, the Eigenlabs technician mentioned in the linked thread?
Nope, never did. I did get through to Mark Rigamonti (he did the mechanical design) at a newer email but he didn’t have any info either. He said he’d also try to contact Wayne and get back to me but I never heard back. That was nearly 2 years ago.
Not only is eigenlabs.com down again but so is johnhenrylambert.com (hence the internet archive link above).
ok 
Fingers crossed that everything is ok!
The Eigenlabs website and John’s homepage are back up! 
1 Like
eingenlabs is down again, been trying to access the site to get the tutorials on how to work with workbench and locanto if anyone has that info id be happy lol.
Keep trying, it seems to wink in and out of existence regularly. Next time it’s up I’d recommend downloading everything you think you’ll need.
@thetechnobear how sure are we that the Alpha/Tau don’t support reading the calibration? Looking at lib_alpha2/alpha2_usb.h, there is a hole between
#define BCTKBD_USBCOMMAND_CALWRITE_REQ 0xb6
and
#define BCTKBD_USBCOMMAND_CALCLEAR_REQ 0xb8
that is exactly where you’d expect to find the 0xb7 read command that is in lib_pico/pico_usb.h.
(Actually @gbevin might know also, I see commits from him in the Pico firmware binary.)
If it is there, it would be theoretically possible to write a recalibration tool that could be used to save the existing calibration to a backup, and make relative adjustments to a particular key through trial and error (or restore from the backup if needed). I could really use that to fix the bad key on mine, since I never got any responses from Eigenlabs about servicing.
-Josh
reading the calibration data is not the issue…
iirc, we actually have some info on this side, including some hints in the source code of how this might be stored…
but none of it is really enough, as we have no information on the calibration process (either mechanical or software side)
Im sure we some hacking we could get “something”, but there would be a risk of corrupting calibration data to the point of non-recovery, making the device unusable.
so, its just not worth the risk… ‘dabbling’ with it whilst knowing we are to some extent grasping at straws.
thats just my opinion, having looked at all the code that existing in the repo related to calibration, including the few ‘tools’ that exist.
(afaik, Geert worked on EigenD only, not the firmware, which we dont even have source for… so not quite sure what you mean)
I was referring to e.g. this commit on the Pico firmware itself, can’t see how he would have done that except by building the firmware from sources:
It’s a binary commit from those that develop the firmware, it’s just being stored in repo … as that’s the way the eigenharp software is shipped.
I know the firmware was done ‘externally’ , as I discussed this with Jim ( the principle dev for Eigenharp) when talking about firmware support for midi for the basestation ( used by Alpha and Tau)
Afaik, It’s pretty specialize hardware on the instruments themselves , not something a non specialist has skills or tools to write.
This doesn’t actually matter … as the firmware is only for the low level protocol, so 99.9% functionality we see is within the Eigend code base running on your computer.
But that does mean, if the read ‘op-code’ is not present, then we have no access to data.
But as I said , even if it does … that’s not the main issue.
the pico does have the read op. code, and it was still unclear what’s exactly there eg we only have a vague idea what that data stream format actually is.
But again, I’m not saying impossible … if i spent alot of time on it, I’m sure I’d could get a little further - but doesn’t feel worth it ( to me!)
the fried chip was named BBQ? it is the sacrificial lamb of the board, amazing.