EigenD Linux Build

Thank you, Mark and others, for porting EigenD to Linux. It’s a great boon to me if I can get it sorted out.

I installed EigenD-gpl-2.1.7-community-x86_64.deb on my Mint 19.3 (18.04 bionic) music workstation, attending to the Linux installation notes, and ensuring Python 2.7 is installed. Upon launch, EigenD presents the “scan your computer for new or updated plugins” dialogue. I click “Perform scan”, and the console reports:

eigend: starting plugin scan…
writing /home/rory/.Eigenlabs/Plugins/plugins_cache_64
done.
writing /home/rory/.Eigenlabs/Plugins/bad_plugins_64
done.

And then the scanner process hangs, showing only a small blank black vestigial window. Is there a log written beyond that which is spooled to the console? Are there other resources needed by EigenD beyond those in the .deb package?

Thanks for any guidance you can provide.

Rory

No plugins would would not require anything else installed.

I half remember an issue with the scanner, that made it crash , but then EigenD would run next time ok - because it only runs it on first run.

But I didn’t have any Linux plugins to use , so was not really an issue for me, that plugins were not getting detected.

It’s was a bit strange though, as there is no specific Linux code required for the plugin handler - as it’s all handled by Juce.

I’m not got any dev time for next couple of days, but once I do - I’ll see if I can fire up Linux to refresh my memory in what was happening.

Do you have any plugins installed? (Not sure what is supported? Probably VST? No idea about Ladspa and LV2 - and what happens when those plugins are in the search patch. Also never used plugins with the Linux version of EigenD)

No plugin installed. Not even a path given to search. And same behaviour with each restart, suggesting the “yup-we’ve-run-the-scan” config state isn’t being set.

I ran the scanner as root last night, in case permissions were at fault. No good. Next step is to see what logging options exist for Scanner and, absent that, to build a debug version.

If you don’t need use plugins then killing scanner will mean next time EigenD starts it doesn’t scan again.
So only an issue if you want to use plugins.

I had a quick look ,

it appears to an issue communicating with sub process it creates ( scanner0) , though not had a chance yet to debug why that is.

It’s not to so with permissions and it also doesn’t appear to be to do with no plugins not being preset.

Btw: you can run the scanner on it’s own, which make it easier to debug.

Yes, looks like the parent process won’t recognize its child is a zombie after Scan is selected:

rory 29853 1.0 0.1 219892 13824 pts/1 Sl+ 19:21 0:00 ./scanner
rory 29862 0.0 0.0 0 0 pts/1 Z+ 19:21 0:00 [scanner0] <defunct>

If I instead select Cancel, then the main scanner process hangs, giving a ghost window frame:

rory 30033 1.2 0.0 0 0 pts/1 Z+ 19:30 0:00 [scanner] <defunct>

Running scanner stand-alone, or as launched by eigend, makes no difference: Every launch of eigend starts up scanner.

Looks like my next task is to build debug versions of scanner and scanner0, and start hunting. I’m new to SCons; will ‘scons debug’ in plg_host/src do the trick?

I built and installed Community 2.1.8, and the VST load went as intended - one and done. Loading a setup yields a list of plugin loading problems, though:

Opening Workbench confirms a number of plugins missing from the setup.

Have any of you encountered this before? I wonder if the wrong version of some library is linked.

Did you put them on library path?

Thank you! I missed that paths have to be added to LD_LIBRARY_PATH. Found a related discussion at Eigenlabs Forum. Created run_eigend.sh to add those paths, and the setup loaded successfully.

That post’s author also mentioned:

I missed your udev script. Once I had it installed, I could run the starter script with user permissions - which solved the issue that running it or the call to the binary with root permissions resulted in different errors.

Is this to modify udev rules so eigend can run at user level and write to a USB device?

Yepp, think that’s it. There is a description of these rules e.g. in the Arch wiki: udev - ArchWiki

Got the Pico firmware loaded (using the blue USB 3 port instead of a black USB 2 port was the trick), and the debug output shows keys performing their assigned function under the Pico Standard Setup.

No audio for the synth pad/bass/piano voices. For each of these, the logger prints “eigend: <sampler_oscillator1>: loader didnt find voice for vel=0.001[…] freq=[…]”, suggesting I’ve not set up reference to these Soundfonts properly. There’s extremely broken audio for the cello and clarinet voices, which I imagine are due to this old Core i3 processor running a bunch of other processes at the same time (even though the logged messages always proclaim “log:total audio dropouts 0 average tick […]”)

Getting there.

And still stuck with none of the sampler rigs generating audio. The Soundfonts are being found in sample_oscillator_1:

(I can’t chose a different one from the browse list, BTW), but that’s apparently not the same as the missing voice that eigenD logged:

image

What IS a recorder voice? Or is that a snark in this case?

Can anyone recommend a minimal Soundfont rig I can build to debug this? Guidance very much appreciated.

I compared the Windows Workbench 2.074 to the Linux 2.1.8 Workbench agent configurations pointed out in the previous message, and they’re the same. So I was hunting a snark after all.

On Linux, ~./Eigenlabs/Soundfont was missing all the *.sf2 files found in C:\Program Files (x86)\Eigenlabs\soundfont; I donwloaded them from the Eigenlabs site. But also ~/.Eigenlabs/ImpulseResponse and ~/.Eigenlabs/Loop are missing all the files present in the corresponding Windows folders. Were these all part of the Alchemy package?

No…

Here you have all the files

Just put them to work…
Hope this helps.

Thanks. Now I understand: There are only MacOS and Windows versions of these archives, not included in the community version of EigenD, and available only from the eigenlabs.com site. Unpacking these under Windows, and transferring Icons, Loops, ImpulseResponse and the added Soundfont files to my Mint box resulted in the Metronome now working from both Stage and the Pico metronome key. But still:

  • eigend must be started with both the --stdout and --debug flags for the Pico firmware to be loaded.

  • None of the default Soundfont instruments - piano, bass, synthpad - play from the Pico. Cello and clarinet work, although the control strip “bows” in only one direction for the cello.

Any thoughts on what might cause these behaviors?

Yeah, I don’t have access to the ‘source’ for the resources installer , so I’d have to rewrite - it’s also a massive file to host.
( also things like alchemy are defunct now)

No reason I can think of why debug/stdout should be required - perhaps a timing issue?!
(I don’t have this issue with MEC on Linux)

I seem to remember noticing that the convolution stuff wasn’t working when I tried on a rPI a long time back - but I assumed it was specific to that platform.
can’t remember if it worked when I tried it on my Mac with Linux.

Yes, I recall your writing about asking Eigenlabs for the resource installer source. From my brief research, one option to create cross-platform installers is to use VMWare’s InstallBuilder (I have no connections to the company), which offers free licenses to qualifying Open Source projects. Hosting a bit over 3GB does present a problem; perhaps a number of music-related sites could be convinced to host a sharded package, and an installer will download and assemble shards drawn from across multiple sites.

I too suspect the firmware loading problem is a timing issue. It’s independent of whether the Pico is plugged into a USB 2 or 3 port.

The convolution stuff is apropos the physical models like the cello, yes? If so, there doesn’t seem to be an issue loading convolvers:

image

My issue is with the three sampler rigs - no audio out. Is the Soundfont file used by a rig specified in an agent somewhere in the Pico Standard Setup?

And lastly, does eigenD write a log file, or does it all spool to stdout/stderr?

TIA for all your help, friends.

Correct. The impulse response files used in the convolution reverb to get the cello model to sound like a cello should be located in /usr/local/pi/impulseresponse. Without those in place, you’ll get sounds, but it’ll sound awful. Similarly the soundfont files need to be located in /usr/local/pi/soundfont. There are also user-level equivalents under~/Library/Eigenlabs/ on OSX (not used Linux, but it’ll be somewhere under your home folder).

Logs get written to files in ~/Library/Eigenlabs/2.1.7-community/Log.

Thanks. Not sure how I.missed the Log directory, but it contains logs that, while not telling of sampler rig failure modes, do tell tales of why eigenbrowser and eigencommander fail to launch properly. What versions of gtk and wxPython should be used with Community Edition 2.1.8?