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