EigenD - Apple Silicon - It lives!

Not true; Clarinet IS work…

2 Likes

Great to know! also because of your “moves” !!

1 Like

ah, i thought clarinet was using convolver - obviously not :slight_smile:
( I guess that makes sense really, as a clarinet does not have a ‘body’)

cool, thats good to know!

1 Like

i thought the cello used to work if the convolution files were missing (just sounded awful)? But maybe if the fft code is also missing there’s an exception thrown?

ok, fixed workbench crash…
(it seems to be a bug in latest juce - so workaround can hopefully be removed later)

Ive started to look into updating fftw (for convolver),
but its a little complicated due to the way it was ‘imported’ into EigenD build - but I believe Ive got a rough plan of action.

edit: oooh, this really first time Ive really sat down and played with the Eigenharp with Live 11 (since release) - wavetable with eigenharp mpe is really rather lovely :heart:

3 Likes

ok, updated top post with links to a pre-release for both apple silicon and intel x86_64

its useful to test the x86_64 version since this is a new version of juce, and also using the ‘system python’, which means it has none of the pre-requisite/install steps of previous experimental version.
also this has been ‘cross-compiled’ on an M1 (which is cool) , so useful to know there no issues there.

note as stated previously, for mac os , new requirements are:

macos or macos 10.13+
apple silicon or intel 64 bit (no 32 bit support)

2 Likes

@NothanUmber , do you have a windows build environment for EigenD?
if so, could you try to build and package my 2.2 branch (it should just work).

I’ve just remembered, my f’ing windows machine corrupted its hard disk a while back, so I had to rebuild it - that means to build EigenD on it is going to mean installing a ton of stuff on it (I dont even have EigenD runtime on it)… which is going to be a lonnng painfful process.

if you dont have a dev env, don’t worry - I’ll do it at some point, its not terribly urgent at the moment.

Chime in here with proof - it Lives !! twice !!
Big thanks to the one and only @thetechnobear !! congrats :confetti_ball:

and

3 Likes

Not anymore on the new Windows machine but I can install stuff again. (Probably at the weekend)

I tried the 2.2.0 mac arm installation package on a Mac mini M1.
macOS 11.2.3, Rosetta is installed, Eigenharp Pico.

Downloaded package and installed, did not scan VSTs.
Started EigenD, did not scan VSTs.
Default setup pico 2 loaded.
Loaded pico standard setup.
Crash.
Disabled SIP, had to fight a little, but computer seems ok now.
Installed package again, just in case something went wrong with active SIP.
Started EigenD, did not scan VSTs.
Default setup pico 2 loaded, LEDs ok, no sound, no MIDI out.
Pico standard setup loaded, LEDs ok, no sound, no MIDI out.
Opened Workspace and clicked some objects.
Crash.

Process:               eigend [716]
Path:                  /Applications/Eigenlabs/*/EigenD.app/Contents/MacOS/EigenD
Identifier:            EigenD.app
Version:               2.2.0-community
Code Type:             ARM-64 (Native)
Parent Process:        ??? [1]
Responsible:           eigend [716]
User ID:               501

Date/Time:             2021-04-14 19:36:33.841 +0200
OS Version:            macOS 11.2.3 (20D91)
Report Version:        12
Anonymous UUID:        0E9D5294-8D1F-504A-ED81-66FE681D38D2

Time Awake Since Boot: 670 seconds

System Integrity Protection: disabled

***Crashed Thread:        11***

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called
terminating with uncaught exception of type (anonymous namespace)::pip_err_t: call problem
...
...
...
***Thread 11 Crashed:***
0   libsystem_kernel.dylib        	0x00000001a2564cec __pthread_kill + 8
1   libsystem_pthread.dylib       	0x00000001a2595c24 pthread_kill + 292
2   libsystem_c.dylib             	0x00000001a24dd864 abort + 104
3   libc++abi.dylib               	0x00000001a2555cf8 abort_message + 132
4   libc++abi.dylib               	0x00000001a2546e34 demangling_terminate_handler() + 284
5   libobjc.A.dylib               	0x00000001a243f6d8 _objc_terminate() + 160
6   libc++abi.dylib               	0x00000001a25550e0 std::__terminate(void (*)()) + 20
7   libc++abi.dylib               	0x00000001a255506c std::terminate() + 44
8   libpiw.dylib                  	0x0000000104ce5ae8 piw::canchor_t::impl_t::~impl_t() + 28
9   libpiw.dylib                  	0x0000000104ce6134 piw::canchor_t::~canchor_t() + 36
10  piw_native.so                 	0x0000000108b9cf84 (anonymous namespace)::canchor_wrapper_::~canchor_wrapper_() + 32
11  piw_native.so                 	0x0000000108b9c61c (anonymous namespace)::canchor_delete_((anonymous namespace)::canchor_object_*) + 104
12  piw_native.so                 	0x0000000108b9c3e8 (anonymous namespace)::canchor_dealloc_((anonymous namespace)::canchor_object_*) + 20
13  org.python.python             	0x00000001048fce74 0x1048c0000 + 249460
14  org.python.python             	0x0000000104921b4c 0x1048c0000 + 400204
15  org.python.python             	0x000000010498723c 0x1048c0000 + 815676
16  org.python.python             	0x00000001049879f8 0x1048c0000 + 817656
17  org.python.python             	0x0000000104956160 PyEval_EvalFrameEx + 19728
18  org.python.python             	0x000000010495a860 0x1048c0000 + 632928
19  org.python.python             	0x00000001049560b8 PyEval_EvalFrameEx + 19560
20  org.python.python             	0x000000010495a860 0x1048c0000 + 632928
21  org.python.python             	0x00000001049560b8 PyEval_EvalFrameEx + 19560
22  org.python.python             	0x000000010495a860 0x1048c0000 + 632928
23  org.python.python             	0x00000001049560b8 PyEval_EvalFrameEx + 19560
24  org.python.python             	0x0000000104950e30 PyEval_EvalCodeEx + 712
25  org.python.python             	0x00000001048edb10 0x1048c0000 + 187152
26  org.python.python             	0x00000001048cbf3c PyObject_Call + 128
27  org.python.python             	0x00000001048d7ac4 0x1048c0000 + 96964
28  org.python.python             	0x00000001048cbf3c PyObject_Call + 128
29  org.python.python             	0x0000000104959f5c PyEval_CallObjectWithKeywords + 208
30  org.python.python             	0x0000000104988eb0 0x1048c0000 + 822960
31  org.python.python             	0x0000000104984408 0x1048c0000 + 803848
32  libsystem_pthread.dylib       	0x00000001a259606c _pthread_start + 320
33  libsystem_pthread.dylib       	0x00000001a2590da0 thread_start + 8

dont worry, I will have to install it anyway to reconfigure fftw


@peter_ostry , I did not say to disable SIP, its compleletely unnecessary.
(Rosetta is not required - but wont make any different)

your crash report , Ive no idea what you did… so cant interpret it, there is nothing useful in that stack trace.

to test, I need you to follow instructions that I have given, nothing more, nothing less.

I do not want people jumping to conclusions about what they think they should do,
thats just going to lead to confusion.

as for the original issue … about scanning vsts
what do you mean it ‘did not scan vsts’ ? did it not report any? did it crash?

have you installed any VSTs that support apple silicon.
as I clearly stated, this will not (and never will) load intel vsts, only native/universal binaries.

as for no sound, no midi out…

you wont get any by default from the samplers (again as pointed out) the samples are not included, you will need to copy over samples to the relevant place.
(this is NOT a final release!)

midi… where did you look?
by default, it will create virtual midi ports, so in a daw you should see these.
this worked for me with ableton and bitwig, including mpe
(which by the way is not enable in factory setup)

2020 MacBook Pro with Catalina. Tested Alpha with my standard setup. Midi only into GigPerformer. Fairly complex for a midi setup (multiple midi devices out, talkers using belcanto to “rewire” stuff, splits, many key groups, etc. Everything seems to be working fine.

  • Workbench seems to work perfectly
  • Quits fine (I used to have to force quit)
  • Works after hibernation/lid close - open again (used to have to force quit and restart)
  • Tried to start EigenD before connecting USB. Still worked.
  • If I disconnect USB and reconnect while EigenD is running Alpha doesn’t reconnect to EigenD. (Alpha keyboard agent doesn’t reappear in Workbench). After that, does not quit properly (I have to force quit).

I’ll give it a “stress test” over several hours with my Tau when I’m next at our rehearsal room. But so far all features I am using seems to be working great!

2 Likes

odd… I cannot reproduce here… tried on my m1/big sur.
with EigenD running and connected to alpha.

  • power off/on basestation - reconnects
  • disconnect basestation usb, plug it back in - reconnects

in fairness, nothing has really changed here - I’d suspect we are seeing quirks with macos (again!), apple are always playing about with the usb stack - actually behaving best that ive seen for a while :slight_smile:
(so, I suspect more likely big sur/catalina - than anything to do with eigend or intel/m1)

I’ll have a go on my mbp/mojave , see if I get similar there.

the fact you had issues before, even if diferrent results, leads me to similar conclusion - i dont think I had any issues when on mojave.

that said, I stopped pulling out usb cables etc around 10.10 (?) , since macOS used to die a horrible death with a kernel crash… so, I got very careful about doing things like closing EigenD before turning off Eigenharp!

2 Likes

“I do not want people jumping to conclusions about what they think they should do, thats just going to lead to confusion.”

Sorry. Just wanted to help.

@peter_ostry cool, no worries
the fact your leds are showing, means the pico is working.
the easy next step is to check for the midi… I can see no reason why that wont work.
(Ive tested pico factory setup here… and worked fine, I think @keymanpal has as well on another m1)

@Kai

I just tried with my MBP/Mojave, it also doesn’t have an issue with usb disconnection or power cycling the basestation.

are you using a basestation pro , or the smaller one?
(Im using the pro… but I guess I can try with the smaller one, though seems unlikely to make a difference)

also can you try with the alpha factory 1 setup, rather than you custom setup.
so we can eliminate your setup from enquires :slight_smile:

other than that, Im back to thinking perhaps a Catalina issue?!
(anyone else running Catalina - do you get same issue?)

perhaps you can also send me the eigend log
do as little as possible to invoke the issue… to keep log as small as possible.

also rather than force quit,
start the ActivityMonitor
then select process, then menu → Sample Process
then save the ‘sample text’ (this gives me a thread dump)
you can then send that along with eigend log

the other thing you can check, about this mac, system report , usb
… check that when you have plugged the basestation back in, check that it has appeared
(note: this panel does not dynamically update, you refresh with cmd+r)
copy me the base station info, after you have plugged it back in

if its present, then for some reason EigenD is not seeing it, or is getting stuck ( I suspect this is the case)
if its not present - then macos is for some reason not seeing it.

Installed the toolchain again and got it to build. Haven’t tested much, but EigenD, EigenCommander, EigenBrowser and Workbench seem to start.

A not so optimal detail: The Steinberg VST2 SDK that can still be downloaded only contains the public.sdk, not the plugininterfaces anymore. Still found a backup copy of the original files but this might mean trouble for future builds…

Edit: Nevermind, found the problem (scons assumes the binaries in $WIX/bin - by default the binaries are directly in the wix root folder, moving them does the trick)

http://fstrixner.de/files/EigenD/binaries/2.2.0_2021-04-15/EigenD-gpl-2.2.0-community.exe

I use the vst3 sdk, it contains vst 2

Was also downloading this: https://www.steinberg.net/vst3sdk
It still contains some VST2 sdk stuff:

VST2_SDK
–public.sdk\

My old copy had this though:
VST2_SDK
–plugininterfaces
–public.sdk
–VST_License_Agreement.pdf

looks like they just moved stuff around a little.
the copy_vst2_to_vst3_sdk.sh script seems to sets it up the same as it used to be.
(Ive not run it but visually, looks like it would be ‘correct’)

I’ll try tommorow, not a bad idea to check the latest vst sdk is working

steinberg are doing this since vst 2 is not GPL compliant - so really all open source projects should only be supporting vst3 not vst2 anymore.

I should check to see if we can make eigend host vst3 plugins,
most modern plugins are now available as vst3 versions.

Ok, please double-check. Thought that the old copy script copied vst2_sdk/plugininterfaces to vst3_sdk/plugininterfaces/vst2.

Vst3 support would of course be nice!
Are they using Juce for plugin hosting?
If yes then the switch might come almost for free?