From: Mathieu Bouchard <matju@...>
Date: 2001-12-05T03:57:15+09:00
Subject: [ruby-talk:27471] Re: GridFlow/Video4jmax in Ruby


On Sat, 1 Dec 2001, Lorien Dunn wrote:
> On Fri, 30 Nov 2001 23:17, you wrote:
> > I've written software called GridFlow (formerly Video4jmax), which is a
> > library for video processing among other things.

> 	IMHO Ruby is a far better platform for doing this kind of stuff
> than JMax. I find JMax very frustrating for complex projects whereas
> ruby is a joy.

I think jMax is not developed enough in the direction of large projects.
Changes to the file format, template structure, etc. would help a great
deal. Ruby would still win because it's stepwise instead of dataflow, and
some constructs are mind-bogglingly difficult to express in a dataflow
style. Nevertheless, Max/jMax have their own charm.

> Porting JMAX objects to ruby shouldn't be a big deal,

I've written a stub for the part of the jMax API I'm using. I'm compiling
my code without jMax. However I think some things are going to be
non-trivial to do, especially because GridFlow is possibly the most
complex jMax plugin ever, in terms of dataflow object communication.

> The major problems with using ruby for realtime programming are the
> lack of posix threading,

jMax also lacks posix threading for now. However you can run multiple
servers on the same machine and connect them by UDP or TCP; and some
particular features (direct-to-disk sound) use separate processes as well.

> and all the dynamic allocation happening everywhere (bad for latency).

the problem isn't so much dynamic allocation than unpredictable garbage
collection. this makes the worst-time quite high for any operation. To get
garbage collection more acceptable in realtime apps, it has to get some
characteristics... it should be interruptible, incremental, and triggered
preventively (that is, before you get OutOfMemory). Otherwise there are
some user-side tricks you can use to turn things to your advantage. In
particular, cut down the processes so that rt-critical parts happen in
processes with a low object count, etc.

> My solution for the posix threads issue is using ruby-fltk for the
> gui-

the jMax solution is to have two processes, one for the GUI, and one for
the rest. 

> 	I'm afraid I don't really have time to help write your bindings,
> however I can provide some advice when needed.

I wanted someone else to write the bindings. I can help as much as
necessary as long as the other person does the C<->Ruby coding.

> However it will make it much easier to do realtime midi-controlled
> video transformations and synthesis.

midi-controlled video transformations ? i want more info on this !

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju