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
