Some future Eigenharp software thoughts/fantasies

I feel guilty for not having contributed with a single line of code to neither EigenD or MEC. I’m very grateful for all the work Mark has put into those two projects. Without actually doing anything to help out, I sometimes think of what I would have liked to contribute with if I got around to it.

The following is how I imagine I’d want my Eigenharp software to work. Without suggesting I will actually start working on this (or that someone else should!), does the following even sound useful to the rest of you? Asking mostly out of curiosity, really.

Anyways, basic idea is to split the software in two. “Core” and “Mapper”, for instance.

A low level, barebones, “stupid” piece of software based on EigenLite and stealing stuff from MEC intended to start on bootup and always run in the background. Its job would be to connect to the harps on the hardware side and communicate with the Mapper software on the other. I imagine this as something most users would install and the forget is even there. Something with as little functionality and dependencies as possible, really.

Software that could run standalone or as a plugin that would transform the raw data from Core into something musically useful and output that as midi data. Splits, scales, lights, expression curves, etc for all three types models should be configurable and saveable as presets.

No idea how Core and Mapper should communicate. Midi 2.0 or OSC perhaps? Via ethernet?

In my head, there are several benefits of this split. I believe it would make it easier for multiple developers to contribute. Getting Core to run on all sorts of devices or keep that up to date on new OSes is a very different skillset to making a, say, dedicated Eigenharp step sequencer for the Pico in Max.

To me it makes sense to separate what every Eigenharpist will need, always, regardless of their use-case from the opiniated stuff. Perhaps someone would want to create something in Max, someone else something on a rPI, while a GigPerformer user would probably want a different configuration per song (possibly even per Eigenharp model!) of a live set.

Then there is reliability. I’m not sure if this holds true, but I would guess it is safer to let the Eigenharps always stay connected to the device running Core. I.e. if my computer boots up and my Eigenharps connects, then I can trust they will continue to behave until the computer shuts down, regardless of how the mapping from raw data to midi changes back and forth mid-performance.

Edit: future-proofing. If Core runs fine on, say, an rPI today and I can receive raw data from that to a laptop, then I could keep that PI as is for all future and worry less about how new Mac OS updates etc. will affect my beloved instruments.

In my ignorance, I imagine I could take some baby steps towards this without too much work if I use MEC as a starting point, send OSC data from that, and then make a simple VST plugin that converts the OSC data to midi. On a Mac.


not quite sure, I see the advantage of spitting out core and mapper…
why run two things, when you can run one?

I think many ‘wished’ that the Eigenharp just put out midi … so thats kind of where I went with MEC.

I can see it being nice to do Mapper in a higher level language - Im not sure many could really deal with the amount of data, unless its in C++.
also Id worry about performance if you start doing things in many processes…
core → mapper → daw/sound engine
each leap, is going to cost you in latency !

in terms of mec vs core…
I guess the main difference is mec does ‘voicing’ … before it puts out osc.
the reason for this is midi , and also since t3d osc is also voiced.

anyway, all this is pretty straight forward,
I guess I could put a ‘test program’ in EigenLite that just spits out osc , and took leds via osc.

in general, MEC, Ive at some point gotta rationalise a few things in it.
… I started added other bits to it, which are interesting to build a full control system - but at the moments, theres quite a few disconnected things.
I really need to tidy it up - and work out where to take it.

but I agree, I do need to come back and look at this.
the Apple M1, really has thrown a bit of a cat amount the pigeons for EigenD.
so Id like to get something thats more workable…

Moved from EigenD - Apple Silicon - #11 by thetechnobear

Question to judge which effort would be justified might be: Assuming we’d have a blank slate, which software would people want?

For me personally the answer to this question would be very different depending on which point in time I would have been asked. Initially I liked the no-assumptions approach of EigenD a lot, because my vision of how to use the Eigenharp differed in many ways from what was envisioned in the default setups. So I was glad that I could customize everything down to the last bolt.
Nowadays I think I know what I want from an Eigenharp and am happy with the setup I have - which can be done with EigenD and also with MEC - but I’d be happy with anything that can do that - the less error prone the better.
Reducing the complexity by reducing the flexibility would impose some usage patterns on people. So question might be: Can we settle on something that most are happy with?

Problem might be, it is always harder to take something away - if the default setup would have been hardcoded or even part of the firmware, then I would probably use it like that, am not ripping keys out of my piano either even though the layout isn’t optimal.

But would be interesting which stance others would have on this.


yeah, this is something Ive struggled with a bit on mec…

(in fairness, this is typical with software aka feature creep)

MEC started out aimed at being very simple…
based on comments on the past, that were along the lines of
‘I wish the Eigenharp was just a usb midi compliant instrument’

that simplicity is really appealing.

for OSC this can be done… as there are no technical limitations (except increased latency/jitter)

for MIDI , its more complex :slight_smile:

midi complications

if we consider the Alpha we cannot ‘just’ output the raw data of 132 keys with 3 dimensions. in any usable form in midi . (even if we could we’d reduce resolution from 10 bit to 7bit!)

the only way to do it is to voice the data (as any mpe device does) using MPE (or similar)

BUT voicing immediately creates an assumption about layout…
on everything except the alpha you could use a linear layout, but the alpha has too many keys for this!
even then, a linear layout implies you then need to start remapping the keys - but thats a pain in alot of software (e.g. daw) - so hence i support layouts of different configs.

from there (and when I got stuck a bit), it soon became apparent, I want to be able to split the surface…
but as soon as you do that, that then means that one part of the surface, needs to go to one device, and another split to another device.

… then if MEC is running in the background, I want to be able to alter these splits on the fly? (like EigenD keygroups)

as you can see, it starts out simple - but gets increasingly more complicated!
(and I’d say these are pretty basic functions)

this is where Im really trying to decide which way to go,
this increasing complexity concerns me… it kind of moves away from the original goal of simplicity.
it makes the configuration much more difficult, and also bakes in what is possible and what is not (to some extent)

however on the flipside, I want a solution that is usable by all users ‘out of the box’…
not something that requires you to start writing code :slight_smile:

core and mapper - diversify development…

perhaps as @Kai points out, splitting it up a little into Core/Mapper might be a way , so that I can focus on Core and others can build various mappers.

also its pretty close to what we have already EigenLite=Core vs MEC=Mapper

but this is only useful if it gets used, I dont want to be supporting another ‘thing’ , if its not really going to used by the community - but I do see the idea having potential, if others can build mapping layers that others can use.

my only concern (which I mentioned above) is performance - if I create ‘core’ to output and accept osc that is pretty raw - and others produce mappers in higher level languages (*) will it be usable.
lets imagine a core (osc) → mapper(python) (midi mpe) → daw

will this latency be acceptable? (**)

someone could test this already today…
MEC already produces OSC (t3d), albeit its voiced - you could try writing a mapper process (in python or whatever) to map this to midi and see, if its acceptable - as a kind of proof of concept.

(*) I think these will be higher level languages, as I think C++ in MEC, is still a barrier for others to contribute - its not just skill set, its also just requires more commiment/time to code in C++.

(**) lets remember for a sec, even eigend/mec → midi → daw, was against eigenlab principles., the idea of hosting the VST within EigenD, was tso we didnt have this interprocess jump!


My understanding is that localhost communication is quite fast (using memory buffers, cutting away all the lower layers) - so OSC might be an option. Perhaps optimally there could be
a) a C++ library that wraps all the communication with the Eigenharp
b) a kind-of-microservice that exposes all/most of the functionality via e.g. OSC

That way one wouldn’t need to go over the service when implementing a VST/Audiounit that e.g. provides a graphical layout mapper and midi mapper with the ability to store presets.

Question to Max/Pd experts: Would such a OSC-based service be considered helpful or would a Max/Pd user rather wrap this into a native external anyways? In the latter case: For which scenarios would the service be used?

Edit: For writing clients in other languages where directly embedding C++ is cumbersome it might be helpful. Or to add intermediate preprocessing modules on the native message level. But then one would need an orchestration environment to start and stop things, maintain different presets etc. (Something along the lines of KXStudio: KXStudio : Applications). If we go that route it might be good if this is an expert option, not the default? Or we would at least need a very straightforward user interface for orchestrating these services?

But before doing all this it might be helpful to collect some scenarios how people are actually using their Eigenharps. Are most just using the default setups that come with EigenD unaltered? And in the case of custom setups or customizations, in which direction are these going? Layouts? Plugins? Freestyle-change-everything?

Have started a questionaire about EigenD usage in this thread: Questionaise: Please describe your Eigenharp setup


Would it be useful if I made a configuration/mapper application thing that as a start is just a UI and not much else? Basically a first suggestion for a set of features as seen from the end-user perspective?

If we think it seems like something worth continuing on, then it could either evolve to be a UI for MEC, a separate MEC-config-creator tool or perhaps the start of some mapper-type of plugin?

It wouldn’t be much effort for me to make something like this as a web application. But C++ and JUCE would probably be more useable down the line. Sounds fun to do, so if it could be useful I’ll gladly give it a go.

I cannot (at the moment) spare time in this area, just too many projects on the go at the moment (let alone other ideas for new projects.

what I like about your Core/Mapper idea, is the potential for others to get involved.
if others can implement mappers - then that could be an interesting way forward.

but unfortunately, thats not just UI… its also the underlying code to do this mapping to something useful.

Id say my experience with open source, is really its not driven by ‘user requirements’ , bad as that may be - rather, its driven by someone who has a need themselves, and codes for that need… in the hope that its useable by others in the community - I guess, its this way because unlike commecial software, developers are not employees - so they are not a ‘resource’ for product development.

The intent would of course be to eventually make either a working application or useful contribution to MEC, not just a UI and then expect you or someone else to implement it! :slight_smile:

I was considering what NothanUmber said about complexity/flexibility and how to settle on something that most would find useful. My current sense of requirements are based on a sample size of 1, so I was thinking a UI and then some feedback could be the first baby steps forward. Hmm. I’ll give it a thought, at least.


A post was split to a new topic: EigenharpMapper