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.
Great! Iāll do some more testing/install on iMac studio and run with Alphaā¦ later tonight.
Thanks for that!
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ā.
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.
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
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.
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)
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.
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 ) so I try to focus on that for now.)
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
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
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
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. 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/
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ā¦)
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.
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?
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.
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.
Hopefully āgood enoughā for the time being.