Is anyone using the patcher software on a raspberry pi 3?

#1

Hi all, I've done a search in the hardware/software sections and can't find an answer, has anyone used the patcher software on a raspberry pi 3 yet? I don't have any specific plans, I'm just curious as to what my options are with the axoloti core board and external hardware.

Asus Tinkerboard w/ Axoloti
#2

Same here,
I was looking for that yesterday. In fact any reference to any SBC dev board, Beagle Bone, Banana Pi, Cubie Truck.. etc Was able to find reference to using them as Midi devices, but can they run the patcher.

#3

this has come up a few times before, and a specific topic here ... my gut feeling was no, it not going to work well :slight_frown:

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 :slight_smile: )

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 :slight_smile:

Anyone try the axopatcher on raspberry pi2/3 running 64bit open suse?
Help building axoloti from source for arm system
Morpheo = RPi + Goom synth + Axoloti
#4

I have tried it a few times on my Novena, which uses a Freescale iMX6 chip, quad core with 4 gigs of RAM - not a speed demon compared to a PC, but no slouch either. I am quite sure it's faster than any Raspberry Pi, but I don't have the benchmarks to back that up.

I did not measure CPU usage much, the compiles were very slow and screen redrawing too slow to make it unusable as thetechnobear says. The graphics issues might be related to the drivers not providing enough or the right kind of 2D acceleration, or it might be because the JVM on ARM is much less optimized than on PCs (which I am assuming it is).

Either way, there's a bit to go I think.

#5

Thanks for taking a look @thetechnobear that's a shame, I thought cross-compiling for 'live' would be the thing that slowed it down rather than the ui.

#6

Thanks for testing. Maybe something to look much later down the track. These units are getting faster all the time, so maybe its just a matter of waiting.

#7

Wanted to resurrect this topic. Very curious if anyone has now tried the patcher on a Raspi 4. Specs are quite similar to what @rvense was describing with the Novena. Reading back through the thread it seems like it was unusable on Raspi 3

#8

Raspi 4 might actually be fast enough to run the existing patcher stack, but that's a band-aid solution. There's nothing that magical about the problem the patcher needs to solve that requires a ton of hardware. We should be able to do it on very resource constrained targets. Even a Pi Zero, etc.

The problem is mostly the efficiency of the patcher code, and also the efficiency of the "compile on live" approach. The patcher is currently Java-based, which isn't something that we can really optimize very heavily for Pi. It's basically the same code running on every platform inside that platform's JVM. So we're mostly deferring to the efficiency of the available JVM. We probably need to pick something that has higher raw rendering performance and can be compiled into native code for the Pi, possibly Qt or GLFW. Something that emits a native executable at the end and doesn't depend on a JVM or an interpreter.

Going live with a patch shouldn't actually launch the ARM compiler toolchain. If we can get to a lighter-weight messaging style architecture, it will be easier to make it really fast on the Pi. You'll run the compiler once up front or infrequently to update objects on your device, but then patching will only send very light-weight messages over the wire.

#9

Out of curiosity, do you have any idea why Johannes would have chosen to write the patcher in Java over Python?

It's purely my own curiosity cause I read Python runs everywhere without the need for 'porting', so I'm wondering what would have made Java more appealing when, if I'm understanding correctly, it is graphically intensive.

Personally I'd love to see a patcher for Raspberry Pi, especially now the 4GB version of Pi 4 is available. It can run two 4K screens apparently, so it would seem odd if it couldn't handle the redrawing of a screen of objects connected with wires. That said, while it can drive two 4K screens, I did also read that it's not capable of handling 4K video (which sounds a bit ridiculous to me).

Certainly though, use it at a more sensible 1080p and it's powerful enough to replace a desktop for many people since the 4GB Pi 4 arrived.

You know, I quite surprised really, that more of the larger softare companies aren't all over it. The Raspberry Pi is actually the most popular motherboard/computer in the world now, and it runs Linux by default meaning you even get to escape the abusive Spy-OSs such as MacOS and Windows by owning one!

They seem to be targeting the desktop market now with those full-on desktop packages they sell, so that'll certainly help to make it a desktop replacement for many.

#10

Ignore what I said about 4K video, I just checked and apparently it does now, which makes it even more of an attractive proposition.

#11

My guess on “why Java not python” is that it’s about graphics frameworks.

#12

Thanks for the comment. I was curious because I'm about to start learning Python. I might have had second thoughts if it were somehow unsuited to working with this sort of stuff, like some show-stopper aspect of it that I'm not aware of.

Python seems to be pretty much everywhere I turn and is easy enough to learn (or so people keep saying). I hope there isn't some biggie that'll make me regret learning it!

#13

Python is easy to learn, if you have talent for programming, just like many other programming languages.

Back to ‘why java’, the decision can also involve what’s available (patcher was written years ago) and what’s familiar. For a long time, Java was the choice for cross platform GUI apps.

#14

You can basically do the same things graphically from either language, e.g. draw to OpenGL, use Qt, etc. Python is way, way slower in raw numerical performance, like on the order of 100 times slower. (Aside: Axoloti's patcher is using Java's included 2D drawing APIs rather than OpenGL etc which would probably be more efficient. There's nothing special about the choice of Java for 2D performance.). Distributing apps in either one is painful. For Java, you need a virtual machine available of the correct version. For Python, you need an interpreter. There are ways to sort of get around this and make the app look like a single package with all its dependencies, but it's a pain.

Semantically, Java and Python are not all that different. Python has an interpreter though, a Read-Eval-Print-Loop console that you can test commands in interactively. That's a big selling point for beginners. It's also highly dynamic; you don't need to declare types everywhere:

pi = 3.1415

vs Java or C-Like languages:

float pi = 3.1415;

When you have millions of lines of code, I think having a compiler be able to tell you that there's a type problem is really important and worth the effort of having to statically declare types, but that's a debated question.

Java and C-like languages have a lot of krufty syntactical detail that is painful to get right for an absolute beginner. Python strips a lot of that away.

On cross platform GUI apps: there are a bunch (like hundreds probably) of ways to achieve that now, and it's a confusing problem to tackle. Java was the old standard. A lot of people like Electron and similar now which is basically a web browser stack, i.e. HTML/CSS/JavaScript.

#15

Well that's me out before I even get started then, but thanks, and at least Python has plenty of those!

I'm hoping to use whatever I learn in Python to work in MicroPython though, cause it's designed to run on that special MicroPython-based board I posted in the FPGA thread. I'm under the impression that the Python code gets converted to bare-metal machine-code to make it fast.

Thanks for the insight, I know what you mean about having to declare variable types, and I believe memory management is another thing that makes the other languages harder (unless I misunderstood what I watched).

Anyway, back to the original discussion, I am definitely one of those interested in an RPi version. In fact, if it worked nice (I know it might be a big if) on the new 4GB model, I would not be surprised if just about everyone warmed to it as their preferred Axoloti Patcher platform.

#16

The MicroPython board you mentioned before runs 'bare metal', meaning no large general purpose operating system.

However, it's still interpreted Python, with the usual speed deficiencies.

#17

I thought it got converted by the board to machine code, so I must be thinking of something else. Off the top of my head it might be PICAXE I was thinking of and mixing the two up, but then again I believe that one converts BASIC into machine code, not Python into machine code.

Been looking into so much stuff I think my brain has run out of RAM :roll_eyes:

#18

Picaxe is interpreted BASIC.

#19

I've just been looking on both sites and can't find what I read before, so I haven't a bloody clue where I read it, but one of the programming/hardware solutions I looked into took either BASIC or Python, and turned it into native machine code for the chip to run.

What the hell, I can't think what else it would be if it weren't one of those!

Would a PICAXE be fast enough to drive a 320x240 display at a refresh rate of 60Hz? I'm pretty sure the bare-metal MicroPython board could manage that, but I'm not so sure about a PICAXE.

#20

I never used PICAXE. If I wanted Python, I’d use NodeMCU esp8266. Cheap, fast, and WiFi.