Hi some,
I watched the thread about trackers and pd and since i still had not found a sequencer software to fit my needs (shaketracker won't compile, jazz is not quite what i want) i decided to use bitmaps for sequenceing.
My favorite mapping is like this: (using hsv conversion) x->freq y->bar h->waveshape-index s->intensity v->velocity A=aux-param
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.
It can read 8 or 16-bit CLUT-mapped, RGB, RGBA, Grayscale, Grayscale+A png files. Until now it can not write files or modify a loaded bitmap. It was implemented on a linux box so porting is untested but IMO should be trivial.
I just started using gridflow so i may decide to continue developing pngread later.
BTW: I would like to implement flext-threads, but how? Am i yet again missing the flext docs or aren't there any beyond the source? Why do the flext tutorial makefiles have references to thread examples but i cannot find them?
Happy patching
Robert Figura
@urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l= 0;O*O+o*o<(16^l++);o=2*O*o+I/74/11.-1,O=i)i=O*O-o*o+I%74*.04-2.2;}
Hi Robert
BTW: I would like to implement flext-threads, but how? Am i yet again missing the flext docs or aren't there any beyond the source? Why do the flext tutorial makefiles have references to thread examples but i cannot find them?
i'm working on a functional reference for the upcoming version of flext. At the moment the documentation lies in the tutorials und my other flext externals.
Concerning the flext-threads tutorials... i can hardly believe how i could overlook that these are missing in the packages! (up to now nobody complained, though...) Please be patient until next monday or tuesday when flext 0.4.0 will be released.
best greetings, Thomas
On Fri, 15 Nov 2002, Robert Figura wrote:
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!! 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.
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?
Mathieu Bouchard http://artengine.ca/matju
On 15 Nov, Mathieu Bouchard wrote:
On Fri, 15 Nov 2002, Robert Figura wrote:
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? Hmm let's see... Cough cough, seems like we are all missing some good docs. That _will_ take some time. Ruby looks like python, but at a first look i cannot tell how bridge_puredata.c does its job.
This is a little bit deeper than i am actually aiming at.
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.
Wait a minute, i put it on pdwiki...
ftp> cd incoming 250 CWD command successful. ftp> cd pdwiki 250 CWD command successful. ftp> put bitmap-0.1.tar.gz local: bitmap-0.1.tar.gz remote: bitmap-0.1.tar.gz 227 Entering Passive Mode (193,170,191,180,216,138). 550 bitmap-0.1.tar.gz: Permission denied
??
ftp> cd .. 250 CWD command successful. ftp> cd pd-externs 250 CWD command successful. ftp> put bitmap-0.1.tar.gz [...] 226 Transfer complete. 66985 bytes sent in 00:09 (7.07 KB/s)
Whoops! Wrong place. Why now?
ftp> cd pd-externs 250 CWD command successful. ftp> ls [...] drwxrwxrwx 2 root ftpadm 4096 Jun 21 2001 pd-patches drwxrwxr-x 3 102 ftpadm 4096 Jun 7 09:03 pdwiki [...] ftp> rm bitmap-0.1.tar.gz 550 bitmap-0.1.tar.gz: Permission denied
Uark. It said permissions, didn't it? Sorry. Anyway, URL is:
ftp://iem.kug.ac.at/incoming/pd-externs/bitmap-0.1.tar.gz
BTW: I needed just half a day to follow the pnglib readme file and compile the first wrapper. It's no big deal.
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.
Regal Robert Figura
@urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l= 0;O*O+o*o<(16^l++);o=2*O*o+I/74/11.-1,O=i)i=O*O-o*o+I%74*.04-2.2;}
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
-
Mathieu Bouchard -
Robert Figura -
Thomas Grill