Is there a way in pd to have a sequence of symbols that you can output one at a time?

I saw a thread on this forum suggesting that data structures would be useful for this, but I couldn't get it to work -- [append] has no method for "symbol." (Unfortunately I can't find that thread again now.)

Then I found an old pd list post where Miller Puckette admitted that data structures had not been fully debugged. So, even though the documentation states that symbols may be stored in data structures, it seems this is not actually the case.

Is there any other way?

I find it hard to imagine that it would be completely unsupported to have a sequence of strings? (Because nobody ever needed to do this before...?)

At worst, I suppose I could store numbers in a table and just require that sections have numeric identifiers instead of meaningful names. It would really be a shame if I had to do that, though.

Thanks,
hjh

Hi,

I have a pd-extended patch that used to work perfectly, back when I was on Ubuntu 10.04 (upgraded during the summer). Now it crashes pd when I try to start the gem window a second time.

I simplified the patch to include only pix_video --> pix_texture --> rectangle and the control bits that start and stop the video. This reproduces the crash (attached).

The idea is that the toggle should turn on the gem window and capture video from the built-in webcam -- then, clearing the toggle should stop video processing. You should be able to keep going like that, but it crashes when you enable video a second time.

I can avoid the crash by closing the patch and reopening, but this isn't convenient for long programming sessions where I might need to start and stop the video dozens of times in an hour.

It's probably something simple I'm doing wrong. Would someone mind taking a look at the patch?

Thanks,
hjh

http://www.pdpatchrepo.info/hurleur/pix_video-crash.pd

Okay, I have been fighting with this for about 7-8 hours now, and it just isn't working.

The basic outline of the patch, now with gem objects (and leaving out some details) is:

[gemhead]
v
[pix_video]
v
[pix_movement]
v
[pix_crop] -- the x and y offsets are driven by a subpatch that acts like a nested loop
v
[pix_blob] -- mode 4 = alpha channel

... and the x, y and size outlets are packed into a list and sent out by OSC.

The problem is that pix_blob very frequently outputs nothing. This really shouldn't happen, if all the objects were doing what I think. Explanation --

Suppose in one frame, I crop the image to the top left quadrant and calculate pix_blob just for that quadrant. Then, on the next frame, I crop to the top right quadrant and get pix_blob again. The successive frames may have very different blob coordinates, and I'd expect to get the different sets of coordinates each time. Instead, pix_blob goes silent sometimes.

I thought, maybe it goes quiet because there was no change -- but these are different areas of the image, and the likelihood of having the same centroid in two different slices of the image seems rather low.

Or maybe it's because the frames are so different that pix_blob doesn't know what to do. (I have no way to guess, in the absence of documentation of exactly what pix_blob is doing.)

Sorry to keep posting so much about this, but I really have to get this working, documentation is not answering my questions, and my previous thread (link) has gone dead. I'm starting to get a bit desperate. At this point, I may have no choice but to chuck out the vast majority of the data I was hoping to get from the camera and go for just one, simple, dumb centroid. Rather frustrating.

Thanks in advance -- I will give credit in the concert program to people who can help me get this running.

James

PS You also need a 320x240 black image. saved as "black320x240.png" - I made one with GIMP. Or just delete the pix_composite part.

http://www.pdpatchrepo.info/hurleur/frame-diff-gem.pd

Hi,

Been a while... my webcam -> gridflow -> OSC -> SuperCollider patch is working really well in Linux. But now a problem -- I need to make this available to some students who are running Windows. [#camera] doesn't work in Windows (unless something changed since the last stable release).

So then I thought, the first time I tried to use gridflow, I couldn't figure out how to use [#camera] so I ended up doing [metro] --> [gemdead] --> [pix_video] --> [#from_pix]. Then I found... in Windows, no Gem integration ("couldn't create" [gemdead] and [#from_pix]).

... which pretty well hoses a major project for the semester.

So I'm evaluating alternatives. Main question for here is: Is there any way to get webcam input into gridflow under Windows? (I'm guessing no.)

If not, what would be the next best thing?

The gridflow objects I'm using are:

[#camera]
[#downscale_by]
[#fastblur]
[#rgb_to_greyscale]
[#reverse]
[#motion_detection]
[#slice]
[#moment 1]
[#fold +] and [#redim] to sum the pixels

Is it feasible to replace these with Gem or other objects?

Would appreciate some ideas, soon if possible -- if I'm going to get this project off the ground, I need to do it quickly.

Patch attached. (Also uses mrpeach OSC objects, i.e., pd-extended.)

Thanks!
James

http://www.pdpatchrepo.info/hurleur/frame-diff-linux.pd

I'm trying to follow the struct tutorial here: http://puredata.info/Members/ggkarman/Tutoriales/datastruct_en_02/view

It's not working.

I'm attaching my test patch, which replicates the tutorial's objects through page 3, as far as I can see. I only changed the names and included just one float in the struct instead of 3.

~~ test patch contents
[pd struct1] contains [struct struct1 float x]
[pd data1] contains nothing

[traverse data1(
|
| [button]
|/
[pointer]
~~

Sending the "traverse" message causes the pointer to say "pointer: list 'data1' not found." That's rather different from what the tutorial says it should do.

pd extended 0.43.3 on Ubuntu

Thanks.
hjh

http://www.pdpatchrepo.info/hurleur/struct-tutorial.pd

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

Just discovered in pd-extended (from the [gate] help patch) that setting the open outlet by passing a number to the right-hand inlet also pops that number out the left outlet.

So if I want to send data out one of two outlets and not pollute one of those outlets with the outlet index, I actually have to make a [gate 3] and never use outlet=1.

This is (IMO) counterintuitive enough that's it's worth asking what is the rationale.

No big deal, I'll just add the extra dummy outlet. Just curious.

E.g., open the help patch H05.filter.floyd.pd. Right click on the array -> properties -> array window -> "View list."

can't read "0": no such variable
can't read "0": no such variable
    while executing
"array_viewlist .gfxstub13fd070 $0-array1 0"
    invoked from within
".gfxstub13fd070.listview invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list]"
    (procedure "tk::ButtonUp" line 23)
    invoked from within
"tk::ButtonUp .gfxstub13fd070.listview"
    (command bound to event)
I saw this in pd extended 0.41 under win7 and thought it was the usual M$ uncooperativeness. But I saw it again just now in 0.39 on my mac.

It is a [i]real bother[/i] when trying to write an array of scale degrees for instance, when you want them to be integers but dragging the points gives you floats. Certainly there's a way to view/change the values [i]as numbers[/i] other than saving the patch and opening it in a text editor? (That won't go over too well with my student...)

James[/list]

New to pd, but not new to computer music or to programming (I've been using supercollider for many years). I'm looking at pd to get familiar with data flow programming in preparation for (potential, so far un-materialized) teaching jobs in the future -- don't care to spend $500+ for MSP when I don't see myself using it for production in the foreseeable future!

I'm looking for an object that's basically a signal-rate integrator, where the next output sample value is the previous value + the input signal. Ideally it could reset to zero on receipt of a bang, but if that isn't possible, I can work around it using some snapshot magic. (Or, if it loops back to start when it reaches a certain output value, I can work with that too.)

I searched the forum and found only this, but this is for purely control signals: http://puredata.hurleur.com/sujet-2402-bouncing-counter - I need it at audio rate for tabread4~.

Sorry if this is too basic a question -- searching the help is a bit less than convenient.

Thanks
ddw

Actually, in that post, I wasn't thinking of lists at all -- I said "data structures" -- but I realized later that lists would be a better (maybe the only) solution. ([append] referred to http://puredata.info/docs/manuals/pd/x2.htm#s9.2 -- nothing to do with "list append.")

I was thinking of [coll] from Max, which stores arbitrary data under (usually) numeric keys. I had thought pd's data structures could do that, but that won't work as long as a data structure can store only floats.

I opened this thread because a documented feature -- "In general, data structures are built from four data types: scalar floats and symbols..." -- is not in fact supported. If there's no bug report for this, one ought to be opened. I'm attaching a patch to reproduce the bug.

I have a feeling the "fix" was to disallow symbols, but then not to update the documentation to reflect the change. I'll admit, it was a wee bit frustrating to wrap my head around traversing a data structure (not the simplest thing in the world) only to find that it couldn't do what I wanted...

In any case, I just found list-dripslow, which will do exactly what I need, so I can meet my immediate needs (and definitely more simply!).

hjh

http://www.pdpatchrepo.info/hurleur/struct-vs-symbol-bug.pd

Never mind, I see what it is now. The list name given with "traverse" should include "pd-" as a prefix.

[traverse pd-data1(

No worries. (Is this perhaps the first time anyone has ever said "no worries" with respect to structs?)

hjh

Further info: With this slightly simpler patch, I can do this:

1. Click [create( to open the gem window manually.
2. Click the toggle to start the camera.
3. Click the toggle to stop the camera -- gem window remains open with the last image displayed.
4. Repeat 2 and 3 -- no crash. So, merely starting and stopping doesn't cause the problem.
5. With the camera stopped, click [destroy( to open the gem window. (No crash.)
6. Still stopped, click [create( to open it again. (No crash.)
7. Click the toggle to start again. **Crash**

That leads me to a workaround -- for now, I'll just have to keep the same gem window open.

But I'm curious why this crashes pd now, when it didn't before.

hjh

http://www.pdpatchrepo.info/hurleur/pix_video-crash3.pd

Sure, it's a good idea to keep opencv in mind. In this case, I was already just inches away from getting the gem approach to work. I have a feeling it would have taken more time to learn a whole new set of objects. But a future version of the project might use opencv.

BTW it's all working quite nicely now. The only hiccup is that the first time I turn on the camera in Linux, I get a whole bunch of

error: GEM: Someone sent a bogus pointer to copy2Image
error: GEM: Someone sent a bogus pointer to copy2ImageStruct
error: GEM: Someone sent a bogus pointer to copy2ImageStruct

But that goes away if I switch the camera off and switch it on again, so I'm not very worried about it. I don't remember seeing it do that in Windows.

Thanks again for all the help! It was a bit frustrating when what I thought would be a 30 minute job turned into 9-10 hours, but it's all working now !! (and in some ways, the data coming out are smoother than I was getting with gridflow).

James

Ah, right, openCV -- I always forget about that -- I've had epic troubles trying to download from their site (from mainland China).

That's worth a look for a future iteration. For the moment, I'm under enough time pressure that I think I had better just simplify.

Well, actually I'll have one go at the [t a a a a a...] approach. Actually it wasn't clear to me that you could do that. I was worried that one pix_crop operation would alter the image and subsequent [pix_crop]s, even in a different branch, would work on the previously cropped pix. But if that's wrong, then I have no problem moving the blob stuff into a subpatch and copying it.

Thanks!
James

Hm, I might be getting just about there. Just wanted to run this patch by some folks who have more gem experience.

It *seems* to be producing reasonable x, y and size values from pix_blob. I haven't tried to do the slicing yet (the logic is basically there in my bigger patch, just out of time and energy for tonight). The size is quite small in magnitude, but it does go handsomely to 0 when there is not much motion.

But, I suppose there might be some mysterious thing that I haven't got quite right (being completely nooby wrt gem). So if someone wouldn't mind offering another pair of eyes, I would much appreciate.

Thanks!

James

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

Never mind, stupid question. I misread the position of the comment in the help patch.

Left inlet = outlet index; right = data to pass thru.

Sorry for noise.

Made some progress -- actually, fairly convinced I could do the analysis on the slices -- but I'm stuck on this point.

In gridflow, I could use #t and #var to pass the same grid multiple times -- so I could get one image from the camera and crop (slice) the same grid 25 times.

In gem (if I'm reading the help patches correctly), if I pass [pix_video] --> [pix_movement] --> [pix_crop], the cropping will be done only when that frame is being rendered -- no way to crop the same frame several times.

From the gridflow patch, I'm getting about eight frames per second (not great, but enough for the triggering work that I'm doing in supercollider). So, if I wanted to get 25 slices eight times per second, I would need to set the gemwin frame rate to 200 and I'm guessing that would not be very successful.

So I guess my options are:

• Reduce the number of slices (and thereby the frame rate). With nine slices, I could get away with 72 frames per second. This might be okay for this purpose, but I hoped to avoid that.

• Is there yet a third image framework in pd that will let me do this?

• Beg the gridflow-dev list for an update where the camera works in Windows (which may be a lot to ask).

Any other options I haven't thought of?

I hope not to be a pest, but I've got some students waiting to be able to use this thing and I'm stuck...

Thanks bunches --
James

[#moment 1] is just a centroid calculator, nothing more than that. I'm attaching a screenshot of an example, where the only pixel that's lit up is at x=2, y=1. [#moment 1] returns a two-item grid: y, x.

I'm not doing any checking within pure data whether there is or is not any movement in a slice. I'm just getting centroid x and y from [#moment 1] and summing the pixel values for a raw "amplitude" (wrong term) of movement. I'm sending a separate OSC message to SuperCollider for each slice with those three values: 25 OSC messages per frame.

Centroid, slicing the frame and summing the pixels -- I don't know how to do that in Gem.

Hm, summing, maybe [pix_mean_color]. And frame difference, [pix_movement2] (I only need grayscale).

Oh wait... is the centroid [pix_blob]?

Still no idea about the slicing.

James

http://www.pdpatchrepo.info/hurleur/moment-1.png

Thanks for the reply.

The outline of the patch is:

• Get the video image from the camera.

• Reduce the resolution by a factor of 4.

• (Optionally) blur.

• Convert to grayscale.

• [#motion_detection] is a frame-difference calculator, with some noise reduction inside. I don't know how the noise reduction works. If something is moving in one part of the image (especially edges with contrasting brightness), then the grayscale values of those pixels will be different between frames and that area will be brighter in the motion_detection result. But if an area is static, the pixel values between successive frames will not change much, making a darker result.

• Then I use [#slice] iteratively to get 25 sub-frames (a 5x5 division).

• For each slice, [#moment] gives the centroid x and y (average of the coordinates, weighted by the pixel value -- so if most of the white stuff is at the top left, x and y will tend toward the top left).

• I'm also summing the pixel values within each slice to estimate the amount of motion -- so I can tell the difference between, e.g. two areas of motion in opposite corners vs motion in the center.

Let me know if you need more detail.

I also posted on gridflow-dev, which was pretty responsive in the past but I haven't heard anything from there yet.

Thanks again!
James