Native arm version - testing EigenCore/ECMapper

yeah, MEC works on both intel and arm native, so you should be ok.

that said, I had a quick look at your GitHub…
personally, I find it much easier to do cross-platform stuff using CMake…

even when using JUCE, I avoid pro juicer like the plague.
that way, you dont need to use any of JUCE binary tools, and can have your own makefile… as your just using their source/header files.
(JUCE have supported CMake for quite a while now)

Im a bit busy at the moment, but if you if I get time, I could have a look at converting ECMapper over to CMake if you wish?!

alternatively, my SSP GitHub creates juce vst using cmake if you want to take a look

you only really need to look at the Cmakefiles, its pretty straightforward.

note: juce do also support a ‘application target’, though you wont find an example in my above repo, as they are all vsts.

ps. I don’t bother with universal binaries…though, Id assume Cmake supports them.

btw: added bonus… if the project is open source then you can get a free license (on approval) for CLion, which is a great IDE… thats uses raw CMake files, and is crossplatform.


I don’t like neither ProJucer nor Xcode, but love JetBrains. I already own their product bundle, including CLion. What has stopped me from moving over is that I don’t know anything about CMake, so I have kept putting it off. I can give it a go myself now that the new ECMapper is out the door, so that I learn something in the process. If I struggle I would love your assistance sometime in the future when it suits you, but armed with your SSP project and my recently purchased CMake book I’ll probably figure it out. :slight_smile:

Anyways, so, Arm64 - I took a look yesterday and have a universal EigenCore build now (I used the arm64 pico decoder from the EigenD resources folder in the 2.2 repo). But I’m a bit confused, because all the pico decoder dylibs in EigenD lists Python2.7 and Accelerate as Framework dependents. Your i386/x86_64 combined picodecoder.dylib in MEC resources, however, does not have these dependents. I didn’t find an arm64 version in the MEC repo.

With a Pico (i.e. not with the dummy decoder from EigenLite), I take it? Hmm, I guess that means I’m either overlooking an arm64 pico decoder in MEC or that I don’t actually need one… I’ll look some more this evening. Curious about the MEC/EigenD dependents differences regardless, though. I checked by doing:

dyld_info -dependents libpicodecoder.dylib

1 Like

I pretty much copy my top-level setup I have in MEC to all my projects these days,
helps me create a project very quickly.

later today, I’ll see if I can get the basic cmake structure in place for you, and offer up (PR) a branch to merge in, as its should only be a 10 min job or so for me.
(I really wanted to check this was a direction you wanted to go in ;))

But I’m a bit confused, because all the pico decoder dylibs in EigenD lists Python2.7 and Accelerate as Framework dependents.

ok, so the underlying issue is…
the picodecoder source code is not open sourced, because of a licensing issue (*). however, I was supplied the code with condition of non-disclosure - this means Ive been able to build a version of it for platforms we require - and also remove any ‘unnecessary’ dependancies.

however, strictly speaking, this created a licensing issue for GPL products.
for you to be able to create a GPL product (e.g. to use JUCE under GPL license), the product has to be complete… you cannot use a binary library.

this is why I created the dummy picodecoder, so that EigenLite can be GPL’d , as its source code is now complete…
so this is how Ive handled the legality of this ‘issue’.

so it’s not ideal, and frankly, there is little risk of legal challenge on picodecoder,
Im sure you can appreciate, that I want to stay within the boundaries that have been set.
whilst, ensuring that pico owners will be able to use their instruments on a variety of platforms.

note: to be complete on ‘licensing’
there are a couple of other bits of ‘code’ we (community) do not have…

  • any code to do with ‘runtime’, basically the installers for the runtime library
    we just have the eigenD part. this is not really an issue, but its why the community build does have a full one click install.

  • Window EigenD driver
    this is a bit more of an issue, as its 32 bit intel only, so one day, that is going to an issue for some users. the good news is this ‘driver’ simply forwards usb packets - and was developed because at the time, you could not have user land code accessing usb devices.
    I did have (successful) experimentation branch of converting windows over to using libusb and the libusb stack/driver… thus removing this dependancy. but it was a bit fiddly to setup… so never released it, nor gave it the thorough testing it would need (incl performance)
    I should do this again… then perhaps hand it over to someone who uses Windows regularly to test it.
    this is also the reason, why Ive never ‘released’ MEC on windows… as Id like to remove this eigend driver dependancy.

sorry, that went off-topic, but its good for others to have this information, and to understand constraints we are working within.

(*) iirc, the hardware/firmware for all devices was developed under contract with third party developer.
the pico decoder is essentially the code/algo used in the firmware on other devices, so fell under that license.
John was going to approach 3rd party, to ask/negotiate a license, but this never happened… and frankly, wont happen - its really not a big deal, as I have access, so it ‘is what it is’.


Thank you for the thorough explanation. This is information that is nice to have. I’m a “windows person”, so I will be more than happy to test/assist/contribute for MEC/EigenLite for windows whenever. You just lead the way! :slight_smile:

1 Like

ok, Ive sent you a PR, which now builds with cmake

(for now I have not removed jucer files)

Juce is now included with a submodule so you should do

then its just

git submodule update --init --recursive
mkdir build; cd build
cmake ..
cmake --build .

or of course just load the project using CLion :slight_smile:

BUT there is one small issue…
the EigenCore is not linking currently… the reason is what you have done with EigenLite !

basically the approach you have taken, using binary library files, is not the way it should/needs to be done.

I did try to link it statically, but CMake was not playing ball…
(or it might be the Juce targets specially, as the cmake options that should work don’t)
I didn’t continue, because as I said, this is not really the way to make it work

so correct approach is:

a) use submodules
so as Ive done with juce, create a submodule that points to my EigenLite project

b) just include the EigenLite project into this project.
there is a CMakeFile that already in EigenLite that will neatly bring this is.

this requires a couple of things…

i) you revert to using my EigenLite i.e. one without changes
I don’t see this as an issue, as Ive included your pull requests.
you could use your own fork , but you should aim to keep it inline with mine… having forks with such a small user base, is frankly not a good idea :wink:
so we really should aim to combine these.

ii) static library
perhaps this is why you are using a fork?
but we can easily modify the EigenLite CMakeFile to support both dynamic libraries and static build - simple flag setting would work.
thats said, Im not sure why you’d care… given the picodecoder has to be a dynamic lib. for reasons I mentioned above, so one or two dynamic libs is really not an issue.

why is this approach better?
well apart from have a more consistent build, it also makes cross-platform builds much easier, since you are building EigenLite from source.
SO… if you building on macOS arm, macOS intel, or windows , or linux , it will all just build.

if you go the binary library route, you’d have to build all the different variations, and alter the link to make sure you pull in the correct version - then IF EigenLiite updates, you have to build them all again.

this way ‘it just works’ ™ , as you can simply do a pull from EigenLite subdirectory and bobs your uncle… new build is created where nessary.

also as I mentioned above… for licensing purpose, if you are using JUCE under GPL (to avoid the banner ;)), you cannot include binary libraries without source - thats part of GPL.
bare in mind EigenLite is GPL, because the EigenLabs code it uses is GPL… so it has to carry forward

id also point out (legally) you are probably on ‘shaky’ ground embedding the ihx files into your binary :wink:

anyway , that s why I didn’t fix the static linking, as its just creating more trouble that its worth.
on the other hand, I didn’t want to move back over to using EigenLite without chatting to you first about it.

but using an EigenLite submodule, is the way I would do this

( * ) I know , I know, no one cares… it’s easer for the end user. etc etc,
but as an open source dev, I do respect licenses etc, EigenLabs were kind enough to open source the code, which made all of this possible… so I personally respect it - but its your decision.

1 Like

@keymanpal I updated the release, so both apps should be universal now. I can’t test i, but I think the EigenCore VST should work on arm native GP now. :slight_smile:

@thetechnobear I have merged your PR now. Much appreciated!


@Kai , is this release based on what Ive done?

if so, just a quick note to say… whilst I do not expect issues… there are a few changes.

a) its using a newer version of JUCE (7)
so keep an eye out for bugs either in the UI, or possibly (less likely) the vst3 implementation.
b) pico decoder has been updated.
should not be an issue, but just be aware in case there are any other oddities.
c) generally the compile/link options may be slightly different.

overall, Id not expect any issue… but id only did surface level testing… so ymmv.
(let me know if you spot any new oddities)

Not working; in AB LIVE also does not show up
Screenshot 2023-07-19 at 18.13.18

–With GP it seems to validate (shows up in Plugin manager) but does not run.–
Edit: the above not true - proper scan and its not listed nor validate.

So, the same as before, it does work if GP is put in rosetta mode.

edit2 - EigenCore stand alone is crashing, here is part of the report:

Termination Reason: Namespace DYLD, Code 1 Library missing
Library not loaded: @rpath/libpicodecoder.dylib
Referenced from: <37365039-AF8F-3823-9301-762570BAB47A> /Applications/
Reason: tried: ‘/usr/local/lib/libpicodecoder.dylib’ (no such file), ‘/usr/lib/libpicodecoder.dylib’ (no such file, not in dyld cache)
(terminated at launch; ignore backtrace)

I’ll take a look, as Im not quite sure what was released…

where did you put libpicodecoder.dylib?
it believe it would need to be in same directory as the vst3.

as for ECMapper, was this previous a vst3? did you rescan?
(it has no external dependancies, and worked in my test host when I tired it yesterday)

let me go have a look at my build, and I’ll see if its working.

I better do a clean test on the Mac Studio, this M1 MBP had previous instals… something fishy.

… nop, its the same:
Mac Studio -M1 Max

And this latest version is crashing Standalone EigenCore.

ok, my build is working :slight_smile:

I’ll throw you a copy to see if its working for you…
(one sec, just need to 'zip it up)

note: Ive only built the apple silicon version… so the native is cool.

and Im assuming green lights = good… as Ive not used ECMapper before :wink:

1 Like

(I have split the thread, was getting messy… hope its ok)

here’s my build…

try these… and let me know if they are ok for you too.

VST3s are called ECCO and ECMA

if these work, then @Kai can look to see what the difference is.

1 Like

Privacy & Security won’t let me go ahead… OPEN anyway, then asks for pass, but stays the same?
and so, no validation.

I had this with the very first version and other plugins?!?!?

Open Anyway :slight_smile:

its because they are not signed.

yeah, but its stuck there.

Meanwhile on Mac Studio: your version its not validated.

sorry, feeling like a newbie… this I don’t have on the Mac Studio.

Id have thought, after ‘open anyway’. if you restart the app (thats trying to use it) it should open…

what do you mean by validated? did you try to open in Ableton?
(thats the first step, as I dont have GP to test, with or know what its doing)

btw: its best to get ECMA working first, as it has no dependancies… once we no thats working, then we can move to ECCO.

ECMA always worked nicely