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

Eigenharp
21

Hmm, this is actually a low-hanging fruit that would be convenient. It would allow full 15 MPE channels per zone by using multiple Mapper instances, and would also support the double Pico. Yes, I’m using OSC, so Core would need to use multiple sets of ports.

Hmm. This should also be pretty simple to do. Makes sense in GigPerformer 4 now that one can add plugins globally for all rack spaces. VST or not, I think a small, simple UI with connection statuses, a settings menu and an optional log window would be more user friendly and give a better impression than a console app anyway.

I deliberately kept things simple at first to see if the idea would even work at all. But revisiting Core and improve stuff like this would be nice to do next. Especially curious how Core on rPI with a cabled connection to ECMapper on my mac will perform. To test that might help decide if the Core/Mapper split even makes sense. Both apps use thread safe FIFOs to push/consume Eigenharp messages. So if I do decide to ditch Core, just moving the relevant Core parts over to Mapper shouldn’t affect the rest of the code.

Heh, I’ve been fighting the urge to get the SSP ever since it got released. Learning that you are making stuff for it is not helping! I’m using Projucer atm since I am so new to all of this, so will probably stick to that until I have more experience. My personal pet peeve is XCode, though. I expected it to grow on me, but I find it horrible! Since I happen to own CLion, I think I will give that a whirl instead.

1 Like
22

lol, I should start getting affiliates links :slight_smile:

I never really liked projucer, and generally dont much like ‘code generators’ for this kind of stuff.
but for sure its gets things going quickly - esp. if its ‘one off’ type stuff.

yeah, I find xcode clunky, I dont use it… (unless I have to) , to the point, I just compile code with xcode command line tools where necessary.

its similar to projucer, I dont like these ides which try to go beyond edit/compile/debug - and hide all settings in thier own ‘project files’ which you have no idea whats going on… and are platform specific.
… in fairness, Xcode and Visual Studio are pretty much the same in this regard.

so yeah, CLion with CMake , I love… simple to use, and means my cmake project files work across all platforms. (albeit, with numerous conditionals in them) … even makes cross-compiling pretty simple, which is important when trying to target things like rPI/SSP where you do not want to be compiling on the actual device.
(ok, most of these benefits are CMake rather than CLion, but the fact CLion just picks these up and works… means they are a great combo)

make sure you are using lock free versions - its quite easy to get priority inversion, and start getting missed message due to not servicing the queue frequently enough. esp. on less powerful platforms.

can you not broadcast over UDP (its only localhost)?
just send all (same) messages to all clients, and then the client can do the filtering.
that should be pretty effecient, only one message to form and broadcast

it does mean its not guaranteed, but in this case it doesn’t really matter since its all local - so message will not go missing.

the only message that you’d really care about missing would be ‘touch off’, but if you did have problems (which I dont think you will broadcasting on localhost) , you could have a fall back to catch this.
(msg seq, with note on count… to be able to force a rebroadcast)

(incoming core just listens on one port - so thats not an issue)

1 Like
23

Yeah, they are lock free, so I think I got that part right. But I suspect I will find some other potentially problematic stuff when I review and improve what I have done so far. Iirc, the current logic for handling changes to layouts/settings is “stop processing - refresh a “data lookup” object that the process thread will use to read from - then start processing again”. I assumed that would be thread safe - but impractical once features that can change settings on the fly is implemented.

Good point. I could. I initially dismissed it because of the two-way communication and that it introduces multiple sources of key LED truth. Which instance should send LED messages back? Should an instance send a “turn off all LEDs” when it is destroyed or not? Stuff like that. Also, if the user change a key LED in an instance that isn’t the “LED master”, it will be confusing why nothing happens on the Eigenharp. So some kind of visual indication that this instance is in “receive only”-mode will probably be needed. Doesn’t sounds hard to solve and with a visual indication of which instance is “master” I think this will be a nice solution from a user perspective.

My first thought was to let the user route things from Core and keep a 1-1 connection to each client using multiple ports. That would be even more flexible and support the double Pico use-case, but with more complexity for the user. I want to keep things simple, so the more I consider this, the less keen I am to go down this route.

I like the msg seq idea! Currently, Core is “dumb” and just sends everything and I haven’t noticed any problem on localhost so far. But still, it would be nice if it differentiated between what is important (note off, strip off, breath 0) and what is not. So that one can optionally reduce the amount of osc messages and still be sure the important stuff is still sent. If/when I do this, I should definitively add message counters as well.

2 Likes
24

I’ve fixed a couple of serious bugs since the release. If anyone is using (or intend to use) this soon I can make a fixed release now. Otherwise I will continue working on this in the autumn and add more of the nice-to-have features as well.

(We are currently preparing for a couple of live shows in august (with Tau, Pico and ECMapper :slight_smile: ) so I try to focus on that for now.)

5 Likes
25

Great news! On bug fixes and upcoming shows.

I also have a show planned on the beginning of August (with a ton of restrictions, even outdoors) will be playing the Alpha on a brief part for like 10 min; I’m “brave enough” to use ECMapper given the opportunity :wink:
Plan is to use the Alpha much more as a “controller” sending MIDI CC, Program change, controlling video, lights… ok leave some area to play notes :wink:

Can’t wait to try out the new version!

3 Likes
26

Nice! I have made a new release with some fixes. From the top of my head:

  • Configuring keys to send CCs and program changes etc should actually work as intended now
  • Multiple ECMapper instances in different rackspaces in GigPerformer could cause crashes. I haven’t had a crash since fixing this despite using it a lot, so I have much more confidence this will be “safe” to use on stage now.
  • The round buttons on the Tau didn’t work properly. LEDs still don’t light up for those buttons (on the Tau only), but at least the buttons work now.

Btw, I know you are much more experienced in GigPerformer than I am, but just in case: I found the new local GP Midi port useful when switching variations/rackspaces with ECMapper program change messages. I made this small scriptlet that I use (I use bank LSBs for Rackspace, program change for variations):

Current : Parameter 0 .. 3 = 0
Bank : Parameter 0 .. 15 = 9
var bankSelectLSB : ControlChangeMessage

On ProgramChangeEvent(p: ProgramChangeMessage)
    Current = GetProgramChangeNumber(p)
    bankSelectLSB = MakeControlChangeMessage(32, Bank)
    InjectMidiEvent("Local GP Port", bankSelectLSB)
    InjectMidiEvent("Local GP Port", p)
End
4 Likes
27

Huge Thanks and big thumbs up to you my friend @kai for ECMapper :beers:
Im sure its just the beginning …!!!

I made a post about it here :wink:

5 Likes
28

I’ve made a new release with a lot of improvements and changes. Changes are:

  • the EigenCore console application has been replaced by “proper” standalone/VST versions
  • it is now possible to run multiple instances of the ECMapper plugin
  • Chords can be mapped to keys
  • Improved velocity calculation
  • Lots of bug fixes and under-the-hood improvements

I also tried to make a quick-start video to help “non-techies” to grasp what ECMapper is and how to use it, but it didn’t turn out that well. :face_with_diagonal_mouth: Hopefully “good enough” for the time being.

Btw: could someone help me rename this thread to “ECMapper” and perhaps add some kind of info to the top? E.g.:

ECMapper is a light-weight alternative to the official EigenD software for MacOS. It is made especially for Gig Performer, but works standalone and in DAWs. Download link and more information at https://ticticelectro.com/2023/07/17/ecmapper/

5 Likes
29

Done ! 20 characters

3 Likes
30

I forgot to mention it, but EigenCore is built for intel macs only. I didn’t realize that would be an issue. I’m on an intel mac myself with little knowledge of how Rosetta works - I just naively assumed it wouldn’t matter and didn’t think more of it.

@keymanpal has done some testing (thanks again!) and tells me that the standalone version of EigenCore works on his M1 mac, but the VST3 plugin doesn’t validate in Gig Performer without running Gig Performer in Rosetta mode. ECMapper is a universal build btw, so no issues there.

I don’t think a universal build of EigenCore is much work, but I will have to sit down and take a proper look at what needs to be done to be sure. (@thetechnobear I didn’t realize until just now that you had made an Arm64 version of the pico decoder dylib - I’m hoping that is all I need…)

5 Likes
31

12 posts were split to a new topic: M1 testing EigenCore/ECMapper

33

Can’t believe I missed this. It makes me feel more assured that as tech progresses, that I’ll still be able to use the eigenharps. Thank you for the work you’re putting in.

5 Likes
34

been running into the technobear tag in a lot of places - downloaded your stuff haven’t quite had an opp to wrestle with a new learning curve yet but one quick question - Ive had some issues with the key presses choking off the sound almost immediately - specially in kontakt - aggravating as can be, may have something to do with velocity, i really can’t say as i am still wet behind the ears, and frankly workbench while not all that much different relatively speaking than a number of other software gui wise - actually deciphering the functionality is enough to make you want to punch babies (not literally),

so would your software make this issue easier to fix? oops two questions, second being any idea what the issue would be?

2 Likes
35

Hard to say what the issue you are experiencing in Kontakt could be without more info. I’ve tried to make sure ECMapper is easy to use. It is possible to configure midi channels, etc in a way that doesn’t make sense and will cause problems, but should be easy to avoid. There really isn’t that much to it, so if you have that issue with ECMapper as well we can hopefully get that sorted easily.

1 Like
36

Just wanted to pop in and say thanks to @Kai for making this. Worked great and much less intimidating than EigenD! I was on the fence whether to sell my Pico, but dusted it off and found this and now may have to keep it haha. Looking forward to the transpose from button feature as well.

4 Likes