[Fluxus] rubyk & fluxus

[David Griffiths]

On Thu, 2010-09-16 at 11:05 +0200, Gaspard Bucher wrote:
> Hi guys !
> 
> 
> I was impressed by the work you did on (fluxus), great job !
> 
> 
> I fell on (fluxus) while looking for a functional scripting language
> to add to Rubyk (http://rubyk.org). In two words, Rubyk is an open
> source real-time signal processor (used for movement recognition and
> other installations). Rubyk is a patcher like max/MSP but with a focus
> on scripting, network transparency (OSC based) and concurrency.

Nice work, the explanatory diagram is particually good :)

> Do you think that the graphical part of fluxus can be embedded (used
> as an object) in Rubyk ?
> 
> 
> This would either require multiple virtual machines (no globals, ideal
> solution) or the use of a global mutex on the VM.
> 
> 
> From my understanding of the source tree, I should first manage to
> have a Scheme interpreter working and then users could start their
> scripts by including libfluxus.

Yes, this is the thing to probably try first, if you embed a racket
interpreter and provide a gl context users can just import fluxus-engine
and off they go... This is what happens if you use fluxus via DrRacket
or emacs.

I'm not sure what the implications are of running multiple instances of
fluxus renderers in the same process however - there are some static
things which may be showstoppers (e.g. texture caching). It would be
worthwhile sorting these out though.

> Using (fluxus) from within Rubyk would mean that any signal that can
> be received in Rubyk (serial port, motion capture, remote box, video,
> Mimas GUI, etc) could be plugged into fluxus and used to alter the
> rendering, enabling distributed installations with multiple screens
> and such.
> 
> What are your feelings about this ?

>From my point of view, good! We had planned to do some work to make a
plugin architecture in the C++ code to simplify the extra bits we have
already e.g. ATToolKit and make it easier to include more things like
OpenCV and give them access to the scenegraph. 

It seems to me, thinking about it again, that it would make more sense
if this connection was higher up the stack - for example via scheme
where it (if I understand right) could come from Rubyk too. 

cheers,

dave