Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A question... RPi as a renderer/slave for Field #57

Open
laboratories opened this issue Mar 17, 2015 · 2 comments
Open

A question... RPi as a renderer/slave for Field #57

laboratories opened this issue Mar 17, 2015 · 2 comments

Comments

@laboratories
Copy link

Hi All

a quick question

With the availability of a [cheap] 4-core (HD video capable) Raspberry Pi 2
I'm looking back again at Field...
and am wondering if there are any thoughts or plans for incorporating RPi(Debian) into Field
(many parts are already there)
(and I hope to sit-down and do the hard research next month - when I have some time)

what I'm most interested in is
control and/or remote rendering,
multichannel video playback,
communications to and from a RPi2 (master:slave with frame/code-execution sync )
and finally a possible overall port of the system [or a strip down version]

PD (and some times PD-Extended) at the moment is really the only thing going for this purpose (other than direct system programming)
I'm currently having good success with GStreamer 1.0 and python on the RPi
(yay) and it made me long for the programmable timeline surface of Field

Thoughts and discussion welcome

and thanks again
really glad to see it's still being developed
g

@marcdownie
Copy link
Member

Well, this seems like a splendid idea --- and one that solves a real problem --- but we have no experience at all with the RPi. There are two ways we can do this: 1. we can get all of Field's graphics system running on the RPi and then send code to the slaves for execution. 2. we can get something much smaller (Python + GStreamer) and send code to that for execution.

  1. would be great, and my preference, but I'm concerned that Field is just too big. Field2 (where all my attention is focused right now) is smaller, but gives up compatibility with OpenGL <3.2 (and thus any hope of compatibility < OpenGL ES 3.0). So I think we'd aim for a proof of concept that has something useful (GStreamer) in Python and then pull over something like the Max MSP plugin so we can send code to RPi slaves directly.

@fatmilktv
Copy link

If there's a use case that entails render-outs from a Field server or
service, I'm pretty interested whether F1 or F2.

I think both stats and video are useful cases here.

I had thought I'd seen something on these lines before (but I'm not finding
it in mail-list just now). Also, presuming not, but, does the prior OSC
work scale to this level-speed-scope?

Thx, Al

On Mon, Mar 23, 2015 at 10:25 AM, Marc Downie [email protected]
wrote:

Well, this seems like a splendid idea --- and one that solves a real
problem --- but we have no experience at all with the RPi. There are two
ways we can do this: 1. we can get all of Field's graphics system running
on the RPi and then send code to the slaves for execution. 2. we can get
something much smaller (Python + GStreamer) and send code to that for
execution.

  1. would be great, and my preference, but I'm concerned that Field is
    just too big. Field2 (where all my attention is focused right now) is
    smaller, but gives up compatibility with OpenGL <3.2 (and thus any hope of
    compatibility < OpenGL ES 3.0). So I think we'd aim for a proof of concept
    that has something useful (GStreamer) in Python and then pull over
    something like the Max MSP plugin so we can send code to RPi slaves
    directly.


Reply to this email directly or view it on GitHub
#57 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants