EigenD Linux Build

Looks like EigenD pythoninstall has wx version 2.8.12.1, No idea about gtk.

I know on the Mac the EigenBrowser and EigenCommander no longer work. So you’re better sticking with Workbench.

1 Like

Mark posted in 2016 on the Eigenlabs developers forum an invitation for others to help upgrade eigenBrowser and eigenCommander to the wxPython Phoenix API. Phoenix was the first of wxPython-4.0.x series. I didn’t find any follow-up information on whether or not that was achieved, hence my question.

1 Like

No, I couldn’t get it working, i has various issues which i couldn’t track down , seemed mainly to do with threading and timing which I found very difficult to debug.

I’ve done various other experiments and tests for replacing eigenbrowser and eigencommander but never really had time/motivation to complete them, Partly because most of use have got around this by using workbench instead - and it’s a lot of work to get rewrite them.

1 Like

Ugh. Debugging threaded real-time stuff can be a slow march into madness.

What needs be done can be handled between Workbench and Stage, from what I’ve so far seen of each. But windows aren’t popping up from the editing buttons on Stage’s Drummer tab. Inconvenient, so gets my first attention.

2 Likes

Sorry to reanimate this corpse, but I’ll put this here in case it helps someone else. scanner0 seems broken on linux in community-2.1.7 (at least with python-2.7.18 which is the stock version in Ubuntu 22.04) but the workaround to prevent eigend from ever calling it (after you’ve run it for the first time and it hung and you killed it) is:

cp ~/.Eigenlabs/Plugins/plugins_cache_64 ~/.Eigenlabs/Plugins/plugins_cache
cp ~/.Eigenlabs/Plugins/bad_plugins_64 ~/.Eigenlabs/Plugins/bad_plugins

because it seems to be a little confused on the file naming somewhere.

There’s a similar naming problem with soundfonts, e.g. I had to do this to get the piano to load (a hint was in the logs):

(cd ~/.Eigenlabs/Soundfont && ln -s Black_Grand_Medium.sf2 'Black Grand Medium.sf2')

After that, I could more or less load a setup and get sounds to play, but there are quite a few problems that make it otherwise unusable (crashes, freezes, broken audio on cello/clarinet/synth, can’t browse for soundfonts via sampler buttons in stage, etc).

So… is anyone here regularly using eigend on Linux? I couldn’t find a branch, tag, or release of community-2.1.8 mentioned above. I do see a 2.2 branch in github. Not sure if I should go through the trouble of hand-building python-2.7.10 if it won’t make a difference.

1 Like

Same problem using official python-2.7.10 :frowning:

1 Like

this has been a known issue from the start , as far as I can remember… regardless of python version I tried.

the workaround detailed above, was only about how scanner failing would also cause eigend to hang, it was not a solution to scanner.

1 Like

Hi everyone!

Been a while since I posted anything, but the day job has kept me completely swamped for months.

I just thought I’d share that I built and tested 2.2.1 on ubuntu 24.0.4 realtime kernel, with gcc
14 and got it up and running, and it works quite well. So far no bugs other than the same weirdness with the plugin scanner that previous community releases had. Not entirely sure why scanner0 goes into zombie mode. But, I rarely use plugins, so I’ve pushed that aside.

Some notes for others that might want to do the same…

You’ll need python2 installed along with your python3, but it is not available in any repo for 24, and there are major problems with building from source from python.org. In effect, it will build with some effort, but it simply won’t play nice with pretty much anything. It will crash on memory allocation on startup.

So you’ll need to install these specific from the repos from ubuntu 22.
libpython2.7_2.7.18-13ubuntu1.4_amd64.deb
libpython2.7-dev_2.7.18-13ubuntu1.4_amd64.deb
libpython2.7-minimal_2.7.18-13ubuntu1.4_amd64.deb
libpython2.7-stdlib_2.7.18-13ubuntu1.4_amd64.deb
python2.7_2.7.18-13ubuntu1.4_amd64.deb
python2.7-dev_2.7.18-13ubuntu1.4_amd64.deb
python2.7-minimal_2.7.18-13ubuntu1.4_amd64.deb

of course, set up your alternatives for python so you can switch between 2.7 and 3.12 (current)

There are some code changes that need to be made in your git checkout to SCons, and Juce core, namely disabling -Werror, and disabling curl for Juce.

GCC 14 is SUPER picky about warnings, and they’re all over the place, and if you try to build with -Werror, it’s probably gonna be a bad time. Bottom line, is some stuff is deprecated that worked with no warnings before, but now generates a ton of warnings, and -Werror treats warnings like errors.

and for whatever reason, the Juce framework simply will not link wit libcurl if you have it installed. The linker just won’t do it, and fails but with no other output, so I cannot tell why. Likely there is something in Juce that requirres a specific older version of libcurl.

However, it is not at all necessary, as the library falls back to manually managing net calls. So you can disable that feature.

With the above, it builds and runs like a dream.

I can share my changes to anyone that might need them. May save you some hair pulling.

Also, I’ve been working on and off on updating the python dependencies to work with 3. I still have a ways to go, but my early testing has been very postivie. I’m hoping that in the next month or so, I might be able to provide a python 3 compatible version. The conversion is actually fairly straightforward, but there is a LOT of it. So it’s taking a bit of time, as I don’t have a great deal of time to dedicate to it.

BTW, I’ve found GPT invaluable in refactoring in a lot of cases. It’s definitely a bit messy and will miss important things, but it can do 70% of the heavy lifting. You just gotta get used to the kinds of bone-headed things it’s prone to.

Anyway, I hope everyone has an amazing holiday season this year!

Many happy mandarin oranges!

5 Likes

Yeah each time I work on EigenD I have to make changes to reflect more modern compilers.
Also different platforms have slight differences too.

Also what I usually do is update juce to the latest version.

Python 3, yeah I did some work on that too ( think there is a branch?) … as you say the issue is, it’s a lot of changes - and unfortunately, for a lot of it, you can’t do a bit test and then do some more.
That makes me very nervous - given some of the way EigenD uses python - compiling is very much only first step.

FYI, I once upgraded eigend to a later version of 2.x , it compiled fine - but I got a hard lock on startup , between ui and audio threads.
Seem to be due to the changes in the memory manager … so I suspect this may be present in python 3. :frowning:

I’m also very wary of using tools to do the refactor … there is so much code, if you don’t do it manually , and so know the changes made … finding a problem/bug will be like looking for a needle in a haystack.

So yeah I started this a couple of times but after a few days got a bit tired doing it.

I’d also love to get rid of Scons, replace it with CMake … but I’d have to delve into the pip creation a bit … not sure if cmake has some support for this.

Anyway good to see someone else having a crack at this. Let me know how you get on.

2 Likes

Will do Mark!

And yeah, tools to do the refactor are always dodgy in any project, but after using GPT4 for some of our complex internal stuff over the last year, and seeing how good it was on some things, and getting to know some of the common issues it makes, I thought… why not kick the tires on this and see. Worst case, it doesn’t work with python3, which is where we already are. LOL.

But yeah, it’s a lot of work to double check everything and make sure interfaces between modules still work.

But, so far, there’s been nothing insoluable, as long as one doesn’t assume the output of tools is going to be good. It’s at best a 70% solution and requires careful review.

I think it might be doable TBH, but time will tell. :slight_smile:

Happy holidays!

2 Likes

yeah, Ive been using things like copilot, and generally, they can be pretty good.

but the one thing Im cautious about, is they have a habit of creating ‘compilable nonsense’ :slight_smile:

… it not be so bad, if when they made a mistake it obviously failed (didn’t compile).
but like a lot of AI, it creates results that are plausible (and compilable code) but are incorrect.
(ofc, humans do this too… but they have to take responsibility for this mistakes :laughing: )

then again, perhaps this problem space is known well enough, it might fair better.


one thing to bare in mind, the python code in EigenD is tightly coupled to the C++ code via the generated pip stuff… theres not really that much pure python.
(k, there is a lot, as its in every modules etc, but it doesn’t do much, mainly its interfacing code)

also I assume your focusing just on the core EigenD?
Id not bother with the python apps (Commander/Browser etc), they have been defunct for quite a while… so definitely a low priority (in my opinion)

anyway, im really interested to hear how you get on with it.

on my last attempt I did take some notes about the changes I was making, so those might be useful to cross check… and also to see what changes have been made.
I was particularly nervous around async and tp_as_async / lock_c2p

looking back at my notes, I think I was pretty close last time - I did have some things running
but I just lost motivation, after doing it for a week or so.
fortunately, I knew this would happen hence my extensive notes - so I could pick up later :laughing:

see

then python_dev_*,md

2 Likes