[ruby-talk:27495] Re: GridFlow/Video4jmax in Ruby

On Tue, 4 Dec 2001 18:57, Mathieu Bouchard wrote:

>
> 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.
>

 I agree. I've used Max on the Mac, the IRCAM Signal Processing Workstation 
(ISPW) on an audio accelerated Next Cube, and JMax on linux. But I got REALLY 
annoyed when I found out that things like tables are only global (I know this 
was going to be fixed).  And I do really complex transformations of midi data 
that just scream for a 'real programming language'. I think the Max family is 
strongest if you don't think of them as programming languages, but as patch 
bays. I also don't like the lack of inheritance (both with plugins and 
patches), as I'm a big fan of OO.

> > 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.

 I've got a data-flow system for ruby. It is written in c, and very fast. But 
it would take some work to use it with something that expects the JMax API! 
I'm likely to realese all my stuff (under the GPL) in a few weeks. I'll send 
you an email when I do.
>
> > 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.

 I decided against this way because I want my prog to be easy to understand 
and maintain.

>
> > 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.

 Actually this hasn't shown itself to be a problem. And I am using GC with 
quite high object counts (all my midi events are ruby classes for one). I 
only had trouble with this when my scheduler wasn't freeing tasks, and ruby's 
RAM usage went to 150 megs.

> 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.

 Sorry. I'm just too busy :( I came across your plugin a few weeks ago, and 
my wife is considering using it in her Masters of Electronic Arts degree. I 
may have time in future though.
 Have you looked at SWIG (www.swig.org)?

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


 What info would you like? All I meant was that I've taken care of all the nasty 
internals of the midi protocol, and softened it somewhat (for example I've 
made things like controller values and velocity between 0.0 and 1.0). The 
kind of thing I meant was (contrived example):

midiIn.channel[1].controller[10].value.connect(videoObj,:contrast)

Also please don't 'reply to all' on list emails, because I get the messages 
twice.

Lorien Dunn