Hello, On Mon, Sep 9, 2013 at 11:07 AM, jo57 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, [email protected] wrote: >> >> *From: *Ali Momeni <[email protected]> >> *Subject: **Re: [PD] GEM on raspberry pi* >> *Date: *September 9, 2013 10:02:52 AM EDT >> *To: *Dan Wilcox <[email protected]> >> *Cc: *"[email protected] List" <[email protected]> >> >> >> 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 >> >> >> >> >> >> > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
