Hi,
Is there some way to get all the RSS feeds? I can see the individual ones, but not a general one. Thanks.

Hi,

I started using PureData a few month ago. Mostly doing some live projection stuff from pinhole pictures I have made and a webcam I use for masking, like in BW printing. I need some controllers to keep my hands off the laptop I use.

I'm running the latest Pd extended version with the recently updated GEM extra under Windows Vista. It's a tablet PC, Lenovo X61t without the (finger) touchscreen, just stylus interaction.

I have a cheap Behringer BCR2000 that works fine after making a usable one from two half dead ones.
There is no lag between turning a button on the controller and the effect in the patch.

I just bought a Korg NanoPad controller as well.
I tried the native and Korg Midi drivers. I have a 2 second lageven in the Midi test patch included in Pd with or without the other controller connected. I was looking forward to it's XY pad... Too bad... it's totally unusable.
Just to make sure I tried it in Ableton Live which is probably one of the pieces of software for which most controller drivers are optimized. It works perfectly. So I guess there is some trouble between pd and the drivers.

Has anyone here any experience from such hardware?

thank you
Pierre-Olivier

www.puffskydd.net
www.flickr.com/photos/pob31
www.dailymotion.com/puffskydd

Here is a slightly modified version that now seems to work out of the box on Windows too.
[text3d] was probably unhappy, at least some instances because it couldn't find the font.
I couldn't get the .arg] to work at all so I have a direct connexion and now it works fine.
I also added the [gemframebuffer] for the jpg depth maps. I don't know if it was necessary, since I changed this before the I made the direct connexion to the bokeh shader and got things working then.

I also got rid of the color setting in one of the framebuffers.
texunit 0 seemed to be used by some other [gemframebuffer] (the ones with the blur shader) so I used texunit3 instead, but this may not be relevant.

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

I just added the render order as a "good practice" measure (from my point of view) and since I was tinkering with the patch and I didn't want to break things because I would change something elsewhere.

Anyway, thanks again for patching all this together. I already have it in a big performance patch. I have to try working with it now.
Cheers

I didn't set the colour, it was there in the first place. I don't know what caused this if you didn't put it there...

A single [gemhead] with a [t a a ...] is good to know what is rendered in what order.
The number in the [gemhead] is good to know what is rendered in what order as well.
First the are rendered the positive numbers in increasing order (ie. first 1 then 2) then the negative numbers in decreasing order (ie. first -1 then -2). This is not specific to Windows.
Otherwise I think it's the patching order that defines what is rendered first and so on. I find this to be very confusing since you can't really see the order and it can be easily disrupted.
I've noticed that [gemhead] in subpatches are rendered out of order too, even with a numbered [gemhead]. Probably related to the order of creation of the subpatches there too.

I got rid of [text3d] because otherwise I couldn't use your patch. Feel free to put them back if you want. I think it crashes because it can't find the font. But this is more or less erratic depending on the version of GEM and Pd. We discussed this with IOhannes on IRC yesterday. He suggested this was related to the font not being found. Maybe including a font in the patch folder and specifying it to [text3d] would solve this issue.

[; dirty 0( should do the job.

I made a few modifications. Now the jpg maps work fine. I think a gemframebuffer was missing.
i got rid of the text since I had a few problems with [text3d]

edit: New version below, closer to the original patch.

Hi.

I spent the afternoon yesterday and got it to run on Windows and adapted the code to have a webcam as a depth texture.
Had a problem with [text3D]. I also have problems with [pix_image] - All GEM related. I should try on an earlier version of GEM to see if it solves anything.

edit. Now fixed. Had to remove a dll to disable imagemagick.

Great!!

I'll post back to let you know how it goes on my windows boxes. Cheers

But testing is welcome!

The more testers, the more bugs found and the sooner the stable version if you see what I mean...

You have [relay] that does precisely that.

Well not so perfect. It comes back regularly to the former situation with a one or two second lag.
I tried MidiOx+MidiYoke to merge both controler info and send them to pd.
MidiOX sees everything fast even when pd has that lag.
It goes away after restarting pd. Sometimes it only take unplugging and replugging the controlers and updating the Midi menu in pd.
Any help appreciated. Thanks

Just found what was wrong!
Too many Midi entries in the registry. Cleaned it up with some m-audio util. (MIDIFix)
Works perfect now.

Thanks for your reply. But I have no audio output, just video using GEM in this case.

Besides the problem occurs with just a [ctlin] in a new clean patch and no other programs accessing the controller. This is just lag in the Midi transmission to Pd.
The BCR2000 works normally without any noticeable lag.