this has come up a few times before, and a specific topic here ... my gut feeling was no, it not going to work well
anyway, I decided, really the only way to know 100% was to 'suck it and see'
so, I just installed axoloti on my Raspberry PI2 with a Linaro distribution.
(the linaro distro, is pretty good performance as Ive tried it on other things, PI2 as I don't have a PI3)
so , it took a bit of hacking of the build script for linux, and determining where to source packages etc, but I finally got it working! ...
I was able to run the UI, build/update firmwares, build patches, connect to axolotl, run and control patches on the axoloti. - so yes, it works.
BUT... hold your horses, before you start popping champagne corks.
Issues
CPU
UI responsiveness, its practically its unusable...dialogs and dragging, wire connections are all painfully slow.
Axo core disconnects, I think this is cpu issue, basically not processing the axoloti USB events fast enough.
Axo voltage low
I was getting quite a few spurious errors/disconnects , when I had just a keyboard, mouse, wifi dongle and axo in the PI2, despite having a 2A power supply on the PI2 and no midi controllers in the PI or Axo
Solutions?
the low voltage is probably not an issue, simply use a powered hub in the PI, and attach everything to that.
(its not uncommon for PI to have this issue, even worse on the BBB
)
CPU, this is the harder thing to fix...
there is one fix we kind of know that will help... to do with USB polling frequency, which has been seen on other slower computers.
there have also been reports of issue under linux of high cpu, which could also contributing to it... but we don't have really an idea what this is.
also, Ive also feared the graphics performance on the PI is poor, with little hardware acceleration, compounded by lightweight processors, and i suspect this is the main culprit.
PI's generally don't have a lot of cpu power, I can see 'reasonable' load on the 4 cores, but interestingly they don't appear to be maxed out, and also whilst Axoloti is 'slogging away' doing its thing, the rest of X seems still responsive.
would it be ok on a PI3, frankly, I doubt it.. the pi3 is about 25% faster cpu, twice as fast cpu... and they claim its twice as fast at the PI2, but honestly, even if it was 4x the speed, it would still be not a very 'pleasant' experience.
I'll perhaps give it another test if we find and resolve and the performance issue under linux... but I'm not spending more time on it, its frankly very unlikely to be worth it.
it
Im sure others may want to try, and i can say if your 'confident' with linux packaging, and understand a build of shell (so you can edit build.sh) its not difficult.
but unfortunately, I can't really package my hacked solution, and its too time consuming to document/support others to do it, and more importantly there probably will be 'issues' with the patcher etc specific to the PI and i don't have time to look into these.
of course, if it does become useable, I will of course update the build scripts to allow others to build
anyway, was an interesting experiment 