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?
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.
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.
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.
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.