If you use Gridflow you can downscale and then upscale it. Try using the attached patch

http://www.pdpatchrepo.info/hurleur/pixellate.pd

when I installed gridflow, it caused my old patches to lag massively, even though they weren't using any gridflow nodes at all, had to completely uninstall PD and re-install it without gridflow to get them working fine again.. Isn't that strange? I am on vista though..

Spent the better part of today reverse engineering gridflow's "multiblob" example patch -- time well spent, actually, as I now have a much better idea what it's actually doing than I would if I had just cribbed the example.

The only trouble is, it's s-s-l-l-l-l-o-o-o-o-o-o-w-w-w-w-w-w-w-w-w, chewing anywhere from 30-60% CPU according to Ubuntu system monitor. So I'm wondering how to pick up the pace. My patch is attached.

First obvious thing is, reduce the image size by another factor of two. After [#downscale_by 4 smoothly], the image is 320x256. I may not need that much resolution, but I'd prefer to keep that as a last resort.

Second thing -- I'm not sure how much efficiency I'm losing by reading the webcam using gem and then converting to gridflow. I ended up doing it that way because I simply could not get [#camera] to grab images at all. The #camera panel does identify the laptop's built-in webcam (BisonCam,_NB_Pro) but 'bang'ing a [#camera 0] only produces this error.

error: [#io.videodev in /dev/video0 0] inlet 0 method bang: alloc_image: ioctl VIDIOCGMBUF: Invalid argument

(Ubuntu Lucid (2.6.33-29-realtime), 64-bit, pd 0.42.5-extended, installed gridflow from the puredyne PPA https://launchpad.net/~puredyne-team/+archive/ppa/+files/gridflow_9.12-1%7Eppa1%7Elucid1_amd64.deb)

Beyond that, I don't know enough about what gridflow is doing under the hood to use it more efficiently. Any pointers?

Thanks,
James

http://www.pdpatchrepo.info/hurleur/labelling-to-osc-blur9.pd

Do any users of gridflow happen to know why none of the pddp_open objects in gf_tutorial_intro can load?

doc_h_loadbang: bang
pddp_open pure-data-1
... couldn't create
pddp_open pure-data-2
... couldn't create

pure-data-1.pd thru 9 exist under gridflow/doc/tutorials, but the other referenced files (especially GridFlow-4, introduction to live video, which is the most interesting to me) appear to be nowhere in the distribution.

Just hoping somebody might know about this... I'm not quite ready to join Yet Another Mailing List just for this issue.

Thanks,
James

I got a response from the creator of Gridflow on the mailing list, which I'll reprint here in case it can help people

I've made a simple video mixer in Gridflow (9.13) and I want to send the output to an external projector. I've set up my computer so that I can drag windows to the second screen, but when I attempt to go full screen using [#out sdl] and then pressing Esc it goes fullscreen on both screens.

Sounds like the kind of problem that can't be solved in GridFlow. It's a SDL issue.

If I use an [#out window] object, which I believe is an x11 window, there's no way (that I can find) to go full screen, so I'm stuck at with an 800x600 window on a 1366x768 screen. I did attempt to use a [#scale_to (768 1366)] object to emulate being full screen but the scaling causes a massive drop in framerate.

Changing the screen resolution is a sure way to avoid even having to scale.

[#scale_to] is a simple abstraction not meant to be fast or fancy. It would be a good thing to make a much better software scaler for GridFlow (interpolating and faster), but it wouldn't be as fast as a hardware-accelerated scaler, or simply changing the screen resolution.

Changing screen resolution also gives you the best image quality when using a CRT, whereas on a LCD it just means you're getting the LCD monitor to do the scaling for you.

Can anyone suggest how to go fullscreen on only one screen, how to go fullscreen using an x11 window or some other way to do this?

There is the "border" method for removing the border, the "move" method to put a window wherever you want (compute window coordinates to match the way the mouse travels from one screen to the other).

I've made a simple video mixer in Gridflow (9.13) and I want to send the output to an external projector. I've set up my computer so that I can drag windows to the second screen, but when I attempt to go full screen using [#out sdl] and then pressing Esc it goes fullscreen on both screens. If I use an [#out window] object, which I believe is an x11 window, there's no way (that I can find) to go full screen, so I'm stuck at with an 800x600 window on a 1366x768 screen. I did attempt to use a [#scale_to (768 1366)] object to emulate being full screen but the scaling causes a massive drop in framerate.

Can anyone suggest how to go fullscreen on only one screen, how to go fullscreen using an x11 window or some other way to do this?

I'm using Gridflow 9.13 with Pd-extended 0.42.5 on a Dell Studio 1555 using the ATI Radeon 4555 proprietary driver running Ubuntu 10.10.

Hello everybody,

it's been a long time since i started wondering about getting some advanced visual effects out of pd. I know "advanced visuals" could mean a lot of different things, but let's say I am thinking of pixel stuff like depth of field, bloom, glow, blurring. I kind of tried everything, from basic pix effects to freeframe fx and gridflow convolutions but no matter what I do, since these effects are cpu based the resulting patch is always dead slow.

My first question is: as far as i know pd is born as an audio software, does it make sense to keep pushing it into the domains of visuals?

Don't get me wrong, I love pd and I know the amazing stuff you could get out gem and gridflow. Let's think of all these kind of 3d manipulations, sound visualization, video mixing, opencv stuff, pmpd physics simulation, just to name a few. You could just get some wonderful visuals by only using geos and simple texturing. But, sometimes, I find myself in front of limitations, like the ones about pixel effects I said before, and I wonder if I should just leave pd to what it's good for and move to video driven software like vvvv or "classic" programming environment like Processing.

I know a lot of stuff I've been talking about could be achieved with an irrelevant cpu cost by leaving calculations to the gpu. I think GLSL potential is extremely huge and I got to work some basic blurring, glowing and blooming effects I found on the web, but still seems a little workaroundy for me (especially multipass rendering).

Here is the second question: could opengl and glsl scripting be the solution to my first question? and what do you guys think about having a place where we can host a (hopefully growing) collection of ready to use GLSL effects along with example patches? maybe with a standard framework of objects for multi texture effects and general GLSL handling?

Ok, that's all. Any feedback will be extremely appreciated.
Here follows a simple GLSL blooming effect applied to gem particles (works on macosx 10.5, pd extended, gem 0.92.3)

http://www.pdpatchrepo.info/hurleur/effects.zip

The GridFlow libary was amazing. I've fiddled with it all day. Great!

I haven't been able to do what i want yet, but i'm sure it's possible with mixing up the right gridflow objects in the right order. Maybe anyone having experience with gridflow could help:

I open an image, and now i have a grid with all the pixel-rgb-values (like (1 255 4) (3 45 55) etc.

What i want to do is for example take all the blue-values and use them for controlling the frequency of an [osc~]. Starting with the first value and switch to the next after a certain amount of time (controlled by [metro]), and then the next etc...

I've tried to use [#redim], [#to_float] and [#to_list] to figure it out, but i'm not sure how to get hold of one value at the time. Can anyone please help?

Best regards,
ZnakeByte

Hi,
there is also a conversation about BPM measuring in the mailing list these days.
As mentioned, in GridFlow you can find [fps] AKA frames per second . A very handy object in which you can specify measuring time for bangs etc detailed stuff.
Here is the help-file: http://gridflow.ca/help/fps-help.html

A slit scan patch has already been developed with Gridflow. Download the library, follow the installation instructions and look for the slit-scan example. It may be difficult to understand what's going on in the patch, but I'm pretty sure that's what you're looking for. Hope it helps.

Download link:
http://gridflow.ca/