EigenPI 2020 on Pi4 4GB

Eigenharp
1

OK… So…
I am looking to get my rPI4 4GB setup as the complete (or as complete as we can) EigenD with samples VST and anything else we can get working.
I have gone over LOADS of forums and posts … all to the point where I can get the EigenD to load up but not control the TAU or load any soundfonts or patches. ( and I have no idea where to install any of these as there is NOTHING but MACOSX and windows directory path info) . I know how old all of this is and iam not holding up much hope of a response.

Power wise my Pi4 is better then my 2010 MAC I ran the original EigenD on. Please if anyone has created an Image for ANY of the Raspberry Pi boards I would be in your debt. Thank you for any help given. P.S. I am a programmer and so can follow or figure out much . so need not be afraid of “going over my head” :wink:

2

there is a rPI release on:

i assume to get it running you read this
https://github.com/TheTechnobear/EigenD/releases/download/community-2.1.7/releasenotes_updated_v2.1.7c.pdf

did you get the tau to appear in eigend?

I’d personally recommend you run on something like patchboxOS (blokas) unless you know how to tune a linux distro for audio use - but some of this is covered iirc in the above pdf (thanks to @Kai)

once you have eigenD running you use open library to see where soundfonts/setups are loaded from.

iirc on linux this is ~/.Eigenlabs/
setups would be in ~/Eigenlabs/2.1.7-community/Setups
soundfonts would be in ~/Eigenlabs/Soundfonts

note: you would have to grab any resources you wanted to from a pc/mac since they are not available as a separate download … that said, really only the loops/soundfonts are useable - and ive not bothered with these for a long time :slight_smile:

rPI4 good point, ive not tried EigenD since the rPI3b - where it was ‘ok’, but not really performant.
the rPI4 is a good step up, but my gut feeling is I doubt it’ll work well with the factory setups, but perhaps scaled back setups could be good… but definitely worth trying.

note: iirc correctly, i disabled the convolution on the rPI, as there was incompatibilities in the libraries used… so things using that, like the cello will not work … but thats a vague memory, so just a heads up.

btw: please stop using CAPS, this in forums this is considering shouting, and i personally do not appreciate being shouted at :wink:

3

Sorry about caps. Ill try and use italicised to express important words. But don’t take offence thanks
On another note I think running on the Seeed studio x86 ii (4GB / 64GB SSD) maybe a better option . Then dropping a 5inch LCD on the header pins for video/touch. What do you think? Too low powered cpu? Thanks for your input.

4

On a side note, I believe Surge (A free, open-sourced, nicely spec’ed MPE-synth) compiles for ARM now, so perhaps that hosted in EigenD on rPI4 is a possibility now? I haven’t really investigated, so no clue if it is realistic or not.

I remember seeing plans for making Surge able to run without a UI, but I don’t know if that work is done. I’ve just kept half an eye on the release notes thinking it would be interesting to try rPI4 with MEC and Surge headless when/if it happens.

Edit: apparently it can run headless already.

1 Like
5

Good news is my PC setup is still working 100% (latest Win 10) and the TAU sounds great still. So on ward to a mini PC setup with integrated touch screen. (rPI4-) I have gotten to the point everything loads but every time i load any Setup thats not ‘basic - empty’ it crashes about 3/4 of the way .
Might give up on rPi4 as I have all the Windows software working.( plus tons of VST’s)

6

possibly, honestly its hard to know without trying…
the main thing to bare in mind, is its not just EigenD… its also how much cpu your plugins or daw or whatever is going to use

I think Ive got MEC running on a rPI4… I say think, as I lose track, but the RPI4 is sitting in my FATES case, and I pretty sure I had it compiled running there.
but saying that MEC, is ok on the rPI3b too… as thats whats in the Organelle-M.
(thats why I used at our last get together for ‘powering’ the alpha :slight_smile: )

in both these cases, I tend to either:
a) run PD instruments for sound
b) send data out either as OSC or MIDI MPE.

although (a) works, I generally prefer (b)… given the price of the rPI, a multi box setup seems like a nice way to distribute the load a bit :slight_smile:

so this approach might be a good one with Surge if its resource heavy.

7

I’ve used various “midi/osc only” setups for the Tau in EigenD on my rPI3b (and on rPI2 before that), so that should work, at least. I have never tried to host a plugin or trigger loops.

I had both MEC and EigenD running happily on a rPI3b + Pisound and tried to use those with PD. But I had some xruns I couldn’t get rid of and eventually gave up on using PD as a sound source (this was before patchboxOS).

Btw, I’m waiting for a Hydrasynth Desktop to arrive. Pico->Pi->Hydra might be nice…

8

one thing to bare in my most PD patches just run on a single core (its possibly to use multi core but few do… this actually works ‘well’ for MEC/EigenD, since they also need a dedicated core (since the main thread processing data has to be realtime too)
so often i found that a PD patch that worked without MEC usually was fine with MEC.

however there are a couple of things to check (e.g when you get xruns)

  • cores are really in ‘performance’ mode… with raspbian distros the raspi-service will pop them back to ondemand on boot up… easy thing to miss!
  • quantity of data
    eigenharps generate a huge amount of data, last yeah in prep for 3e I actually did some work on improving the usability of mec in this area… since i found it was easy to just move the ‘bottleneck’ to another thread/core (!) … so thats not better
    however…you PD patch still has to be able to process the quantity of messages its getting, so this may mean thinning the data stream (best at the MEC end) or being ‘considerate’ about the processing you do on it.
    btw: I tend to use OSC rather than midi, not sure performance wise if thats worst or better… the reason i use OSC is its higher resolution.

note: following, Im going to say rPI… but actually I include things like bela/organelle/norns etc.

all that said… I have to say, I tend to have to keep ‘reviewing’ my intentions about rPI (etc) and Eigenharps…

as a geek, its easy for me to fall into a trap of using it ‘because I can’ !
sometimes I look back at this and realise Im being a bit daft…
we’ve spent serious $$$ on the Eigenharps, so to ‘hamstring’ it with a $40 rPI is a bit stupid :wink:

thats not to say using a rPI is stupid… rather I find I need to think about WHY am i doing this!

for a pico, its really easy to justify…
a rPI makes it a standalone setup, that can also be portable (with a usb battery)

for a tau/alpha, its definitely more nuanced…
these cannot be portable since, they required a powered basestation…
even if we put a rPI inside the basestation, and battery powered it, its still not really that portable…
once you have the extra ‘bricks’ , does a laptop really add much inconvenience ?
(and no cost , I don’t think is a justifier… given the $$$ spent on the Eigenharp :wink: )

BUT that does not mean it doesn’t have a role… actually I think it very much does…

the role I see for the tau/alpha is that the rPI (etc) is more like a dongle, something that just turns on and you forget it… no powering up of laptops, running EigenD… its just plugged into your studio setup ‘ready to use’… this is why MEC is the way it is… without a UI, the idea is more ‘set n’ forget’

sooo… yeah, I think this is where things like the Hyrdasynth are really exciting with this approach…
if MEC can just ‘disappear’ into the background, and its just you and the Tau + Hyrda… then its a winning combo.

I have to admit, at the moment Im lacking a decent polyphonic/mpe standalone synth for the Eigenharp,
I’ve been planning on creating some… but really not had time, to create something that really shines.
that in turn has made my ‘needs’ for MEC languish a bit.
(my eurorack ‘obsession’ has not helped in this area :wink: )

BUT, my hope is the Osmose will change that…
Sure my main plan for the Osmose is to play its as keys BUT I think it’ll give me an impetus to have the Eigenharp ‘present’ on my midi router, so at anytime … I can use the EagenMatrix from it.

anyway… sorry for the ‘rambling’… but been wondering for a while… what is the role of a $40 computer when used with an expensive controller?! so these are my thoughts…
but very interested to hear what others think.

2 Likes
9

My initial goal was having a setup where I can just toggle a power switch and play. Currently I have an Organelle with MEC in the setup for the Eigenharps.
The incentive to use an Organelle instead of a cheap notebook (which might have cost about the same or even less) was to have a system that is rock stable, doing one thing and that reliably, something I don’t have to fiddle around with anymore once setup.

Current status: Even though the setup kind of works now, it’s still not perfect (e.g. even with Organelle OS 4. the Organelle midi interface cannot keep track with all notes when playing lots of notes fast and eventually stops forwarding midi notes, so I have to restart the Organelle). I am not convinced that the hardware is too slow, it’s presumably a software thing. (MEC can be ruled out, also getting the same effect e.g. with the Morphs, it’s probably the driver of the DIN midi interface of the Organelle.) It is only when sending midi notes to the PC though, e.g. USB-midi to Continuum is fine.
So it’s at this famous 20% stage where all the features are somehow in but 80% of the time would still have to be put in to get it rock solid :slight_smile:

An advantage of both Organelle and rPi is that it is a defined platform. So technically once the “rock solid” state would be reached (which is the hard part), it could be shared.
But as soon as the out of the box solution is supposed to be altered, the knowledge needed to do so is easily higher and more cumbersome than on a usual PC. So it would likely mostly make sense for plug-and-play stuff that everybody would use in the same fashion with minimal or no reconfiguration. Which particularly Eigenharp players who don’t consider anything as a given might have a hard time to get accostumed to. It was the concept behind EigenD and one of the reasons why I got into Eigenharps in the first place - If I remember right, I was fascinated by EigenD before I was fascinated by the Eigenharp.
Sometimes limitations and constants to just accept can be freeing though :slight_smile:

1 Like
10

is this just an issue on the TRS DIN, or is it also an issue on USB MIDI

I suspect that the TRS output is a bit limited… I only really used the TRS midi a few times, for a quick connection, worked fine when I used it … but perhaps heavy data would cause it issues
.but most of the time I use USB midi… even more often OSC :wink:

btw: the code is available for the serial midi driver, so it could be looked at if its causing issues.

yeah, agreed…
that’s kind of where id like it to be at.
not aiming for the most flexible solution, but rather one that works for when you just wanna pick up the eigenharp and play…

if you want to start messing with configurations, doing more elaborate things - I think that’s when a laptop with a nice screen, trackpad and keyboard just makes much more sense.

really 80-90% of the time (perhaps more), my alpha is just used in a chromatic scale in the same layout - and the only thing i do is move between 3 ‘modes’
a) send mpe midi
b) send non-mpe midi (poly)
c) send osc (t3d)

actually, thinking about it I also have a split mode that I sometimes rarely use… but that’s it :slight_smile:

so… kinda the only thing im missing in MEC is this ability to switch outputs on the fly.
but… unfortunately, that’s a bit of a can of worms, since it involves suddenly ‘repurposing’ the keys to do the ‘switch’

oh, really i also really need to add support for the ‘drum pads’ , even though i never really use them… hmm, perhaps they could be used for mode switches, and special commands (e.g. send command like start/stop transport)

1 Like
11

Yepp, it’s just TRS DIN that is slow, usb is no problem. Well, the only problem with usb is that there are only two ports on the Organelle :slight_smile:
One is connected to the USB hub (which speaks to the Morphs and the basestation) and the other is connected to the ContinuuMini. For some reason the ContinuuMini isn’t fond of being attached to the USB hub - it’s just doesn’t work.
In order to play VSTs on the Mac I thus connect it via DIN Midi between Organelle and Babyface.
Edit: Even if a USB port on the Organelle would be free it wouldn’t help as both the Organelle and the Mac are USB hosts.

As the DIN interface of the Babyface is reliable when e.g. used with the Linnstrument, I suspect it’s the Organelle DIN interface. For Morph the easy workaround is to just plug the USB hub into the Mac instead of the Organelle - done. And for the Eigenharp I can connect the basestation to the Mac. But then I can’t play the Morph or Eigenharp anymore with EaganMatrix without an Organelle reboot.
But the better solution is probably to determine the data rate coming from MEC or the Morphs to understand whether the DIN interface would technically have a chance. And if yes to try to find out why it doesn’t reach the nominal bandwidth. And as a last resort to decimate the data until it fits.

Or to take the Organelle out of the equation, connect everything to the Mac (with MEC or EigenD for the Eigenharp). This solves the bandwidth issue. But then the Mac isn’t optional anymore, which is an imho cool feature of the current setup - switch on and play, only boot the Mac when it’s really needed for VSTs or recording.

Or - right on topic :wink: - to replace the Organelle with a rPi which has four USB ports instead of two.
The Organelle is a cool, hands on synth by itself though, particularly with Orac. But perhaps it would be better to move this to my stage piano anyways, as most Organelle patches are better suited for keyboards out of the box… (the Morphs can also do “keyboard” though when asked nicely)
Edit: No, the rPi option doesn’t really help either as both the Mac and the rPi would be hosts. So it’s the Organelle or the plug-everything-into-Mac way.

So, back in the land of choices - again :slight_smile:

1 Like
12

I’ve been back and forth between using a laptop or rPI + hardware since I first got the Tau. I guess there are some arguments for the PI for live use. A device with a dedicated use is probably “safer”. Easy to have a spare ready in case something happens, etc. I try to lug as little gear as possible between my home and rehearsal room, so one PI in each location could be nice, as well.

…but over time, the reliance on GigPerformer and some increasingly complicated uses of the laptop as part of our live setup has made the Mac pretty much a necessity now Even without the plugins I use as sound sources for the Eigenharp, replicating the current GigPerformer scripts, midi messages, etc used live on a PI would still be quite a bit of work.

For practicing at home, the PI could easily be the best option. Always on, so it would just be a matter of picking up the Eigenharp of choice and start playing. I notice even the slightest hurdle getting the Eigenharp ready makes it more likely for me to pick up a guitar or something else instead.

For serious studio use, a dedicated Eigenharp laptop or connecting directly to the DAW easily wins, hands down.

So I guess my current opinion is that a PI-based setup would in many ways be the “better” solution for my needs, but the laptop makes most sense from a strictly pragmatic point of view. All the tinkering and making stuff work is fun, but also extremely time-consuming. I try to avoid technical distractions and spend as much time as I can actually playing. But being a geek makes it hard sometimes… :slight_smile: And of course, it doesn’t need to be an either/or. A simple PI-based option at home for practicing, and then connect a laptop when needed is of course a possibility.

3 Likes
13

Inspired by this conversation I just installed Patchbox OS and EigenD on a 8GB rPi 4 with Pisound. Short summary is I downloaded 2.1.7, the linux.eigend.sh script and the 69-eigenharp.rules and pretty much just followed the install instructions for linux. The Alpha worked fine with my usual midi-only setup, but I got an error for the Pico manager agent that it couldn’t find libpico_decoder_arm7_1_0_0.so. So I downloaded it and placed it in release-2.1.7-community/bin. No more error, but I still couldn’t get EigenD to detect my Pico (no pico keyboard showing up in Workbench).

Anyways, since the Alpha worked, I then installed Helm. That ran just fine in standalone mode on the PI together with EigenD. (It can also run as a VST3/AU/LV2 plugin, but I haven’t tried that yet.)

Helm doesn’t support MPE, and after five minutes of testing I got the sense that it didn’t sound great, but definitively usable. I’d be perfectly happy to use it if MPE support was added.

rPIHelmEigenD
rPIHelmEigenD927×513 121 KB

3 Likes
14

pico… which version did you use? is there an error in the log?
you’ll need : https://github.com/TheTechnobear/MEC/blob/master/resources/libpicodecoder_arm7.so
(renamed appropriately)

also you’ll need to have the pico firmware file too… pico.ihx

It should work fine, I’m reasonably certain I have it running on my rPI4 here.
(well mec at least, and I think its the low level stuff thats shared between mec/eigend thats failing)

2 Likes
15

Confirmative, the Pico works at least with the rPi3 (don’t have a 4). I had to set max_usb_current=1 in /boot/config.txt to get it to work though, otherwise the USB port doesn’t provide enough power for the Pico.

1 Like
16

I’ve spent more time on this. I installed “Carla”, a plugin host kind of like GigPerformer’s geeky cousin. It can also host SF2 files, etc. and worked well as long as I start it before EigenD. Dexed combined with some reverb plugin also ran fine, apparently with lots of CPU resources to spare. I could not get Surge to work. I believe it is supposed to work, so I’ll see if I can make a bug report to the devs. I installed all of this from the KXStudio repos using Synaptic as package manager.

I’m not making much progress on the Pico issues, though. I did a clean install on a 3b and wrote down each step I did:

OS:
RPI 3b with PatchboxOS 3-14 which I then updated from the patchbox menu. No active modules.

Downloads:

Installation steps:
cd ~/Downloads/
sudo dpkg -i EigenD-gpl-2.1.7-community-arm.deb
mv linux_eigend.sh.txt linux_eigend.sh
sudo cp linux_eigend.sh /usr/local/pi/release-2.1.7-community/
mv libpicodecoder_arm7.so libpico_decoder_arm7_1_0_0.so
sudo cp libpico_decoder_arm7_1_0_0.so /usr/local/pi/release-2.1.7-community/bin
sudo cp 69-eigenharp.rules /etc/udev/rules.d
sudo udevadm control --reload-rules

Optional:
Some Pi models need the following to provide enough power to the Pico
sudo nano /boot/config.txt
…and then add max_usb_current=1 at the bottom.
Reboot for the change to take effect: Sudo reboot

Running EigenD:
cd /usr/local/pi/release-2.1.7-community/
. linux_eigend.sh

…hopefully this can be helpful as easy to follow install instructions to others once I get things correct.

This is the console output when starting a blank setup in EigenD with the Pico connected, then opening Workbench and adding the pico manager. No pico keyboard show up in Workbench. PI console output

Surprisingly, I can not get the Pico working on my 2020 Catalina MacBook Pro anymore, either. I had it working a couple of weeks back. I have upgraded from 10.15.5 to 10.15.7 since then. Not checked logs or really investigated yet, so hopefully something simple. On my Win10 computer it works fine, so thankfully not a hardware issue! I don’t really use the Pico much, so not something I’ll be losing sleep over. :slight_smile:

17

this looks wrong to me…
basically the pico once it has its firmware loaded the device id should change (iirc) to 2139.0001.0004.0101 so, whilst the initial devices is found, it looks like its not able to upload the firmware to it.

the pico with rPI has had a chequered past… it never used to work due to some kernel issues, then it got fixed, then it stopped working again… its hard to say…
usually what I do is test it with MEC, and then have a look at console messages (dmesg)

also for some reason, Ive noticed my Pico is getting far more ‘picky’ with age even with my mac (10.14)!
e.g. there are a whole load of usb cables that used to work fine with it, but now seems like only one of my shorter cables is guaranteed to work… others I’ll get all sorts of issues with.
I don’t think its a software issue, as usually its ‘write’ errors on the cable, but its certainly odd as used to be fine with ‘any old cable’
( perhaps my old imac is having issues?!)

18

Hi Kai.

Just wondering if you ever got your Pico working with EigenD on a Pi4? thanx -Tefman.

19

No, I ran out of spare time to mess around and never picked it up again. I don’t remember if I got around to checking the MEC console messages as thetechnobear suggested. I don’t think so.

20

So Mark & Kai,

Cause I’m stubborn,I followed your install instructions above on a rpi4 4Gb.
Got this far… see screenshot. Seems like pico_manager fails to load on rpi4 as well. Could pico.itx be in the wrong folder? thanx.
2021-03-01-004638_1920x1080_scrot