Hi Claude,

Thanks for the background info.

The Maciunas film is great but I think your work is sufficiently
different :-)

The idea of creating a customizable DVD is very cool. I can imagine
allowing users to control parameters in audio/video, etc. and create
something fun.

As for the steps that you took - I wonder if you could please explain
saving the ppm files in Gridflow. I have looked at http://gridflow.ca/latest/doc/format.html and just couldn't figure it out. I was trying to do something similar with jpegs and sending messages like:

[open jpeg testfile(

and

[format jpeg(

to an

[#out]

object but had no luck. I'm sure I'm just being stupid but any help would be appreciated!

I know that saving the files will slow things down considerably but
would still like to know how it's done :-)

Thank and best, p

On Aug 23, 2006, at 3:51 PM, Claude Heiland-Allen wrote:

Paris Treantafeles wrote:

...

Hi Claude, I finally have downloaded and watched your Soft Rock EP and wow...
great stuff! I may be biased because it's quite similar to some of my own work

• even without the GridFlow abstraction that you shared :-)

Thanks - a friend of mine showed me a video made 40 years ago that
looks similar in places:

George Maciunas - Artype (1966), 29 mb http://ubu.wfmu.org/video/fluxfilm_20_maciunas.mpg http://www.ubu.com/film/fluxfilm.html

I'll have to try harder to come up with something original!

...

If you don't mind can you tell us how you captured the visuals? They look very good - were you writing to disk (say from Gridflow
to Gem?) or sending video out to another machine to capture.

I saved lossless ppm images direct from GridFlow. To avoid using
an excessive amount of disk space, I used a named pipe created with
mkfifo to send these images directly to mpeg2enc (part of
mjpegtools package, I believe).

Needless to say it works slower than realtime, I think it rendered
at about 4 frames per second on my machine, including the time
taken to encode the video to MPEG2 format.

I'm working on a build system that would enable you to create your
own custom Soft Rock DVD, hopefully I'll get it finished and
debugged before Christmas. It will need a fair amount of
intermediate disk space (maybe 5-10 GB) because the following
deadlocks after a few frames:

   / writesf~ WAV pipe -> toolame  encoder \
  /                                         \

Pd --< >-- mplex multiplexer \ / \ GridFlow PPM pipe -> mpeg2enc encoder /

I believe the root cause of the deadlock is either or both of
writesf~ and GridFlow using blocking I/O rather than non-blocking I/ O, from what I have read mjpegtools is written to play nice with
fifo's.

The intent is to generate a sequence of unique (but similar) DVDs
from around 1 MB of pd/bash/make code and a small amount of seed data.

...

Thanks for sharing! p

Thanks for the feedback!

Claude

http://claudiusmaximus.goto10.org

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Hi Claude,

Yeah, recognizably the same is fine though. I mean if they wanted to do something very different, they could get
your patches and modify them or write their own :-) At minimum even a "remix" capability is cool.

Thanks so much for the attached patch - yes, this is exactly what I
was trying (unsuccessfully) to figure out!

Best, p

On Aug 23, 2006, at 8:26 PM, Claude Heiland-Allen wrote:

Hi Paris,

Paris Treantafeles wrote:

...

Hi Claude, Thanks for the background info. The Maciunas film is great but I think your work is sufficiently
different :-) The idea of creating a customizable DVD is very cool. I can
imagine allowing users to control parameters in audio/video, etc.
and create something fun.

Yes, that's the idea, it will still be recognizably the same work,
but (hopefully) different enough to be interesting.

...

As for the steps that you took - I wonder if you could please
explain saving the ppm files in Gridflow. I have looked at http://gridflow.ca/latest/doc/format.html and just couldn't figure it out. I was trying to do something similar with jpegs and sending messages like: [open jpeg testfile( and [format jpeg( to an [#out] object but had no luck. I'm sure I'm just being stupid but any help would be appreciated! I know that saving the files will slow things down considerably
but would still like to know how it's done :-)

Attached is a simple example that saves a sequence of image files
to /tmp , I hope it helps. The key is using:

"open <format> file <filename>"

You need the keyword "file" to distinguish from things that aren't
files. The keyword "gzfile" can be used instead, which will use
gzip to compress the file. For example, for gzip'd TGA files you
can use "open targa gzfile blah.tga.gz" (if this doesn't work, my
memory is flawed...). I think other keywords are available/ planned, for things like UDP and or TCP connections, but I've never
used them.

...

Thank and best, p

Thanks,

Claude

...

On Aug 23, 2006, at 3:51 PM, Claude Heiland-Allen wrote:

...

Paris Treantafeles wrote:

...

Hi Claude, I finally have downloaded and watched your Soft Rock EP and
wow... great stuff! I may be biased because it's quite similar to some of my own
work - even without the GridFlow abstraction that you shared :-)

Thanks - a friend of mine showed me a video made 40 years ago
that looks similar in places:

George Maciunas - Artype (1966), 29 mb http://ubu.wfmu.org/video/fluxfilm_20_maciunas.mpg http://www.ubu.com/film/fluxfilm.html

I'll have to try harder to come up with something original!

...

If you don't mind can you tell us how you captured the visuals? They look very good - were you writing to disk (say from
Gridflow to Gem?) or sending video out to another machine to
capture.

I saved lossless ppm images direct from GridFlow. To avoid using
an excessive amount of disk space, I used a named pipe created
with mkfifo to send these images directly to mpeg2enc (part of
mjpegtools package, I believe).

Needless to say it works slower than realtime, I think it
rendered at about 4 frames per second on my machine, including
the time taken to encode the video to MPEG2 format.

I'm working on a build system that would enable you to create
your own custom Soft Rock DVD, hopefully I'll get it finished and
debugged before Christmas. It will need a fair amount of
intermediate disk space (maybe 5-10 GB) because the following
deadlocks after a few frames:

   / writesf~ WAV pipe -> toolame  encoder \
  /                                         \

Pd --< >-- mplex
multiplexer \ / \ GridFlow PPM pipe -> mpeg2enc encoder /

I believe the root cause of the deadlock is either or both of
writesf~ and GridFlow using blocking I/O rather than non-blocking
I/O, from what I have read mjpegtools is written to play nice
with fifo's.

The intent is to generate a sequence of unique (but similar) DVDs
from around 1 MB of pd/bash/make code and a small amount of seed
data.

...

Thanks for sharing! p

Thanks for the feedback!

Claude --http://claudiusmaximus.goto10.org

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

#N canvas 13 12 1149 431 10; #X obj 462 150 t a a b; #X obj 484 299 #out; #X obj 506 193 f 0; #X obj 546 193 + 1; #X obj 414 216 #finished; #X msg 414 239 close; #X obj 506 232 rubysprintf /tmp/%08d.ppm; #X obj 462 50 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 462 108 # rand; #X msg 462 84 ( 240 320 3 # 256 ); #X text 25 222 Close file after writing. Only necessary for the last image in a sequence , as each "open" message closes the previous
file. ; #X text 695 208 For an image sequence it is useful to have sequential numbering , but in other instances it is more useful to name with a time stamp (for example , if the patch crashes and you need to
restart without overwriting previous images...).; #X text 615 93 A simple image is pseudo-random noise.; #X text 278 18 Click here to generate and save images (in ppm format to /tmp by default).; #X msg 506 264 open ppm file $1; #X text 23 328 For writing to a named pipe created with mkfifo (say it is called "fifo.ppm") , you would "open ppm file fifo.ppm" once , then send multiple image grids (of the same size) to #out , and only "close" after the last image has been sent.; #X text 580 325 Note: when saving to a named pipe , gridflow (and Pd) will appear to hang until the data is read from the other end of the fifo. When experimenting try "cat fifo.ppm >/dev/null" to
magically bring Pd back to life.; #X connect 0 0 4 0; #X connect 0 1 1 0; #X connect 0 2 2 0; #X connect 2 0 3 0; #X connect 2 0 6 0; #X connect 3 0 2 1; #X connect 4 0 5 0; #X connect 5 0 1 0; #X connect 6 0 14 0; #X connect 7 0 9 0; #X connect 8 0 0 0; #X connect 9 0 8 0; #X connect 14 0 1 0;

hi

vincent rioux wrote:

pix_video (to read a stream from a webcam e.g.) 8 pix_crop (to divide the image) pix_snap to take a snapshot as a picture. pix_mean_color to compute the mean value.

[pix_snap] is unneeded here: this object will grab the render-buffer (what you see in the gemwindow) and make it available as a pix-buf. the output of [pix_video] is exactly that kind of image that is needed by pix_mean_color.

Moreover would it be possible to compute these values on a more complex shape than a rectangle?

images in Gem are always rectangular. so there are 2 ways to acchieve what you want:

• make [pix_mean_color] operate on "sub-shapes" of the rectangle image

(neither currently possible with this object nor planned)

• set the unwanted pixels (those between the bounding rectangle and the

borders of your more complex form) with a pixel-mask to some constant value. the offset you are introducing by this is constant (like the surrounding pixels) and can therefore be eliminated.

fmasdr IOhannes

Mathieu Bouchard a écrit :

On Thu, 24 Aug 2006, vincent rioux wrote:

...

pix_video (to read a stream from a webcam e.g.) 8 pix_crop (to divide the image) pix_snap to take a snapshot as a picture. pix_mean_color to compute the mean value.

if for example you want to reduce 240x320 camera input to 2x4 output,

[metro 40] | [#camera] | [#downscale_by (120 80) smoothly] | that's all.

hello Mathieu, thanks, i will try it (probably with puredyne).

but i might not understand what you want to do: what do you really need pix_snap for?

well, that was a mistake indeed.

...

Moreover would it be possible to compute these values on a more complex shape than a rectangle?

This can mean several different things, so you should say what you mean here, in detail.

i was refering to a possibly non-rectangular shape. i am not used to gridflow but i would guess that it is possible to take the mean color over a group of pixels.

v

On Fri, 1 Sep 2006, Mathieu Bouchard wrote:

On Fri, 1 Sep 2006, vincent rioux wrote:

...

i was refering to a possibly non-rectangular shape. i am not used to gridflow but i would guess that it is possible to take the mean color over a group of pixels.

actually the fastest way to do this in GridFlow is to use [#store]. This one is hard to beat. You put your image in the [#store], then you recall areas of it by sending a list of positions (a N-by-2 grid) and you will get a list of RGB pixels (a N-by-3 grid), which you can then average by using [#fold + (0 0 0)] and [# /].

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada