EigenD - Apple Silicon - It lives!

Eigenharp
6

Here is Apples stance:

Scripting Language Runtimes

Deprecations

  • Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
  • Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)

https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes

So - perhaps it might not be worth to spend too much effort into trying to use the on-board Python but bring the Python that we need with us in an installer? Then it would be in our hands what to use.

7

If I understand this page correctly, then 3.9.1 is the first Python that runs natively on M1 silicon and thus 2.7 runs in Rosetta anyways? Which would mean for a native build we’d need to get it to run with Python 3 anyways(?)

8

yeah, thats all expected…
but lets face it, the reason Apple are including 2.7 is they know, lots of bigger customers are using it.
my suspicion is… they will continue to include it until suddently they hit a technical issue that means they can no longer do it (without a big engineering effort)

but for sure, you never know with Apple,
they routinely will just annouce ‘this version no longers supports X’ :slight_smile:

anyway, as above, its not that I have not looked at moving to Python 3, or even at removing Python all together - but unfortunately its not that simple.

every module includes a python interface, which has a significant amount of code in it,
code that cannot just be automatically ported, but would have to be understood and re-written.

it also goes deeper than that, many parts of EigenD code only exist in Python
(e.g. even for MEC, I had to re-write some python code that uploads firmware into c++)

I was actually looking at this 2 days ago… and it really became clear, Python is here to say in EigenD…
it would be easier to re-write everything, than to extract it :frowning:

my belief as stated previously is really two long-term directions…

a) EigenD
remove any UI dependancy on python, leaving only the module interfacing
move to python 3
hopefully this means EigenD is not dependent on any other python packages.

b) MEC / EigenLite / Similar
pure C++ no dependancies, modern tool chain, that can be easily maintained going forward by anyone.
(this is partly why MEC and EigenLite are separate - to give multiple solutions)

1 Like
9

Architectures in the fat file: /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2 are: x86_64 arm64e

anyway…

kind of the point of this thread is to move away from (my own) speculation/assumption,
and actually start trying things out so we can get to some solid experience of what is needed for this to work.

obviously the goal is to try to do this in baby steps if possible.
its easy to just say , convert it to python 3, compile natively.

but I already know that move to python3 is problematic, and will take a lot of dev effort.

2 Likes
10

Moved my posting to Some future Eigenharp software thoughts/fantasies to keep this thread on topic.

2 Likes
11

that seems like sometihng to discuss on this topic…
https://community.polyexpression.com/t/some-future-eigenharp-software-thoughts-fantasies

you are totally correct, we all have limited time - so I have to allocate my ‘dev’ time to whatever will be most fruitful to most users.
that is part of my hope is that MEC/EigenLite is much simpler for other devs to get into, thus reducing the dependancy on one single developer (me) - that is something we can explore in the above topic.

however, I do think that EigenD has alot of functionality, and that some users would really miss it. so, Id really like to not ‘abandon’ it unless it becomes obvious its a huge time sync - which im hopeful its not. (*)

anyway, perhaps lets use this topic to focus on EigenD on Apple Silicon, either via Rosetta or Native :slight_smile:

(*) again, Im trying to manage expectations here… there are complications with EigenD/Python versions - its not trivial. however its not all doom n’ gloom, its quite possible that I will have a ‘break-through’ and suddenly things will fall into place, and then progess will be rapid.

so, my main issue is… just its a bit of an unknown time sink… last time, I spend a few days and didnt get far - but who knows, I could have just been a few hours, or days (or weeks!) off the breakthrough I need.

(my main mistake was leaving it, I should have just thrown a few hours at it , here and there… thus limiting frustration, but still made progress)

2 Likes
12

ok, first … Ive edited the ‘try in Rosetta’ post…
as Ive realised for this experiment we do not need any python packages…
(they really are only needed for EigenBrowser/Commander which wont work anyway)

BUT… the better news is this…

Screenshot 2021-04-11 at 17.44.17
Screenshot 2021-04-11 at 17.44.173439×1440 609 KB

I’ve managed to compile ALL of EigenD natively on Apple Silicon. (*)
everything seems to run, arm vsts are even loaded !
logs actually look surprisingly healthy.

Ive not plugged in an Eigenharp yet… thats my next step, but looking hopeful given my mec tests previously.

you can see a few graphic anamolies in the UI.
not sure, if this is big sur/m1 related, or possibly even my monitor
(Im using a very wide screen resolution… might try something in normal aspect ratio)
my suspiscioin is a new version of Juce will probably fix that (**)

(*) the only module that is not compiling is the convolution engine, and due to to needing a new version of the fftw library, which supports NEON as well as SSE,
I’ve done this on linux, so it should not be a massive move, to change this on macOS.
really its just about building the lib, since on linux, I just make it a dependency, as it always installed anyway.

(**) its quite a ‘jump’ from where we are - to the latest juce version… so that might cause other issues, so its a bit on the back burner, I’ll look at it once Ive tested hardware is working!

2 Likes
13

holy smoke…

IMG_0657
IMG_06573024×4032 1.82 MB

its working… and running exceptionally too…

Ive got midi coming out, and the synth rig is playing with its reverb - very little cpu!

vst host is not working yet, but given they scanned - Ive a suspicion i know what the issue is…

simple performance test …loading alpha 3 setup

mac mini m1 - 1 min 43 seconds
mac book pro i7 2.5ghz - 3 min 26 seconds

twice as fast !!!

lets remember this is really not showing off the M1, since the M1 does NOT shine in single core performance - its the fact it has 8 cores (4 performance, 4 eco)

in practical terms, this means the Mac Mini M1 will really shine if you want to run EigenD , and then have a Daw/GigPerformer also running on the same machine - since it has a ton of resources left over!

@keymanpal , given this is basically working… there is no real need to test under Rosetta.
I need to check the packaging/install process is working , and fix the vst hosting.
once thats done I’ll get a copy of this native version over to you

6 Likes
14

Great awesome news!!

1 Like
15

Im on a roll today…

VSTs are now working, and also fixed the packaging… so feels fully functional.
so its ready for those brave enough to play :slight_smile:

Ive a feeling, I will need to update Juce before this is ‘released’ in any kind of public form, but if you are familar with EigenD and have an M1 to test on send me a DM and I’ll supply a link (sorry this is not the release to ‘learn eigend with’) - just about to send it to you @keymanpal !
you do not need to do anything, other than install the package - hopefully it should ‘just work’.

vsts - we can only host native arm plugins.
amusingly, the only ones I had installed were the ones I had developed :slight_smile:
but I then went and found that u-he, vahalla and modartt (pianoteq) , all have eleases or betas of thier plugings…

all of these appear to work when I tried :slight_smile:

known issues:

  • I think the graphics library we use (juce) is struggling a little , probably more with Big Sur than the M1.
  • convolver missing - so thing like cello will not work

limitations: (aka unlikely to change)

  • can only host ARM plugins
  • eigen commander/browser will not work
  • you’ll need to copy samples manually etc if you want to use these.
    (I do not really recommend installing eigend resources pkg which contains these)
4 Likes
16

Late to the party here, but that’s awesome work Mark!

1 Like
17

Pico and clean install is working - thanks to the intrepid @keymanpal for testing this :slight_smile:

this morning, Ive also tested the Tau (and Pico) and can confirm this is working too.

1 Like
18

– test for longer sessions, check stability
I find it quite stable, playing, interacting with instruments.

– drummer/sampler - need to load some samples.
WORKING great! (just drop files manually)
**Clarinet is also working **
NOT Cello (not sure why - convolution?

– headphone output (tau/alpha)
OK!

– mpe for midi
In a similar way to VST (tested with Arturia Pigments in Stand alone mode

– mpe for vst plugins
It was one of the first things I’ve tried using “SURGE” - pitch bend, matching 48 in both
EigenD and Surge, but needs more testing

M1 MacBook Air (16Gb ram version)

Loading times:Alpha - Factory Setup

  • 39s - 1 Split Standard Setup
  • 45s - 2 Split Standard Setup
  • 81s - 3 Split Standard Setup

STAGE on iPad 1 - StIlL works nicely :wink:

2 Likes
19

@keymanpal to confirm you think mpe is working ok, on plugins and via midi? (at least with basic testing?)

yes, cello and clarinet will not work, since they use convolution - which is currently disabled.

1 Like
20

phew - that took longer than expected BUT…

EigenD is now running on the latest version of Juce (6.0.8) - this seems to have got rid of all of the graphics glitches. yay!

only one minor issue when I shutdown Workbench I get an exception which I need to look into, but this does not affect functionality.

@keymanpal , sending you a copy now :slight_smile:

2 Likes
21

Not true; Clarinet IS work…

2 Likes
22

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

1 Like
23

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
24

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?

25

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