[PD] Re: Soft Rock EP

[Paris Treantafeles]

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 at 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;