[PD] bitmap sequencer and flext png library wrapper

[Mathieu Bouchard]

On Sat, 16 Nov 2002, Robert Figura wrote:
> On 15 Nov, Mathieu Bouchard wrote:
> > On Fri, 15 Nov 2002, Robert Figura wrote:

Ok, I'm having exams right now (that are taking more of my time than the
finals will)... sorry for the delay.

> >> As i somehow missed gridflow until now, i wrote a little png library
> >> wrapper using flext. Now gridflow is just too nice but if anyone is
> >> still interested in these 400 lines of code, just email me a note and i
> >> will put it online somewhere.
> > If you can debug GridFlow-for-PD, please do!! 
> I see. This is in fact necessary. Huh - Me?

Well, you said gridflow is just too nice. I say it would be just too nice
to have a debugged version of GridFlow 0.6.x.

> Hmm let's see... Cough cough, seems like we are all missing some good
> docs. That _will_ take some time.

It already took me a long time. I hope the 0.6.3 code (the one in CVS) is
a bit more readable than the last official release. If you look for docs
about the code: this did not happen for several reasons, mostly that the
code structure has changed a lot since June, and the changes are not
completed, but the bugs are preventing me from finishing that job, and now
I need help; do you see that loop in the 

> Ruby looks like python, but at a first look i cannot tell how
> bridge_puredata.c does its job.

Well the big difference between Ruby and Python C-wise is that in Python
you have to take care of reference counting and with Ruby you don't.

'bridge_puredata.c' becomes 'gridflow.pd_linux' which loads Ruby and tells
Ruby to load the other 90% of Gridflow. GridFlow creates the FObject class
and then subclasses it many times, each time calling FObject.install(),
which tells the bridge to register a class in puredata or jmax. Puredata
objects have proxies for each of the non-first inlets so that any inlet
may receive any distinguished message. All inlets are typed as 'anything',
and the 'anything' method translates the whole message to Ruby objects and
tries to call a Ruby method of the proper name.

>> and if not, then I would be
>> interested in porting the PNG code to GridFlow, which is not using flext
>> despite being C++ code. You see, GridFlow doesn't have PNG
>> support yet.
> Uark. It said permissions, didn't it? Sorry. Anyway, URL is:
> ftp://iem.kug.ac.at/incoming/pd-externs/bitmap-0.1.tar.gz

Downloaded it. Thanks. Will look at it when I get a chance to, but that
will be after one more session of debugging.

> BTW: I needed just half a day to follow the pnglib readme file and
> compile the first wrapper. It's no big deal.

Well, I remember I got annoyed by having to handle setjmp()/longjmp() by
hand; in a sense, setjmp()/longjmp() is the proper way of doing
things, but I found C makes it annoyingly clumsy to use (that or Ruby
exceptions, which are somewhat higher-level). I had a good part of it done
but I gave up at some point and I don't recall why.

I will try again using your code as a basis.

> >> I just started using gridflow so i may decide to continue developing
> >> pngread later.
> >> BTW: I would like to implement flext-threads,
> > You want to implement them into what?
> Implement loading a png in a thread.
> Loading a png requires a relatively big cpu chunk. There is no herb
> against this latency but there is no need to eat it all at once.

Aren't there many video operations that take a big cpu chunk? I tried to
alleviate that issue by packetizing gridflow's data (from the very start
of the project), but it seems that given jMax/PD's method of evaluation in
message mode, everytime I send a picture through a network of objects,
evaluation does not stop until that picture is done. Now I don't know
where the audio chain gets inserted into that. If it may be called
everytime the message-sending function is called in PD, then there's not
that much of a problem with video _and_ you are right that loading a PNG
causes a higher-than-average latency. I'd like to see a more generic way
to fix that, however, because it happens that I read from my webcams in
blocking mode (and I have not checked yet whether I may do otherwise,
but I may have to use a separate thread or process).

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju