hi all ...
i've got a problem with a simple gem patch that's related to the way gem handles pixes ...
my patch looks like this:
pix_video | t a a | | | |do a | do b
but the |do a| part changes the state of the picture ... this for the dataflow: although i should have the same message to work on (coming from pix_video), i'm working on two different messages ...
for my taste, this doesn't follow the dataflow language of pd any more, since two messages that should have the same behaviour, behave different...
any idea, how to solve that?
cheers ... tim
Perhaps I don't understand what you are trying to do, but why not use the GEM specific [separator] [pix_separator] objects?
Also, splitting a GEM chain without these objects will mean that each chain operates on the same set of data, so the pix_ data and GL states won't be unique to each.
On Dec 17, 2004, at 11:16 AM, Tim Blechmann wrote:
hi all ...
i've got a problem with a simple gem patch that's related to the way gem handles pixes ...
my patch looks like this:
pix_video | t a a | | | |do a | do b
but the |do a| part changes the state of the picture ... this for the dataflow: although i should have the same message to work on (coming from pix_video), i'm working on two different messages ...
for my taste, this doesn't follow the dataflow language of pd any more, since two messages that should have the same behaviour, behave different...
any idea, how to solve that?
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support.
On Fri, 17 Dec 2004, chris clepper wrote:
Perhaps I don't understand what you are trying to do, but why not use the GEM specific [separator] [pix_separator] objects?
As Homer (not the Iliad one) would say: D'OH!
(wrt my previous message)
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Perhaps I don't understand what you are trying to do, but why not use the GEM specific [separator] [pix_separator] objects?
i had hoped that i miss something that obvious ...
Also, splitting a GEM chain without these objects will mean that each chain operates on the same set of data, so the pix_ data and GL states won't be unique to each.
can't this be done without the semerator objects? i mean if you pass the gemlist to certain objects, it should be able to use some kind of reference counting to figure out, if the same message has been splitted up ...
thanks ... tim
On Dec 17, 2004, at 1:16 PM, Tim Blechmann wrote:
can't this be done without the semerator objects? i mean if you pass the gemlist to certain objects, it should be able to use some kind of reference counting to figure out, if the same message has been splitted up ...
The [separator] object resets both gemstate data and also OpenGL states on the GPU. This has to be done to enable each branch to manipulate the 3D view and textures independently. [pix_separator] makes a copy of the pixel buffer in order to achieve the same thing. GEM pix_ chains only use a single buffer and overwrite the data with a few exceptions that use internal buffers for specialized processing.
On Fri, 17 Dec 2004, Tim Blechmann wrote:
but the |do a| part changes the state of the picture ... this for the dataflow: although i should have the same message to work on (coming from pix_video), i'm working on two different messages ...
This is because your message refers to some resource lying outside of the message. Examples of this in plain Pd would be pointers (as with [traverse], [append], ...) but also things like [table] and using symbols to refer to those tables.
There's this thing called "value semantics" that means that all values referred to by any message get copied along (or at least appear to be so while being optimised under the hood).
What I'm trying to say is that it's not against the Pd model to work using non-value semantics, just that it's less usual than having value semantics.
Besides, value semantics are easier to deal with, on average; but if you ever tried using a purely functional language like Haskell (that enforces value semantics everywhere) then you know that it isn't always the easiest way to think about things.
Now, I don't know why GEM works that way, but it is feasible to handle images otherwise. Both PDP and GridFlow have value semantics for images. OTOH, Mapod, yet another video plugin, uses non-value semantics, even requiring explicit deallocation (!). I recall that Mapod has a way to "fork" a buffer, a sort of deep-copy replacement to [t a a]. I'm trying to recall whether there's something similar to that in Gem; I mean, apart from [separator]...
Maybe you can hack something together using [pix_buffer], but surely someone else has a better solution than that.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju