Hello,
On Mon, Sep 9, 2013 at 11:07 AM, jo57 jaime.oliver2@gmail.com wrote:
It is still a really interesting platform…
indeed!
Have you been using it successfully with Pd & sensors? Is there a Pd binary?
i compiled the latest from miller's site: http://msp.ucsd.edu/software.html
so i have 0.45 working, audio is fine; the api/specs/docs on the GPIO and analog sensor pins on the UDOO are MINIMAL. i'm working on getting them going.
How do usb sound cards work with Udoo?
been using the built-in audio; it has 1/8" in/out in addition to the HDMI
On of the nice things about the pi is that you can access pins form within pd with the pi external. is there something like this in Udoo?
absolutely. the GPIO setup on the UDOO is the same as the PI (i.e. the is a special folder with a subfolder for each pin and the params for each pin is a file. the GPIO pd extern that miller has ( http://msp.ucsd.edu/syllabi/206.13w/index.htm) should work just fine; i'm only waiting for the pin-numbering diagram from UDOO folks...
a
best,
J
On Sep 9, 2013, at 11:00 AM, Ali Momeni batchku@gmail.com wrote:
Hello all, My bad, UDOO supports OpenGL ES 2.0 and OpenVG. So getting GEM working on it is closer to the RPi than i thought.
Are the porting efforts of GEM for RPi being documented somewhere? Is IOhannes m zmölnig still working on GEM?
ali
On Mon, Sep 9, 2013 at 10:53 AM, Dan Wilcox danomatika@gmail.com wrote:
It's not that the RPI doesn't support OpenGL, it's that it's using OpenGL ES which drops some of the earlier GL 1.1 api, mainly intermediate mode. GEM can/will work fine on RPI if it's api is updated a bit to support ES (or through an emulation layer like glshim). This is a good idea in the long term anyway, since newer implementations of GL (3.3+) are also dropping support for the "old way" of doing things.
I've long thought that GEM could be ported to work on iOS, but I haven't had a need for it so haven't looked into it. In that case, there would need to be some function wrapping to support the old GL API, but this has already been done in libraries like OpenFrameworks, so they could be used as a template. Simple things like using a vertex array when setting vertex points in intermediate mode, etc ...
If the Udoo board has a regular GL 1.1, 2+ stack then it should work fine with GEM without any changes ... except that, unlike the RPI, it will require running X11 in order to use XGL. OpenFrameworks on the RPI, for instance, uses GLES without X11 and thereby doesn't waste resources on the windowing system. In my experience with embedded Linux system, it's best to ditch X if you truly do not need it. ON my old setup, X took almost 100 MB of ram on my 256 MB system. Running my custom SDL visual app directly to the framebuffer took only 1 couple of MBs by comparison.
Then again, embedded systems nowadays have more and more resources to burn so it may work without having to be frugal. (although efficiency is still important IMO).
On Sep 9, 2013, at 10:03 AM, pd-list-request@iem.at wrote:
*From: *Ali Momeni batchku@gmail.com *Subject: **Re: [PD] GEM on raspberry pi* *Date: *September 9, 2013 10:02:52 AM EDT *To: *Dan Wilcox danomatika@gmail.com *Cc: *"pd-list@iem.at List" pd-list@iem.at
hello friends, i'm very keen to try GEM/openGL on a Udoo board (http://udoo.org) which DOES support OpenGL. if anyone is up for trying it i can provide you with a board to try on. should be a load of fun :)
ali
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list