@Kai just that 1st screenshot
MBP Mojave + Pico
@Kai just that 1st screenshot
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.
…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.
For once, I’m hoping it’s wet and miserable weather at the weekend!! That looks great, Kai!
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.
lol, I should start getting affiliates links
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.)
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
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
Can’t wait to try out the new version!
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
Huge Thanks and big thumbs up to you my friend @kai for ECMapper
Im sure its just the beginning …!!!
I made a post about it here
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/
Done ! 20 characters
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…)
12 posts were split to a new topic: M1 testing EigenCore/ECMapper
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.