[PD] still struggling with basic understanding of Gem dataflow

[John Harrison]

On Wed, Mar 25, 2009 at 10:22 AM, marius schebella <
marius.schebella at gmail.com> wrote:

> hi john,
> I just looked at your patches, here's what I think:
> 1) pix_buffer_write seems to copy and clear the pix buffer. so if your
> pix_video is connected to pix_buffer_write it is gone and you don't
> see it anymore (rectangle stays white). I am not sure if this is a
> bug, it seems strange to me, too. but as soon as you disconnect the
> pix_buffer_write the image will be shown on the rotated rectangle.


Yes I also noticed that disconnecting the [pix_buffer_write] fixes the
problem. i see that sort of thing in Gem all the time ([pix_mix] for
example.) But wouldn't a [pix_separator] fix this then? It doesn't...

>
> 2) the rotateXYZ does not rotate the pixels, but only the geometry
> that this texture is mapped to (the rectangle). so in your left
> example you go from gemhead through buffer_read, texture to the
> rectangle. in that line no rotationXYZ is applied to the rectangle.
> marius.

So why does the right example work? Because the rotation happens after the
[pix_buffer_write] even though [pix_buffer_write] is later in the rendering
chain? Or perhaps the rotation is ignored by [pix_buffer_write]? And at the
same time [pix_buffer_write] sends the output of the rotation as a
"passthrough" on its outlet? And also you are saying it would be normal and
expected for the output of [pix_buffer_write] to be different than what
[pix_buffer_write] is actually storing? If that isn't the case, example 1
and example 3 should produce the same results.

Perhaps I need some rules about how Gem is different than Pd in terms of
dataflow. So far it seems to me that a rendering chain in Gem shows
conections but does not reveal the order in which these connections are
processed i.e. if 3 objects are all connected to each other in a rendering
chain in Gem i.e.

[Gemhead]
|
[object 1]
|
[object 2]
|
[object 3]

we cannot conclude that the output of [object 1] feeds the input of [object
2] and the output of [object 2] feeds the input of [object 3]. We only know
that the data will be processed by objects 1, 2 and 3 but not in what order
they will be processed.

Further perhaps we cannot conclude that the output of an object is actually
the result of the object having processed the data. Demonstrating this: in
my patch example, [pix_buffer_write] outputs different data than it stores,
or examples 1 and 3 would be the same.

And this leads me to a more general statement of my original question: how
can I determine the order in which objects are processed in Gem?

And my specific example which started this thread: how would one apply a
rotation to an image, then apply [pix_rtx] to the rotated image?

-John


>
>
> 2009/3/24 John Harrison <john.harrison at alum.mit.edu>:
>  > Attached is a small example patch of how I just don't get
> Gem...still...
> >
> > [pix_rtx] has a steady wave that normally flows from left to right.
> >
> > I would have thought that the attached patch shows me rotating the image
> > first, then applying [pix_rtx]. So it would stand to reason in my mind I
> > would see a rotated image with [pix_rtx] flowing from left to right.
> >
> > But that isn't the result I see. The patch has [pix_rtx] flowing from
> right
> > to left now. It is as if [pix_rtx] is applied *before* the rotation
> instead
> > of *after* as I would have expected.
> >
> > Grasping at straws, I have tried [pix_separator] between just about every
> > object, but that makes no difference.
> >
> > What am I misunderstanding that makes the behavior of the patch make
> sense?
> > And...how would I get [pix_rtx] to flow from left to right on a mirrored
> > image?
> >
> > -John
> >
> > P.S. Are questions like this better on the Gem-dev list? That's a
> developer
> > list but at the same time I feel a bit awkward putting too many Gem
> > questions on a Pd list
> >
> >
>  > #N canvas 962 171 305 227 10;
> > #X obj 29 -58 gemhead;
> > #X obj 29 -35 pix_video;
> > #X obj 29 44 pix_texture;
> > #X obj 28 72 rectangle 4 3;
> > #X obj 159 9 gemwin;
> > #X msg 136 -34 create \, 1;
> > #X msg 214 -33 destroy;
> > #X obj 135 -57 loadbang;
> > #X obj 29 17 pix_rtx;
> > #X obj 29 -10 rotateXYZ 0 180 0;
> > #X connect 0 0 1 0;
> > #X connect 1 0 9 0;
> > #X connect 2 0 3 0;
> > #X connect 5 0 4 0;
> > #X connect 6 0 4 0;
> > #X connect 7 0 5 0;
> > #X connect 8 0 2 0;
> > #X connect 9 0 8 0;
> >
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090325/f82a09aa/attachment.htm>