hi, I have just built gridflow on my ubuntu box as part of my efforts to find software/ an API where I can manipulate images/movie frames at the pixel level.

I'm trying to do some proof-of-concept kind of things with gridflow now - the simplest being to sort component pixels according to colour etc.

to me, #grade looks like it may be the key object (when combined with others). What I really need are some examples of building a sorting patch using #grade - or ways of working iteratively upon the contents of grids.

Gridflow is very elegant but unfortunately a little beyond my comprehension at this point: I get the feeling that this is due to the design: that it allows you to do complex processing & operations with a minimum of objects involved.

anyone got some pointers/ideas?

Ash

cool mr. God,

yes, this build seems to work well on an Intel iMac I have here at work - help menu fixed & PDP/PiDiP objects working better than before too! usual complaints about codecs from the console - I need more time to look at these.

Is it...just possible that I may be able to move my working platform (which relied heavily on PDP etc) onto a Mac? wow, that would be cool

--clarification: the codecs issue is one about moving qt files made on linux to a Mac & re-saving them with VLC so that QT7.x can open them correctly - this is a workaround for the 'bad atom' error (ie. problems in the file header). More to do with libquicktime than PD I imagine.

Ash

cool, you now have 3 options:

a) my old analogue art-school boy method
triggering from a table of cue-points
c) movement-detection

This is all kind of like 'good automation' - not where you just press a button & everything assembles itself - but where you get involved in aspects of making your work (where you may have least expected) that open holes in the software AND your methodology... blah blah

Ash

hi - if yr not using audio tracks in the movie, then you could record an audible tone on the movie sound track at the desired point & get PD to listen for this as a trigger. This is an old idea that can be taken quite a way (like having a continuous frequency on the film soundtrack & using pitch-following to control stuff too).

Sort of like playing with super-8 film 25 years ago

Ash

thanks for sharing. You got 5 x 25 frames at 25fps - so you didn't drop any frames - try and pass a name consisting of a path to the object & it might save your files to there.

The help file notes that TIFF output is slow - trying jpegs at high quality would be fine re-encoding into a movie - if that's what you want to do with the resulting image sequences...

Ash

SCSI disks for use with pdp_qt? Or perhaps even firewire drives - that standard is meant to offer the same advantages of highspeed async IO (depending on how the particular drivers work I guess).

With pdp_fqt - does enabling threads help at all? possibly not... unless DSP is already running.

Maybe stream media from another machine, though that's getting very elaborate & startup could still be slow..

A

Yes, you need to keep going. That's what open source is all about. You could do far worse than writing up whatever you discover too. I'd stick with GEM & see where that gets you as it basically is OpenGL repackaged.

A

yep that's a situation that came to mind, Data moving around needlessly. & how to determine which subsystems a particular object or relationship of objects is going to hit. Don't let us stop you though - sounds like good old pd insane fun

Using a profiling tool that will tell you what your graphics card vs. CPU are doing could also be useful. That's not something I know much about sorry.

A

I can't find it now but I saw a list of the GEM objects that 'wrap' OpenGL functions somewhere. I imagine these are wrappers in the sense that they allow you to call x. function as a pd object. I know nothing about these - maybe if you were to grab a basic OpenGL sample & try to translate the function calls & program flow from c or c++ using the GEM & other pd objects...it all might become clearer. Please post back if you do - I'd love to know

Determining how much of the processing would get offloaded to the GPU on a video card - I think that would be a bit of a black art. I would just try to check if CPU load changes depending on how you build & rebuild your patch.

I would expect that the higher-level GEM objects are already doing this (using the GPU).

A

hi,
well, I can't make it work either. I setup MaxMSP & PD 0.39-extended rc2 & a 'network' session in Apple audio midi setup. I configured both apps to use this session for midi out (max) & midi in (pd).

PD couldn't see anything arriving at a notein object (in omni mode - no args) - I was definately sending from Max. Max couldn't communicate with itself either for that matter, when using the network session.

When I switched the inputs to IAC bus #1 - the communication all worked fine within the apps & between them.

Guess that saves me reading the documentation (if there is any).

Probably everything is handled by IAC inside localhost - since this is what feeds the TCP/IP midi routing probably. I wonder if it really would be any more efficient...

A

This is new in Tiger I think - 'CoreMIDI' API - previous versions needed 3rd party stuff to do it:
http://www.soundonsound.com/sos/jul05/articles/tiger.htm

or Panther:
http://www.nerds.de/en/ipmidi_osx.html

I'm sure I remember seeing freeware/open source too but where? I'm assuming here that routing within the computer should be possible...

A

PD allows you to save out patches in a 'max' format - this is in a text format that's a bit different to the pd one.

That would allow you to open them in Max/MSP - but you are likely to get some very...interesting results.

Can you have the 2 programs side by side perhaps - that would be the easiest way I reckon.

A

hi,

looks like you can start pdp_theorin~ playing in two different ways:

auto: just open a file & it starts playing.

manual: you have to bang it with a metro object (at the playback rate you want). So in that case, you need to open a file, then start the metro - likewise, stop the metro to pause playback.

• this is my crappy explanation of multi-threading (flame-free zone thanks) -

Threading allows the computer to run tasks 'concurrently' - that is, with the illusion that the CPU is handling several tasks simultaneously (really, it's devoting a slice of time to every program that's open/running at any moment). Having the option for pdp_theorin~ means that it gets it's own subprocess (to do it's thing - like fetch data from the disk etc) running alongside anything else that PD happens to be doing (like telling the metro object to fire when the time is right).

Most of the pdp player objects allow for threading - It can help file playback/recording in terms of efficiency in the case where the rest of PD doesn't actually have work to do at that instant. As to 'when to turn threading on/off' - well, that's going to be harder to decide - just keep an eye on the CPU load meter & experiment...

It's also somewhat more than this - you should look at the help file for pdp_control. The point is to be able to tune the processes that can kill other parts of a complicated PD patch (ie. processing video vs. avoiding audio glitches).

• end of blah - it's been a while since I wrote anything other than perl scripts really -

What sort of quality are you getting from theora/ogg files?

Ash

ummm, don't know much about this object. I'm not in a position to even test the following I afraid: pdp_theorin~ does seem to output an int when it reaches the end-of-file. In the help patch you will notice a slider connected to the right-most inlet. This lets you seek to the starting byte of the file. SO... you could use the end of file message to send 0 to the right inlet. If the object is in 'manual mode', then the metro will keep on bangin away while you manipulate the read position in the file.

Given the author's caveats about seeking in theora this could be an interestingly dodgy file player...

a

What about AppleScript-automator, I'm sure you could whip up something to import the aiffs & delete them...

I didn't realise that DP (well anyone) still used SDII - I have fond memories of SoundDesigner & old Digidesign hardware: 'it just worked' (well, usually).

second that. The format really relies upon the old-style Macintosh Resource-fork that used to be the norm on MacOS.

see http://www.mega-nerd.com/libsndfile/FAQ.html#Q013.

I guess the question is - why do you need to do this? & on what platform? Probably better to write out aiff files & then convert/import them to SD2 in the environment where you need them.

Ash