MEC access the round "command" keys on Pico?

Just learned what MEC is after having some intermittent issues with EigenD on my Catalina box.
I always thought that the Eigenharps are FABULOUS expressive instruments, but the entire attempt to control everything using the complicated EigenD and Belcanto etc… was an overkill.
A simple MIDI or OSC output with fine controls over the output is more than sufficient.

I build MEC and it works, doesn’t have support for scales or changing the root note yet, but those can be dealt with either by modifying the source or elsewhere.

What I am missing is the detection of the little round “control” keys on my pico (the two on top and two on the bottom) which are used for changing the scales, starting the drums, switching to a different octave etc…

Does anyone know if it is possible to detect presses on these?

Thanks.

You can change the root note with “note offset” and the layout with “row multiplier” and “col multipler”. This allows a whole bunch of layouts with chromatic scale.
I usually play only chromatically, but I think there was something like “notes” for defining scales: https://github.com/TheTechnobear/MEC/blob/master/resources/examples/eigenharp.json

No clue whether mode keys are used in MEC atm. - guess not? But EigenLite (the Eigenharp lib behind MEC) apparently allows access to the mode keys (kbd_mode), so it could be added.
Edit: This is the glue code in MEC that calls into EigenLite: https://github.com/TheTechnobear/MEC/blob/master/mec-api/devices/mec_eigenharp.cpp

yeah, once I got into scales and mode keys, things started getting complicated pretty fast!
… since for things like the alpha and tau, it makes sense to have split keyboards. (aka surfaces)
from there, you need to start potentially targeting different devices, or different midi channels.
then there is a whole load of annoying complications to do with the leds, since you need to light them relative to the surface mapping, which requires a reverse mapping - arghhh

so you’ll find, although i did some tests, and ideas around these - I never got around to integrating it into the main core.

( as you can see… the idea was MEC was suppose to be a simple interface into the Eigenharp, where the user could then map etc in a daw … add adding this extra layer, almost felt like it was moving away from this …)

anyway, its not so difficult with the pico, as it only has a few keys…
so you can actually map each of the keys manually… Im pretty sure the mode keys do get mapped… as they are just seen as a different column.

the hardware api, does not see the instrument in the layout you see it
on a pico, iirc, its just 2 columns, one for the mode keys, one for the eigen keys

so you should be able to map all these to midi notes…
then in your daw or whatever, apply splits and scales as required.

however, there is probably one issue with this… which was where surfaces came into it (and yet more complication) - you don’t want the voice allocation to include the mode keys… which currently you cannot prevent.

edit: I have to admit by the time i was last working on this, i had got into modular… so polyphony was not really as much of an issue for … rather i just want the expressive side of the eigenharps.
i do need to get back to mec to kind of finish this all off, but just a matter of finding the time.
(splitting the keyboard would be really handy for the modular :slight_smile: )

Thanks guys - I am involved with Gig Performer and I really can do everything I need including scales, root notes etc within Gig Performer itself. I do not need any note mapping or rather - it can always be a chromatic scale with x/y/z values and I can then translate that into whatever I want.

I just didn’t see anything happen when I pressed the little round buttons on the pico. I’m not talking about the 18 main buttons, but the 4 round ones used for the octave and scale selection.
I would like to use those in similar fashion that EigenD uses them - the bottom ones to move the octave and the top ones to somehow change the scale.

The actual octave/scale changing does not have to happen inside MEC but I still need to know that these were pressed and send a signal to GP to do something.

ok, theres a couple of problems…


a) velocity
so as detailed above, the issue is these keys are seen the same as others.
the issue is for the main keys, I do velocity detection based on a number of readings…
but this does not work on the mode keys… since they just send one value.

you can get around this by setting :

{
    "mec"  :  {
        "eigenharp" : {            
               "velocity count" : 0,

note: this will mean you effectively won’t get a real velocity for the main keys
you’ll likely get note on velocity = 1 for all keys.

(I guess, what you could do for the main keys is calculate a velocity from subsequent channel pressure events… which is effectively what I do inside mec when velocity count > 0 (default is to use 4 readings)

I thing mid-term what I need to do in MEC is treat switch keys different… since we dont want them to be voiced, nor wait affected by velocity. (but don’t have time at mo, to do the refactor that requires)


b) I was off-setting the ‘course’ by 1024 , which meant it wrapped around on midi notes

I just checked in a change for MEC, to alter this to 120 - you need to pull ‘dev’ branch, and rebuild

now the mode keys come in as 120
BUT… the default setting in the prefs file for midi is to offset by 48

                    "calculated": {
                        "keys in col": 9,
                        "row multiplier": 1,
                        "col multipler": 5,
                        "note offset": 48
                    }

this would mean they’d be out of midi range, so you’ll want to change the offset to zero

                    "calculated": {
                        "keys in col": 9,
                        "row multiplier": 1,
                        "col multipler": 5,
                        "note offset": 0
                    }

then you’ll get the main keys on 0-17, and mode keys as 120-124

edit note: I’ve just added support for these mode keys to have their leds set, using 120-124

mid term, I want to use the physical characteristic to determine things like the offset - but thats closely related to the surface mapping stuff Ive started but not completed.


I know not perfect…
as I said, I really need to get back to this at some point…
but things like mode keys and also the layout begs quite a few questions.

the ‘biggest’ issue is the tau, since it has an irregular shaped playing surface, rather than just rectangles as like the pico/alpha … my thought was to treat these a bit like the ‘percussion keys’ on the alpha… so give them a separate role.

but all time, and Ive been ‘distracted’ recently

2 Likes

Thanks. I’ll play with it and see if I can make things work for me.

Cheers.

This sounds really interesting - What is MEC and what are you doing exactly? because I agree that if my Pico was a straightforward MPE midi controller it would meet my needs much better. The ability to control pitch bend in Stage is pretty useful and the midi channel poly mode is kind of essential. But I still live in eternal fear that the next update will render my Pico unplayable.

MEC (Micro Expression Control) is a neat program from Mark:

It allows to run Eigenharps (and Soundplanes etc.) without EigenD, so you can e.g. use a Raspberry Pi or Organelle as an Eigenharp to MIDI (or OSC) converter. It even runs as MaxMSP module or VST - there variants are probably less tested than the standalone though. (For Alpha or Tau you still need the Basestation). Of course it doesn’t offer all the bells and whistles of EigenD but it’s nice for a minimalistic setup.
There are binaries for Organelle and Rasperry Pi (on Patchbox OS) and it can be compiled from source for Mac, Linux and (experimental) Windows. Best check Mark’s Youtube channel, MEC is described there e.g. in combination with ORAC 2.

Thanks as always for the reply - I have downloaded MEC master from the GitHub link and I am not sure what to do next. It all seems a bit beyond me truth be told. As I am still having issues with EigenD crashing, especially when using a few controllers, I thought that this may be a good alternative. But anyway I have to think a bit about what to do next. I also find it difficult to get my EWI usb to work when I have other controllers connected. It’s not the end of the world though I’m still making music.

There are currently no prebuilt binaries for Mac or Windows.
Best have a look at the build documentation: https://github.com/TheTechnobear/MEC/blob/master/docs/BUILD.md

Just had a look, the Windows version doesn’t seem to support Eigenharps (nor most other devices) yet, so it’s probably only practically viable for Mac or Linux atm.

if(WIN32)
message(“windows support limited”)
set(DISABLE_LIBUSB 1)
set(DISABLE_EIGENHARP 1)
set(DISABLE_SOUNDPLANELITE 1)
set(DISABLE_PUSH2 1)
set(DISABLE_NUI 1)
set(DISABLE_TTUI 1)
endif()

Many thanks for the reply!

yeah, the issue is we don’t have the windows drivers for the eigenharp

BUT do not fear (!) , libusb can be made to work with windows,
however, I found it quite a faff - so really need to do go thru the process a few times, so I can explain what is needed.
also, I then need to test it, to see if there are any windows specific issues.
(the libusb code works fine under linux and macos)

finally, I’ll be honest here… the whole build process under windows is horrible/time consuming - so it takes me a while to get ‘motivated’ to do it. (compared to mac/linux which takes me about 15 mins to setup from scratch)

hmm, that said, I now have CLion, which works under windows … perhaps that might work a bit easier under windows?!

I tried to build MEC yesterday on Windows (probably not too useful until the usb stuff works but still). Apparently most mingw64 distributions seem to be outdated by now. Finally found an easy way to get an up to date mingw64 toolchain:

  • Install MSYS2: https://www.msys2.org/
  • Install all relevant build tools (including cmake, gcc, make, gdb etc.) by opening the msys2 shell and typing:
pacman -S mingw-w64-x86_64-toolchain

In Clion it complains that cmake is too new but it apparently still seems to work. Well, until it complains that it needs PureData sources that cannot easily be gotten for msys2 under Windows via pacman, needs a manual download and setting of environment variables I guess.

yeah, i think ive compiled mec on windows… ( either under msys2, or the linux subsystem)

( I used to sometimes do a bit of code editing/developing on my windows laptop… and was compiling just to check for errors … don’t think i ever ran it… that said, who knows perhaps i did )

does it need pd sources? i thought i include m_pd.h, which i thought was all that was needed - (but i may be mis-remembering this :slight_smile:

running libusb on windows , im pretty sure this info can be found online.
its a matter of installing a driver which basically acts as a proxy for libusb to hardware layer.
you don’t need to change any source code , the code should ‘just work’. (iirc)

this ‘experience’ i actually got trying to use a libusb with eigenD… but it was quite a while ago !
(thats why i can’t remember how successful it was…i believe it work, but i dont think i ever really tried to play music with it for extended periods - so i dont know if the performance is ok)

EigenLite doesn’t seem to like mingw64:

C:/Users/strix/CLionProjects/MEC/external/EigenLite/eigenapi/picross/pic_winstdint.h:33:2: error: #error "Use this header only with Microsoft Visual C++ compilers!"
   33 | #error "Use this header only with Microsoft Visual C++ compilers!"
      |  ^~~~~

Edit: Only Kontrol seems to need PD stuff, if I comment out add_subdirectory(“mec-kontrol”) (which is probably not needed for Eigenharp purposes?) the following error seems to go away:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
PD_LIBRARY
    linked by target "KontrolModule" in directory C:/Users/strix/CLionProjects/MEC/mec-kontrol/pd/kontrolmodule
    linked by target "KontrolRack" in directory C:/Users/strix/CLionProjects/MEC/mec-kontrol/pd/kontrolrack

P.S.: In the build docu as alternative to mingw64 WSL is mentioned. Did you try WSL1 (which maps Unix systemcalls to Windows systemcalls) or WSL2 (which runs a Linux kernel inside HyperV)? For the first I wonder whether USB would work and for the latter whether latency couldn’t be an issue?

P.P.S.: If I interpret this issue right then libusb doesn’t fully work with neither WSL1 not WSL2? https://github.com/microsoft/WSL/issues/2195
Am a little hesitant to install particularly WSL2 on my private machine because HyperV is a type 1 hypervisor, so once installed, Windows is also virtualized as kind of a guest (and I fear that this might lead to worse latencies for audio stuff).

I guess, I did the build under the linux subsystem then…
it was a while ago, and as i said, I didn’t try to run MEC, I was just using it for compilation.

my confusion is I do also have mingw64 installed… since I really loathe microsofts cmd and powershell… so avoid at all costs :wink:

this is kind of why I just marked it as ‘unsupported’… I was a bit concerned that if I even got it compiled with an ‘alternative’ (unix like) dev environment, this would link its some other runtime that would be required by users - which complicates things even more.
I guess compiling under MSVC is the best option, but I didn’t want to go down that rabbit hole, its bad enough with xcode on macos.
(that said… at least with CMake, I believe their is support for MSVC - so pehaps not that bad)

anyway, I’ve got in on my ‘to do’ list, but Ive got 3 others projects on the go at the moment, so not got time/focus to look at it now :frowning:

Sure, totally understandable, particularly when you don’t plan to use it on Windows machines yourself. At least not yet… :wink:
Had a look at the Apple presentation yesterday. Fortunately they didn’t use the opportunity when moving to ARM cores and getting iOS app compatibility in to remove side loading capabilities, making the Apple store obligatory for the new Macs. Like MS did with their (oh wonder, not really successful) ARM based Windows. Well at least Apple hasn’t done that yet…
So macOS is fortunately still an option :slight_smile:
The new MacBooks look neat - if only they would have added more USB/TB ports. Two (with one needed for charging) is imho not enough. (Particularly with some devices not working properly with USB hubs).

There might be a way to get usb to work with WSL2 on Windows by as I understad it forwarding packages from Windows to the Linux kernel: https://github.com/rpasek/usbip-wsl2-instructions
Not sure whether this is a worthwhile path though - don’t think many people would install this to use MEC on Windows…

It is probably easier to just use EigenD on Windows. With a minimal setup it also starts fast and can be used in a setup and forget manner.

1 Like

yeah - I need a new Mac, and was hoping the ARM based 16" Mac Book Pro would be released - Unfortunately not this time around :frowning:

I’m thinking of getting a new Mac Mini for now… Im sure it’ll be better for music/video than my current iMac… then look at getting the macbook pro once it gets released (Im guessing mid 2021?)
(need to run this by Lydia, as its a bit of extra cash… as we’d hoped that we just get a new MBP)

this would allow me to look at building EigenD (and MEC) on BigSur/ARM.

(I’m hoping EigenD willl work under Rosetta 2 will pretty good perfromance)

3 Likes