why would you do that?
these files are needed to be read to initialise the eigenharps…
I would not want to do this as a separate step!?
kind of the point of EigenLite is to make it easy to connect to Eigenharps, not having to worry about oddities like this two stage initialisation.
also, as I mentioned to David, I do try to keep EigenLite pretty ‘lite’ (hence the name), a thin wrapper around the EigenD code… so to be agnostic in use… using the ihx files was part of this, as this is the way EigenD works.
(the idea was to use MEC as the next layer of abstraction on top of this…)
of course, I could see how we might want to embed the ihx data somehow into the binary,
in that case, sure, then EigenLite could just take a data stream, which would allow it to do the same initialisation.
i.e. don’t remove the initialisation, which I think definitely be in EigenLite, but rather allow it to source the data stream differently…
we could then update the test/demo application to show it using a directory.
one issue here is… depending on which eigenharp you plug in, different data streams (ihx files) are required - so all need to be present.
(again, Im not willing to fix this to pico or a particular basestation, this part should be part of eigenlite)
as for the a separate firmware reader, sure we can add as a utility in EigenLite
(though I thought there was already one in EigenD build?)
note: EigenLite will only use the IHX file IF it needs it, ie. if the harp is already initialised it wont try to use it.
so overall, I’ll take a look…
basically, I think my plan would be … move to using some kind of supplied data stream…
something like
struct {
void* pico_=nullptr;
void* baseMax_=nullptr;
void* baseMini_=nullptr;
} ihxData;
then if the connected eigenharp needs initialisation, then it’ll look for these…
if you leave as null for any of these, that it needs it will fail to initialise.
then I’ll update the test/mec to use a file based implementation.
then I’ll look to add a simple fw initialise app too…
not only will this show how it can be done from a file, but allow the option to initialise separately from eigenlite… though frankly, this is not something Id want to ever do 
btw: be careful with ‘disconnects’… Ive noticed that you can get them when you do not expect them… and EigenLite (like EigenD) will already try to reconnect anyway… so you don’t need them for this.
its kind of why I didnt add the event… as apart from logging the disconnect, I couldn’t see much that you would want to do with it. (and the logger already logs this event)
… but I guess, some apps might want to de-initialise data, and then re-create on reconnection?!
(though I usually just do this in the connection i.e. if already connected - destroy, then re-create)