batchku at gmail.com
Mon Sep 9 17:14:39 CEST 2013
On Mon, Sep 9, 2013 at 11:07 AM, jo57 <jaime.oliver2 at gmail.com> wrote:
> It is still a really interesting platform…
> Have you been using it successfully with Pd & sensors?
> Is there a Pd binary?
i compiled the latest from miller's site:
so i have 0.45 working, audio is fine;
the api/specs/docs on the GPIO and analog sensor pins on the UDOO are
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?
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...
> On Sep 9, 2013, at 11:00 AM, Ali Momeni <batchku at 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?
> On Mon, Sep 9, 2013 at 10:53 AM, Dan Wilcox <danomatika at 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 at iem.at wrote:
>> *From: *Ali Momeni <batchku at gmail.com>
>> *Subject: **Re: [PD] GEM on raspberry pi*
>> *Date: *September 9, 2013 10:02:52 AM EDT
>> *To: *Dan Wilcox <danomatika at gmail.com>
>> *Cc: *"pd-list at iem.at List" <pd-list at 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 :)
>> Dan Wilcox
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list