ECMapper - a light-weight alternative to the official EigenD software for MacOS

[Kai]

I have started working on something. GitHub - KaiDrange/ECMapper: Two applications for the EigenLabs Eigenharp instruments. The console app "EigenCore" reads data from the Eigenharps and then transmits that data via OSC. The standalone/VST/AU application "ECMapper" receives the OSC data and converts it to midi as configured in the UI.

A VST3/AU/Standalone Juce application. So far just the UI and saving/loading the layouts as XML. So not really that interesting yet.

I’ve experimented with sending/receiving OSC and generating MIDI, so I think I know how to do that part. However, I tried to make an app using EigenLite by looking at MEC and doing some cargo cult programming, but that didn’t go too well.

So, I think the plan now is to dig into the details of MEC to try to learn what needs to be done from here.

@thetechnobear I currently believe I should learn how MEC creates the MecMsg objects and then send something like that via OSC. And then look at your mec_midi_processor/mec_mpe_processor on how to convert those messages to midi on the receiving end. Does that sound about right?

[thetechnobear]

cool , I’ve taken the liberty of moving this to its open topic…
I think it deserves it, and also ‘development’ discussions tend to ramble on a bit

(feel free to rename it, if you wish)

---

@Kai

I tried to make an app using EigenLite by looking at MEC and doing some cargo cult programming, but that didn’t go too well.

hmm, thats surprising, really there is not much to using EigenLite…

I was going to explain here…but realised I was typing alot… thats possibly useful to others.

so decided to add to the EigenApi repo instead as a wiki

Home

it was rather ‘thrown together’ and frankly, Im not the best person to explain (given I know how all this works already )

Ive made the wiki ‘public’ editable, so if you see anything wrong, or find that something needs more explanation then please feel free to edit.

really, I should separate out bit of the api into different pages… but i kind of ran out of time

anyway hope this helps.

[thetechnobear]

part 2

ok, so another approach… would to be not to use EigenLite (directly) instead to use MEC.

I admit this doesn’t buy you too much, unless you start wanting to get into note handling i.e. voices, which can be a bit tricky. ( e.g. handling velocitities, note stealing)

if you are interested in this side, then perhaps its better to use MEC, since we can collaborate in this area … it does most things, but there are areas it still needs work on.
and so makes sense to do that together
the key here is MEC is not just the app it has an ‘api’ , so you may find that layer easier to use.

HOWEVER, I recognise, often its easier to work on your own code that someone elses.

to this end, you’ll see in MEC, I actually also developed a VST

TheTechnobear/MEC

this one is quite amusing, I was doing something very ‘different’
what this vst does, is actually HOST another vst, which it then feeds eigenharp events through to directly.

the reason I was doing this, was at the time no HOST supported MPE, so the idea was you could basically use any VST as an eigenharp instrument in any DAW.

that said, its been quite a while since I tried it… but I think it should still be doing something?

I really must update it… as I do still like this idea …
Ive been creating alot of VSTs for Percussa SSP, so my VST experience is vastly improved now … so Im sure I could really do a nice job on this now

anyway other point being, this is a demostration of using the MEC api inside a VST.

hmm, makes me wonder… does any host support the concept of vst midi fx generating mpe midi?
I guess they dont care?
my concern here is some hosts (ableton!) may well strip channel off of midi from a vst?!

anyway, back to coding, ive 4 (!) new plugins im trying to finish for the Percussa SSP!

[Kai]

@thetechnobear

so decided to add to the EigenApi repo instead as a wiki

Sweet, got it working easily now, so that was very useful! Not sure what I got wrong the first time around, but when everything is new and confusing (including XCode, Juce and even MacOs (!)) this helped me narrow down what to do.

@thetechnobear

if you are interested in this side, then perhaps its better to use MEC, since we can collaborate in this area … it does most things, but there are areas it still needs work on.
and so makes sense to do that together
the key here is MEC is not just the app it has an ‘api’ , so you may find that layer easier to use.

HOWEVER, I recognise, often its easier to work on your own code that someone elses.

Making EigenharpMapper (I need to come up with a proper name, btw ) is a nice learning exercise. I’m likely to do some very silly, inefficient stuff here and there. So until I know what I’m doing it is probably best to keep this project “heavily inspired by MEC”, but separate. And then see if some of it can be useful for MEC down the line.

@thetechnobear

hmm, makes me wonder… does any host support the concept of vst midi fx generating mpe midi?
I guess they dont care?

my concern here is some hosts (ableton!) may well strip channel off of midi from a vst?!

Hmm, good point. As long as Mapper works both in GigPerformer and standalone I’m happy. As for DAWs, it will probably be a bit of hit and miss. I’m a Cubase user, so I guess I could do a quick test there.

The most serious hurdle so far is that while both AU and VST3 support more than 16 midi channels output (i.e. more than one “device”), Juce does not. I would have liked three separate outs in GigPerformer, one for each zone. I can think of several workarounds, but it is isn’t going to be as elegant as what I had imagined.

@thetechnobear

this one is quite amusing, I was doing something very ‘different’
what this vst does, is actually HOST another vst, which it then feeds eigenharp events through to directly.

I quite like that idea as well. From a musician perspective having layout and sound source(s) bundled together as a “preset” within the DAW of choice makes a lot of sense. For Tau and Alpha, people would probably want to host 2 or 3 plugins? Perhaps combining the layout stuff from Mapper with the mec-vst could be a plan eventually?

[thetechnobear]

yeah I think there are all sorts of different combos that could work.

I will say the ‘mapping’ whilst it seems simple intially, opens up a huge can of worms.
Id recommend you think carefully about it in advance…

when I looked at this the first time, I tried to simplify by just having a simple key to note mapping.

however, once you mess with this, you will quickly see why EigenD has both physical mapping and musical mapping, and they are different things.
this mainly related to partitioning the surface aka splits

the thing is on a piano-like keyboard we do splits using musical notes.
but this is only possible because its a linear layout, that happens to match the physical layout.

as soon as you start using isomorphic layout that approach to splits goes completely out of the window,
and instead you need to have a physical view and a musical view.
you also for the leds, need to have these views work bi-directional.

I realised this whilst doing whilst doing the surface mapper, but ran out of motivation to start making the necessary changes.

I do want to finish this off , as its pretty interesting…
i generally quite like the approach Ive taken, which is to map the keys as a ‘surface’, and then you can sub-divide that surface into another surface… then at some point that surface can (optionally?) be mapped to a musical layout.
( I also had a neat element where you could combine surfaces… e.g. from two different devices)

in fairness, when Iooked back at what i’d done , it was pretty much an EigenD Keygroup, just called surface…
so… upshot is… look at keygroups, you will find their mapping strategy is pretty much the way to do both musical and physical mapping (or like me, ignore them , and then re-invent them )

not quite sure where im going with this at the moment.
I still like the idea of using a rPI4 or similar as a headless device, to turn the Eigenharp into a standalone instrument … that i just plug into my midi router, and play whatever is on the network.
thats kind of why I moved away from the vst idea, and also any kind of GUI.
(but you can see, the vst was similar - a way for the eigenharp to be seen as a musical instrument, rather than a controller?!)

anyway, good to see someone else come up with some ideas.
I think there are lots of different ways you can integrate the eigenharp , so its nice to have options.

[NothanUmber]

Good points! As somebody who rarely uses splits or non-chromatic scales - do the guys who do use them usually change splits and scales on the go in so diverse ways that the amount of permutations would explode? Or would it be viable to “just” have a combined physical+musical layout where one assigns absolute pitches to keys. So one would have e.g. a “4 notes vertical, no split, chromatic” layout or a “4 notes vertical, split at row 5, major” layout. And then the only transformation available would be transposition (each note +/- X semitones).
Would be enough for me but as said, I’m a no split, only chromatic player anyways

[thetechnobear]

like you, i only ever use chromatic scale…

so actually for a while, Ive been using the Alpha without splits.

but I have to say, when I do put splits into place it is alot of fun - quite nice to have a pad sound on the top half of the alpha, and then a lead at the bottom

so what I need from splits is, the ability to target different instruments (midi ports) and also sometimes to transpose - mainly octaves.

perhaps a not so obvious example of this is the percussion keys on the alpha and tau.
these usually have to be mapped separately if you are going to use them for percussion
also, they are really handy to have as ‘mode keys’ e.g. say a metronome/transport, but that implies potentially some kind of feedback.

the other thing to bare in mind is
a) mode keys often need to be handled differently
b) the tau is not rectangular, which makes it a bit of a pain to map.
(as I mentioned previously my calculated notes, works really nicely for for pico and alpha, but breaks with the tau)

I’d ideally like to switch splits on the fly (and then target different instruments) , but for me thats probably only from a pre-defined selection - i could probably even switch via midi (e.g. send program change to ‘eigenharp’)

finally, I think most needs to use the leds to give some ‘reference’ points even in musical layouts, even if its just tonics.

unfortunately, that leads into the next ‘layer’ on top of surfaces - scales!
for chromatic layouts its pretty easy, its mainly just offsetting columns (reversing rows/columns is also useful) , but scales means missing out notes.

In many ways I think adding scales is actually a pretty useful function for this mapping layer.
and as long as you retain, physical mapping as well… its doesnt really complicate things much.

one simplication that I think can work is that whilst, the physical mapping, needs to split down the surface in pretty flexible ways - i think the musical mapping always comes at the end, and you only even do it once.
potential this means you can simplfy to
hardware mapping → N x physical mappings → (optional) musical mapping for each physical map.

(the reason I wanted layers of physical maps was actually to allow combining across hardware surfaces, but its probably a bit overkill)

but as I say, I only come at this from the angle that I underestimated this all when I started out with MEC - Id hope to avoid alot of this, with the idea the Eigenharp would be ‘dumb’ and you could map within your daw/host - but the more I used it, the more I found mapping is really handy.

[Kai]

With Core and the communication between Core and Mapper done for now, having to deal with mapping hardware to notes is coming up on the horizon. My plan was to ignore scales, splits, tonics, etc. Just a physical key → midi note #, LED colour and “Zone”. Where a zone is basically a static split with its own configuration (ref. the right side of the screenshot). If someone wants a D minor scale accordion layout it shouldn’t be a problem, setting it up is just something they will have to do manually per key. The layout can be saved and loaded without changing the entire preset. I was thinking I could include some common layouts/scales to get people started, and then they could easily make/share their own.

…but, I intend to make it so one can configure specific keys to load specific layouts. So that switching back and forth between various layouts mid-performance would still be possible.

Sounds like there will be “gotchas” I haven’t thought of yet, but I hope the general idea will be flexible and easy for people to grasp. A bit cumbersome to set up, perhaps, but not THAT bad. It takes me probably around 5 minutes to create one.

[Kai]

Update: I’m still working actively on this as often as I can. It has been in a “mostly working” state for quite some time, but my lack of VST dev experience has meant I have been stuck in a quagmire of refactoring and testing. (Even though it is obvious in hindsight, one of several issues was I was slow to realise the UI in a VST will pop in and out of existence. So my initial, stupid approach where the UI “owned” the plugin settings got very impractical and required a complete rethink of how to handle state/presets, etc…) I think I have a practical, working solution down now, though. So hopefully I can move forward instead of rewriting existing code soon.

Anyways, the OSC localhost approach seems to work well and playing my Pico with Mapper hosted in GigPerformer feels responsive and nice. I will have to do some more realistic testing once the last of the temp hardcoded stuff is replaced by a proper implementation, but at the moment I think it is very likely that I will actually finish this and that it will be a decent third alternative alongside EigenD and MEC.

[keymanpal]

That’s great news!! Keep pushing

[Kai]

EDIT 2: Ok, seems like I stumbled across a solution to this, so ignore this post. (Apparently, renaming the folder where the executable is run from fixed things. Doesn’t make any sense to me, but doesn’t matter as long as it works. Macs are weird…

---

The good news I am ready to release the standalone and VST3 versions for mac, but the bad is that when testing the installed package, I hit a weird problem I couldn’t solve. I’m a windows guy, so I was hoping @thetechnobear or someone else knowledgeable had some idea what was going on…

It turns out “EigenCore”, the console application using EigenLite, is not working properly when run from the ~/Applications folder. My project is in a subfolder of ~/Documents. When I run my build from XCode I get a dialog requesting access to my Documents folder and then it runs fine. I can also start it from terminal, no problem. I can move it around to any subfolder of Documents, and still fine.

…however, if I copy it to ~/Applications, and start it using terminal, it starts and works for 30 seconds or so. (I can see Pico key presses getting registered, etc). But then something apparently happens that makes Core lose connection to the Eigenharp. There is still some activity, but things aren’t working properly, and even quit’ing with Ctrl+C takes a lot of time. I always put the folder with resources at the same location as the executable, btw.

Anyone have any idea what is going on or what I could try to do to pinpoint what the problem is? I’ve been googling around and trying all sorts of stuff, but I’m still stumped. Something MacOS security-related, perhaps?

EDIT: I tried doing the same with the EigenLite test app, and that worked. So apparently not Eigenharp related. I can ask on stack overflow or the juce forum instead…

[Kai]

…and it is done. For now. Hopefully. I’ve tried to check as best I can that this doesn’t suffer from the “works on my machine” syndrome, but with only access to one Mac I’m not really confident I got everything right. Anyways:

ECMapper v1.0.0 MacOS

This release contains:

• “EigenCore” (an application that communicates with the Eigenharps)
• “ECMapper” Standalone (EigenCore Mapper) that receives data from EigenCore and outputs midi as configured in the UI.
• “ECMapper” VST3 plugin that works as the standalone version, but intended to be used in GigPerformer (only host tested). Intended as one plugin per rackspace, so that the Eigenharp settings change when active rackspace changes.
• A ECMapperLayouts folder in ~/Documents with a couple of example layouts per Eigenharp model to get people started.

Both EigenCore and standalone ECMapper should show up in Launchpad. ECMapper standalone needs to have audio output device set even though it only outputs midi.

Edit: argh, even though I tested it multiple times, EigenCore don’t start properly from Launchpad. It is just a folder and console app found in ~/Applications, so if you instead open terminal, “cd ~/Applications/EigenCore_v100” and then start it with “./EigenCore” it should run. Or so I hope.

[keymanpal]

Give me a moment… installing

edit and following:
So… installing was easy done !
although it initially installed in “user”/Applications ??
(I just copied to the whole dir to Macintosh HD/Applications)
… and IT WORKS !! both ECMapper Standalone and ECMapper VST3 inside GigPerformer4

[keymanpal]

@Kai WOW just wow!! great work!
Intuitive and what a fast way to get… ahah mapping of wonderful eigen keys to whatever you want !!

Ohh, this is what I sometimes referred to = integration !!
It will give new life to instruments ahahahah and even crazier setups of keys!

[keymanpal]

@Kai just that 1st screenshot
MBP Mojave + Pico

[Kai]

Yay! I’m very glad to hear you got it working. If it runs on both my MBP Big Sur and your MBP Mojave then it will probably work for others as well.

Pro tip: you can use the keyboard cursor keys to navigate the keys in the UI when mapping. I found placing the mouse cursor over for instance “Zone”, then using enter and the cursor keys to set things was the fastest way when doing lots of changes.

I won’t have time to work much on this for the next couple of months, so that is why I wanted to release it now. I expect there to be bugs, but I’ve been using it myself and so far it seems to work as intended. Lots of stuff I want to add, obviously, but for now I tried to selfishly prioritize the stuff I knew I had use for myself.

[keymanpal]

@Kai

If it runs on both my MBP Big Sur and your MBP Mojave then it will probably work for others as well.

Great! I’ll do some more testing/install on iMac studio and run with Alpha… later tonight.

@Kai

Pro tip:

Thanks for that!

@Kai

but for now I tried to selfishly prioritize the stuff I knew I had use for myself.

All good for me ! I just love to support/help as I can (no requests, might just take some notes), and honestly between EigenCore and GP, plenty of “workarounds” or ways to achieve “this and that”.

[Kai]

@keymanpal

I just love to support/help as I can (no requests, might just take some notes)

Oh, requests, ideas, bug reports, etc. are very welcome! I feel ECMapper should aim to be as useful as possible while also being something “non-tech” musicians can make sense of. Feature wise it will never hold its own against EigenD (and I don’t think it should even try ), but rather aim for convenience and the use case where one don’t want to host stuff in EigenD, but instead add Eigenharps to some other host.

Current thoughts on what to do from here:

• Pri 1 - make sure what is already there is working reliably. It should be “safe” to use on stage without worry. So needs more testing and probably some bug fixes.
  …and from there on

• Code quality and performance improvements

• Make UI more user friendly/robust (stop users using “wrong” settings (like MPE range 1-16 and single channel 5 at the same time, for instance)

• Customizable expression curves and a smoothing/slew setting for the keys and breath.

• The ability to create an ordered list of layouts and then switch between them from keys.

• The ability to change some settings from keys, (e.g. change transpose or midi channel on the fly)

• Expose some settings as VST parameters, so that they can be used for automation or GigPerformer Widgets

• AU plugin (I originally meant to include one, but I couldn’t get it working out of the box and didn’t feel it was important as a first release)

• Raspberry PI version - especially if EigenCore on PI and ECMapper on some other device turns out to perform well (I haven’t tried yet).

• Windows version of ECMapper is simple, and could probably very easily be built from source right now. From what I understand EigenCore will be more tricky because of the USB stuff in the EigenLite API.

• A manual

…some other thoughts/ideas I’ve had that I consider less important, but might be useful/fun to implement further down the line:

• IOS version of ECMapper? Would probably require a redesign of the UI.
• Make EigenCore optional for ECMapper (I’ve tried to structure the source code so that the relevant parts of Core can be (hopefully) easily added to ECMapper).
• Allow for mapping negative breath to something
• Set chords on keys (I’m thinking bass side of an accordion, where keys play maj,min,maj7… chords)
• Make EigenCore general so that other devs can use it + document how to communicate with it.
• Perhaps exposing the accelerometer values so that they can be mapped to something as well?

…but yeah, all of this combined will be a lot of work, so won’t happen anytime soon. Once the codebase is bugfree and nice then at least adding some of this should be easy, though.

[GoneCaving]

For once, I’m hoping it’s wet and miserable weather at the weekend!! That looks great, Kai!

[thetechnobear]

cool stuff…

some questions thoghts (sorry, dont have time to check the code yet)

• what protocol are you using between EigenCore and ECMapper?
• might be good to make EigenCore a VST as well - for user to install.
• EC Mapper, perhaps allow multiple instances…

what Im thinking is…

if EigenCore is broadcasting via OSC,
then you can easily have multiple EC Mappers running, this would mean each instance could represent a split/section of the surface… essentially, they would kind of be activing like midifx

in MEC I do have a VST implementation, but its very dated…
I really want to update it, since now ive been doing a load of stuff on the SSP - Ive managed to get juce integrated into my build with Cmake (yippee!) - also I can now avoid juicer , which I really dislike with a passion