EigenLite dev work, ideas and discussions

Eigenharp
1

GitHub is nice and all, but I still thought it might be nice to have a dedicated topic for EigenLite.

I’ve been tinkering a bit with it on and off lately. I added “disconnect” events that are sent when a device gets destroyed and made a small PR for it. (I show connection statuses in my UI and as VST output params so for GigPerformer panels.)

I also started thinking that reading ihx files perhaps could be moved out of ef_harp. So I refactored a bit, added a firmware reader interface for file open, read and close + a default implementation that does the same as before. The idea was to move the responsibility of how/where to get the ihx files out of EigenLite by making the application using EigenLite provide a firmware reader to EigenLite. (I use this to read from embedded data instead of files.) Possibly (probably) done clumsily since I’m not actually a C++ developer. But seems to work, at least… It is in this branch at the moment: GitHub - KaiDrange/EigenLite at fwReader

Does this make sense? Should I make a PR for it?

1 Like
2

The goals sound plausible to me. Am not deep enough into the code to judge the diff (e.g. (why) is it a static library now instead of a dynamic one?), @thetechnobear has most certainly the best understanding.

3

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 :wink:

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)

4

Yeah, that is not related and there by accident. Btw, I don’t think it is possible to have everything static linked since (or so I assume) the pico_decoder library isn’t open source and will still need to be included as a dynamic library.

5

That is what I did. Sorry for not being clear. Initialisation, sending the firmware to the harps, etc is still inside EigenLite as before. It is just that a simple “file reader” is provided in the constructor. From an EigenLite user the difference is small. It could just as well be exactly as before if we prefer. Or perhaps two constructors (path or a reader implementation)?

I’m mostly worried about unnecessary complexity. Eigenapi.h getting more cluttered and possibly confusing. And then generally increasing the code base for functionality that isn’t really useful.

I like how the actual data reading is moved out of ef_harp, though. My thinking was to keep the actual validation and processing there (where it belongs), but separate the use-case/platform specific actual data reading. If we scrap the rest it would perhaps still be nice to have that refactoring so that support for other platforms or switch to reading embedded data is easy to add down the line.

Yeah, I added confirmResources() as a “precheck” for the host application thinking an application would probably like to know if everything for all harps is there before trying to initialise EigenLite. Perhaps a variant of that as a static function in eigenapi.h could be nice regardless of the rest?

I made something like as an implementation of the IFW_Reader yesterday. I haven’t commit’ed it anywhere, but iirc:

struct {
  const char* pico_ihx = nullptr;
  int pico_ihxSize = 0;
  int pico_bytesRead = -1;
  ...
} ihxData;

and then a check that all ihx data has proper values and that the data start with a ‘:’

EDIT:

Hah! That took me a while to realize, actually. :smiley: “This worked 2 mins ago, how could it be broken now?!”, while in reality I broke it hours ago and didn’t notice it…

Anyways, keep in mind that I don’t know what I’m doing and do not have any strong opinions. I’m good at my C#/Typescript day job, but that is miles from this. I just enjoy learning the inner workings of EigenLite and experiment and poke at stuff. I perfectly understand if you’d prefer to not have me meddling. Discussing features and/or explaining why something is a bad idea takes time and effort, too. Especially when your focus is elsewhere.

6

yeah. Id not have a file reader… I think a simple data structure with char* and size (per device type) is more flexible. (I forget size in my first reply)
(we dont need ‘bytes read’ thats an implementation detail an should not be part of the public api)

iirc, the base code thats currently being used for file has some error checking in it… so hopefully as long as the data pointer and size are valid, then it can protect itself well enough.

(and as mentioned, we can even allow it to have nullptrs, in case a (dev) user doesn’t care about all eigenharp types)

as you say, could also leave the current constructor (with dir name) to retain compatibility, and ease of use (when you want to use the current file based implementation)

Id need to go take a look at it, but Id think this is all pretty trivial… as its just getting characters from a data stream rather than a file…

I cannot remember the size of the ihx file, but its probably ‘acceptable’ to even read in the whole file, and convert it to a byte stream… so as to use the same implementation both use-cases.

1 Like