We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Hello all,
It's about a year since ARM support for Processing was first released with version 3.0.1. Since then major pieces of the puzzle have come together: the Hardware I/O library, accelerated video decoding with the GL Video library, a custom Rasbian image, a tool to upload sketches to a Pi via the network and a library to work with the touch screen.
I'd be interested to hear from you: how can we make Processing for the Pi & friends better? What resources/libraries/functionality/documentation/bug-fixes would you like to see? (Probably not possible to tackle them all, but please do tell!)
Best
gohai
Comments
Does the processing distribution fix the opengl issue I had with raspbian, specifically that the panel containing the graphics was always offset from the frame holding the panel?
Any chance of a cut down processing distribution containing only processing and not much else? A 4gb download is a bit off-putting.
@koogs This was caused by a bug in the GL library we're using, which doesn't take the "overscan" setting into account. If you download the latest image from the Wiki page, or set
disable_overscan
to 0 in/boot/config.txt
, it should be fixed (provided your screen doesn't actually need the overscan).Thanks for the suggestion about the size.
Hi gohai, just wondering if there has been any progress on the issue Raspberry Pi: how to enable built-in pullups of GPIOs ? Missing feature or missing documentation? #4143
I'm knee deep in a project using Processing on an RPi and this would have saved some time :)
@rozling That's a really good question - at this point there is still no way to do this in a portable way through the Linux kernel, unfortunately. I've asked the maintainer of the relevant subsystem recently, and he replied that it's anticipated to have something like this in the future.
In the default state, the GPIO pins in the Pi seem to have some sort of bias towards reading back as high, but I don't know how strong or reliable this is. I'd also use external pullup resistors at this point.
Thanks gohai - yeah I couldn't figure out what way they were leaning so we're going the external pullup route.
One other suggestion I was thinking of would be that it would be great to have a little more control of deployment from the IDE, i.e. to be able to change the hostname or whether the sketch should launch at boot.
Also I couldn't find in documentation (although maybe I missed it) where on the Pi is the instruction to launch at boot, i.e. is there a script somewhere we can edit?
When trying to access GPIO pins through the hardware.io library offered through the add tools add library method, a conflict comes up between the native version of processing hardware.io library and the new library for the pi. It effectively prevents access from the pins, and there is very little documentation online about how to fix this issue.
some thoughts written up on it here: http://www.jtoy.net/2017/01/04/my-experience-with-processing.html
Thanks for your post @qifan. Have you tried using the GL Video library for using the camera? We're definitely interested in hearing about your pain points, and any particular suggestions how we can make it a more straightforward experience.
As to performance: that's something we only can do so much about. From my experience I can say that the Raspberry Pi 3 can already run most sketches that I care about - but if you have truly graphics intense applications (e.g. a lot of particles), then a $35 board obviously can't be compared to a dedicated, >$100 graphics card.
I plan to write a guide for optimizing on the raspberry pi. That given, don't forget that the pi 3 does have a dedicated graphics card and glsl runs pretty good on it. I've run very basic sketches that run pretty slow on the pi 3. I ahve not even touched particles on the pi yet.
As Hardware/IO is a part of core Processing, as Network, Serial, etc are, I think it would be appropriate to place Hardware/IO example code under the Libraries heading under File/Examples/Libraries ... (SHFT+CTRL+O) option.
@SiriusCG It should be - is it not?
Oops. Seems I had a brain cloud moment. Yes, in the ARM release the examples are there. Somehow, I also expected them to be in the Windows version too because I use the "Upload to Pi" tool to transfer sketches.
@SiriusCG We decided not to bundle the Hardware I/O library with Processing versions other than the ARM one, since we thought it would confuse users. You should be able to see the examples on Windows when you install the "Hardware I/O" library through the Contribution Manager on this platform. (This is specifically for users who prefer to use "Upload to Pi" to program their SBCs.)
It would be really helpful to (optionally) specify the sketchbook/library directory using the command-line tool, or better still - allow contributed libraries to be installed at the same time as the main program or through a separate cli.
I have a Processing 3 sketch running on Debian Stretch on a headless RPi3 and it works perfectly if no contributes libs are imported (thanks to this!).
But when using the command-line to run the sketch that does import a contributed library I get this:
root@bdd360b:/app# processing-java --sketch=./display_sketch --present Sketchbook folder disappeared: The sketchbook folder no longer exists. Processing will switch to the default sketchbook location, and create a new sketchbook folder if necessary. Processing will then stop talking about itself in the third person. No library found for processing.video Libraries must be installed in a folder named 'libraries' inside the sketchbook folder (see the Preferences window). display_sketch.pde:0:0:0:0: The package “processing.video” does not exist. You might be missing a library.
The library is cloned into
~/sketchbook/libraries
(I found the folder first, then specified it in preferences.txt like this:sketchbook.path.three=~/sketchbook
) and it's also cloned into the folder containing the sketch directory.