Hi.
I'm trying to create a pix delay loop in GEM, but it doesn't work as expected.
[pix_video]
|
| [r loop]
| |
[pix_add]
|
[pix_delay 100]
|
| [pix_gain]
| |
| [s loop]
|
[gemlist...]
It doesn't seem to do anything at all. I noticed that the [pix_add] help file has pix_ sources with their own gemheads. I tried throwing in [pix_separator]s all over the place, and that didn't help. Any tips or suggestions? I find the whole GEM dataflow a bit odd since it's all pointers (right?), and I'm used to PDP. Is there another way I can go about the same thing?
Thanks! -Ian
This looks a lot more like a problem for a PDP solution.
I would not think one could send the whole gemlist [s loop] back up the chain into itself. Remeber that in Gem it is NOT the video data passing through the gemchain but control data and pointers.
Perhaps some Gem developers may have an idea of how to make this work... Gem is not the solution to all problems, and if you are working with the video-data passing through cords mind-set PDP/PiDiP is a better choice.
I know Jamie is working on some PDP to Gem bridge stuff, maybe when that is ready you could combine the two and use PDP only for the pix_ stuff.
Also in gridflow the data is actually passing through cords... but I'm not sure what OS your running or if Gridflow is the best solution to your particular problem.
B.
Ian Smith-Heisters wrote:
Hi.
I'm trying to create a pix delay loop in GEM, but it doesn't work as expected.
[pix_video] | | [r loop] | | [pix_add] | [pix_delay 100] |
| [pix_gain] | | | [s loop] | [gemlist...]It doesn't seem to do anything at all. I noticed that the [pix_add] help file has pix_ sources with their own gemheads. I tried throwing in [pix_separator]s all over the place, and that didn't help. Any tips or suggestions? I find the whole GEM dataflow a bit odd since it's all pointers (right?), and I'm used to PDP. Is there another way I can go about the same thing?
Thanks! -Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Well I guess PDP would be the preferred way to do this, but AFAIK no one has compiled it for Windows, which, by unfortunate necessity, is what I need to write this for.
Any way to apply a recursive filter with a delay would be good. I just tried using [repeat], since looping is basically a kind of recursion, but no luck since I couldn't incrementally delay them.
Really all I need is to be able to copy the dereferenced pointer once, apply effects to it, and add that back to the original. Doing that recursively would be just what I need. I thought that's what a [pix_separator] would do.
Any thoughts?
-ian
B. Bogart wrote:
This looks a lot more like a problem for a PDP solution.
I would not think one could send the whole gemlist [s loop] back up the chain into itself. Remeber that in Gem it is NOT the video data passing through the gemchain but control data and pointers.
Perhaps some Gem developers may have an idea of how to make this work... Gem is not the solution to all problems, and if you are working with the video-data passing through cords mind-set PDP/PiDiP is a better choice.
I know Jamie is working on some PDP to Gem bridge stuff, maybe when that is ready you could combine the two and use PDP only for the pix_ stuff.
Also in gridflow the data is actually passing through cords... but I'm not sure what OS your running or if Gridflow is the best solution to your particular problem.
B.
Ian Smith-Heisters wrote:
Hi.
I'm trying to create a pix delay loop in GEM, but it doesn't work as expected.
[pix_video] | | [r loop] | | [pix_add] | [pix_delay 100] |
| [pix_gain] | | | [s loop] | [gemlist...]It doesn't seem to do anything at all. I noticed that the [pix_add] help file has pix_ sources with their own gemheads. I tried throwing in [pix_separator]s all over the place, and that didn't help. Any tips or suggestions? I find the whole GEM dataflow a bit odd since it's all pointers (right?), and I'm used to PDP. Is there another way I can go about the same thing?
Thanks! -Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Ah.. I wish there were enough windows developers to help with the windows stuff!!! I wonder what the stats are for what OSs people use PD on. I get the feeling it has an inverse relationship to what the developers are using! ;)
What are you actually doing with the add and multiply? for a test you could try using pix_data to create a pd message of the image, and then dumping that as a message back into the chain above.
I've done very little with pix_ stuff in Gem, since I'd not consider it the strength of Gem... so maybe some other Gem pix_ gurus have some ideas??
could you do something using multiple gem-chains? perhaps using pix_separator and/or the pix buffer stuff.
B.
Ian Smith-Heisters wrote:
Well I guess PDP would be the preferred way to do this, but AFAIK no one has compiled it for Windows, which, by unfortunate necessity, is what I need to write this for.
Any way to apply a recursive filter with a delay would be good. I just tried using [repeat], since looping is basically a kind of recursion, but no luck since I couldn't incrementally delay them.
Really all I need is to be able to copy the dereferenced pointer once, apply effects to it, and add that back to the original. Doing that recursively would be just what I need. I thought that's what a [pix_separator] would do.
Any thoughts?
-ian
B. Bogart wrote:
This looks a lot more like a problem for a PDP solution.
I would not think one could send the whole gemlist [s loop] back up the chain into itself. Remeber that in Gem it is NOT the video data passing through the gemchain but control data and pointers.
Perhaps some Gem developers may have an idea of how to make this work... Gem is not the solution to all problems, and if you are working with the video-data passing through cords mind-set PDP/PiDiP is a better choice.
I know Jamie is working on some PDP to Gem bridge stuff, maybe when that is ready you could combine the two and use PDP only for the pix_ stuff.
Also in gridflow the data is actually passing through cords... but I'm not sure what OS your running or if Gridflow is the best solution to your particular problem.
B.
Ian Smith-Heisters wrote:
Hi.
I'm trying to create a pix delay loop in GEM, but it doesn't work as expected.
[pix_video] | | [r loop] | | [pix_add] | [pix_delay 100] |
| [pix_gain] | | | [s loop] | [gemlist...]It doesn't seem to do anything at all. I noticed that the [pix_add] help file has pix_ sources with their own gemheads. I tried throwing in [pix_separator]s all over the place, and that didn't help. Any tips or suggestions? I find the whole GEM dataflow a bit odd since it's all pointers (right?), and I'm used to PDP. Is there another way I can go about the same thing?
Thanks! -Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
B. Bogart wrote:
Ah.. I wish there were enough windows developers to help with the windows stuff!!! I wonder what the stats are for what OSs people use PD on. I get the feeling it has an inverse relationship to what the developers are using! ;)
Usually I use and love Linux + PDP, but when the computer isn't mine... I guess what I need to do here is not try to use GEM as a substitute for PDP and give in to its paradigm.
What are you actually doing with the add and multiply? for a test you could try using pix_data to create a pd message of the image, and then dumping that as a message back into the chain above.
What I'd like to do is apply successive blurs and pix_curves at a slight delay, so the effect would be a very slow-to-fade motion blur with color difference over time. In general, I use delay loops a lot to apply temporal layering effects of all sorts.
I don't see how [pix_data] could be of help here, from the help file: "[pix_data] will get the colour of a specified pixel within an image when triggered." Unless I used... 307,200 [pix_data]s to totally reconstruct the image ;)
Is this sort of what pix_buf is supposed to be for? I can't get it to do anything, and the help file isn't exactly clear to me: "All images use a pull system, so as long as nothing is modified in the pix "upstream", the pix_buf is still valid."
I've done very little with pix_ stuff in Gem, since I'd not consider it the strength of Gem... so maybe some other Gem pix_ gurus have some ideas??
I suppose not. Perhaps there are some snazzy, similar things I could do with OpenGL. Do you have any tricks for using video input as an input to GEM's OpenGL? I could see a similar effect being accomplished with semi-transparent objects laid over one another, but how could I use pix_ information to effect the shape of an OpenGL object?
could you do something using multiple gem-chains? perhaps using pix_separator and/or the pix buffer stuff.
I thought of that, but a [pix_video] object can only exist in one gemlist per camera.
Thanks for the tips. Cheers, Ian
B.
Ian Smith-Heisters wrote:
Well I guess PDP would be the preferred way to do this, but AFAIK no one has compiled it for Windows, which, by unfortunate necessity, is what I need to write this for.
Any way to apply a recursive filter with a delay would be good. I just tried using [repeat], since looping is basically a kind of recursion, but no luck since I couldn't incrementally delay them.
Really all I need is to be able to copy the dereferenced pointer once, apply effects to it, and add that back to the original. Doing that recursively would be just what I need. I thought that's what a [pix_separator] would do.
Any thoughts?
-ian
B. Bogart wrote:
This looks a lot more like a problem for a PDP solution.
I would not think one could send the whole gemlist [s loop] back up the chain into itself. Remeber that in Gem it is NOT the video data passing through the gemchain but control data and pointers.
Perhaps some Gem developers may have an idea of how to make this work... Gem is not the solution to all problems, and if you are working with the video-data passing through cords mind-set PDP/PiDiP is a better choice.
I know Jamie is working on some PDP to Gem bridge stuff, maybe when that is ready you could combine the two and use PDP only for the pix_ stuff.
Also in gridflow the data is actually passing through cords... but I'm not sure what OS your running or if Gridflow is the best solution to your particular problem.
B.
Ian Smith-Heisters wrote:
Hi.
I'm trying to create a pix delay loop in GEM, but it doesn't work as expected.
[pix_video] | | [r loop] | | [pix_add] | [pix_delay 100] |
| [pix_gain] | | | [s loop] | [gemlist...]It doesn't seem to do anything at all. I noticed that the [pix_add] help file has pix_ sources with their own gemheads. I tried throwing in [pix_separator]s all over the place, and that didn't help. Any tips or suggestions? I find the whole GEM dataflow a bit odd since it's all pointers (right?), and I'm used to PDP. Is there another way I can go about the same thing?
Thanks! -Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi Ian,
[pix_delay 100]
If I remember correctly, the pix_delay object needs the amount of delay explicitly set via its second inlet ... but you did that probably. Anyway, it is probably right that GEMs paradigm doesn't allow for that type of manipulation, maybe johannes can get into this more deeply. The only ways to do iterative processing with gem i can think of is to use either pix_buffer, pix_buffer_read and pix_buffer_write (it's really awkward and rather slow, but it does work). The other solution would use pix_snapshot, but I haven't tried that yet. There was a patch (by Ben Bogart iirc) somewhere on the list that illustrated how to do this ... I'll dig it out if you can't find it. However, the latter pretty much maxed my CPU out.
hope this helps, thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de