[PD] still struggling with basic understanding of Gem dataflow
John Harrison
john.harrison at alum.mit.edu
Thu Mar 26 13:05:40 CET 2009
This is fantastic! Thank you Marius for taking the time to build these
patches.
rtx_sch2.pd exactly answered my question and shows beautifully how to
perform a set of OpenGL operations on the content of some pix_ data
before applying more pix_ operations. The patch makes total sense.
I'm still playing with it to make sure I fully grasp all parts. I really
appreciate this help.
-John
marius schebella wrote:
> hi,
> I think your pix_coordinate idea was not that bad (see attached patch).
> but that is probably not what you want??
> on the other hand, using pdp_rotate and converting twice is really
> eating up a lot of cpu. pdp is a different world again and the bridge
> between pdp and gem is buggy (your patch crashed my computer for
> example).
> but again, as chris said. there is a difference between rotating the
> content of the pix data and rotating the geometry that this data is
> mapped to.
> so the second patch shows, what I think you really want. rotate an
> image and then feed this into your pix_rtx.
> marius.
>
> John Harrison wrote:
>> This is extremely helpful. I'm starting to "get" it.
>> Comments/questions inline.
>>
>> chris clepper wrote:
>>> There are two types of objects in GEM: pix and OpenGL.
>>> Pix objects do work in the top to bottom manner like Pd DSP objects.
>> would [pix_coordinate] be an exception to this? I've been playing
>> with it and it seems to behave the way you have described OpenGL
>> objects and not GEM objects. I read the help patch about
>> [pix_texture] reassigning the coordinate values, but that still
>> didn't explain all the behavior I was seeing.
>>> The convention in GEM is to put the GL objects after the pix_ ones
>>> showing that once the pix_ processes are done on the CPU it is time
>>> for the GL processes on the GPU to start.
>> I understand you to be saying that the GL processes will always be
>> applied after the pix_ processes. If that is the case, then it sounds
>> like there is no way to have [rotateXYZ] applied before [pix_rtx].
>> Makes sense.
>>
>> For the more general case, is it correct that there is no way in GEM
>> to give an arbitrary rotation of an image as input to a pix_ object
>> since there is no Gem pix_ object with arbitrary rotation function?
>>
>> Figuring that might be the case, I tried to build [pix_rotate] using
>> [pix_coordinate]...and this led me to the question about about
>> [pix_coordinate]
>>
>> Using pdp_rotate, pix_2gem and gem2pdp, I did successfully build a
>> pix_ rotator. On the chance it might be helpful to see, I attached a
>> demo patch which feeds a rotated video stream to [pix_rtx] then
>> rotates the stream back to the way it was. While it more-or-less
>> works it seems a bit scabby. Is there a better way?
>>>
>>>
>>> There are lots of exceptions to Pd rules in GEM and there is really
>>> no way around them. It is kind of like learning English - I before
>>> E except after C, excepting all of those words that ignore the rule.
>> As long as I can make sense of what the rules are, which objects
>> break them, and some rough idea as to why, I'm cool with that.
>>
>> Thank you again for your help. As Hans suggests, I'd like to find a
>> way to help organize, then share this information, whether it be on
>> the wiki or in some other meaningful way.
>>
>> -John
>>
>
More information about the Pd-list
mailing list