Native arm version - testing EigenCore/ECMapper

I don’t have AB Live on the Mac Studio …
This is GP

I install back yesterday version, the one that EigenCore Standalone works… and your ECCO, but no go.

Im currently trying to get my MacBook to use them in Ableton Live…

but facing the same ‘open anyway’ issue as you… I need to find a way to be able to get past this.

1 Like

It is supposed to look for it here (i.e. the Frameworks folder in the bundle):

otool -L libpicodecoder.dylib

show the @loader_path as expected at my end, but I bet that if I did the check on a silicon Mac that it would show @rpath/libpicodecoder instead. So that is probably why my attempt at a quick fix failed. Should be easy enough to fix, though. I’ll give it another go…

EDIT: this is the fix attempt I did before merging the PR.

1 Like

yeah its all to do with the rpath…

on my local build, Ive found its linked to a copy in my build directory :slight_smile:
which is why it was working on one Mac but not the other.

more details

otool -L ECCO.vst3/Contents/MacOS/ECCO
@rpath/libpicodecoder.dylib (compatibility version 0.0.0, current version 0.0.0)

which, I think should be good…

otool -l ECCO.vst3/Contents/MacOS/ECCO
Load command 37
cmdsize 96
path /Users/kodiak/projects/3rdParty/ECMapper/build/EigenLite/eigenapi/lib_picodecoder (offset 12)

not good :slight_smile:

I think what needs to be done is…

inside EigenCode/CMakeList.txt, this needs to set the RPATH… to wherever you are putting the dylib



For this test I’ve set @loader_path for both the x86 and the arm64 pico decoder, and then added the arm64 to the x86 one with lipo -create.

1 Like

Going to give it go… 1sec.

@Kai YEP !! working !!
(this on Mac Studio

ummmm but standalone does not light up green…


Closer look to install, drag n’drop to Documents seems locked, so not working.
Its not clear - a + sign appears and holds, but files aren’t copied to destination.
(I already had files from previous instal /shared some other way)
Jul-19-2023 23-10-40

1 Like

Huh? Now, that is super weird. …or, one thing I can think of is that there can only be a single instance of Core running. A second would not show any lights. Could the VST be running at the same time?

Ohh so sorry, yeah I left GP running, changed desktops while going for the standalone bahhh…

Whoho! So, a working native arm version, finally! :smiley: Thanks a lot, both of you!

I’ll update the installer… but not tonight. :slight_smile:

1 Like

Yep ! it IS working nicely! thanks Kai :wink: and Mark :wink:
I got scared with no MIDI messages from Pico, saved GP session open back all is good !!
Midi, sound…
Jul-19-2023 23-37-02

Sure ! Have a good night :wink:


…and installer is updated (with the exact same files you tested).

(Thanks for catching the drag&drop-thing for the folders, btw. Apparently that was the wrong approach. I can’t have a single installer with both system and user paths, hence the manual approach. But after a bit of googling I realize that an alias to the Documents folder isn’t going to work either (it will point to MY user folder). Ah well, plan for next time: two installers - one with the apps that go to the system folders, one for “extras” that go to Documents.)

In case you have a use for them - the Gig Perfomer files are:

  • Panel/Global rackspace for EigenCore (with the lights and a manual shutdown switch since GP doesn’t shut down EigenCore cleanly - I don’t think this is “my fault”, since Cubase and the Juce pluginhost do a proper shutdown.)
  • Channel constrainer Scriptlet preset for isolating a midi channel range (when using two zones, for instance)
  • A scriptlet preset that sends program changes from Mapper to “Local GP Port” so that you can change rackspaces with keys.

I like to have a dedicated rackspace for song selection. I hit a key from any racksapce to send me to song selection and then pick the rackspace I want from there. Feels very similar to the “EigenD” way of doing things.

1 Like

Awesome work! Let’s keep pushing…

I’ll install on MBP M1 later today :wink: I need some Tea.

so @Kai, I had a look at this for the CMake build, and ‘half fixed’ it.

Ive sent you a PR

the change is simple enough:

to EigenCore/CMakeLists.txt

  ## setup rpath for linux and macos
    message("adding Frameworks to rpath")
    set(CMAKE_INSTALL_NAME_DIR "@rpath")
    set(CMAKE_INSTALL_RPATH "@executable_path/../Frameworks;@loader_path/../Frameworks")

all looks good…

 % otool -l ~/Library/Audio/Plug-Ins/VST3/ECCO.vst3/Contents/MacOS/ECCO |  grep -A 2 LC_RPATH
          cmd LC_RPATH
      cmdsize 48
         path @executable_path/../Frameworks (offset 12)
          cmd LC_RPATH
      cmdsize 40
         path @loader_path/../Frameworks (offset 12)
%otool -L ~/Library/Audio/Plug-Ins/VST3/ECCO.vst3/Contents/MacOS/ECCO | grep picodecoder   
	@rpath/libpicodecoder.dylib (compatibility version 0.0.0, current version 0.0.0)

but I say its only ‘half’ working…
as whilst ECCO loads correct in my test host and Bitwig.
for some reason Ableton refuses to scan it

Im not sure, sure why… as yesterday, it was working, with incorrect path.
(and ECMA and all my other plugins are fine with ableton)

any idea?


Yeah, both the standalone and VST3 version should have a Frameworks folder in the bundle (Contents/Frameworks). In XCode there was a build step to copy the dylib into /Frameworks.

I’ll read up on how to do it now… (I pushed some small CMake changes btw, naming etc mostly + changing the VST3 SDK path (I didn’t have SDKs/Steinberg…, so pointed to the JUCE one)

Edit: I see a scripts/ that copies libpico_decoder_arm64 so that looks relevant…with wrong vst filename commited right now, but I don’t see where/if it is being called. I bet that was what was working yesterday? I tried updating the filename of course, but that alone didn’t seem to do anything.

1 Like

Confirm its working with latest build, installed on MBP M1Pro 2021 - Ventura 13.4.1, all good!
GP and AB Live = plugins are validated and show up.

1 Like

Yeah I added that (manually) otherwise it wouldn’t work in any host :laughing:

Ah, right. :slight_smile: I just tried a variant of the same at the end of the EigenCore CMakeLists.

add_custom_command(TARGET EigenCore_VST3

The plugin runs fine in Gig Performer (and the Frameworks folder with the dylib is there), so I committed it, even though it is just the x86_64 pico decoder for now.


On hols and away from all my hardware, but just wanted to drop a note of thanks to you all for the work your putting on this!