This patch demonstrates what looks like a bit of an inconsistency:

pix-invert-huh.pd
gempower.pd

[pix_colorreduce] appears to produce a new copy of the incoming pix data -- the result is rendered but the original data are still available to be used for later pix-texture-ings.

Many other pix_ operations behave similarly, so I assumed (hah!) that this is a general rule.

Then I find that [pix_invert] seems to overwrite the original pix, so that, in an entire rendering chain involving [pix_invert], every pix_texture will use the inverted data (except, here, the colorreduce because it's already split its results off into a separate buffer).

Wait... it gets better... if I switch the order of the left two outlets of [t a a a], so that the order goes 1/ colorreduce, 2/ no modification, 3/ pix_invert, then the pix_invert may apply to the second pix_texture as well as the third (even though pix_invert applies third).

And also, I had thought of using pix_buffer as a set of "registers" to be able to go back to the original data at any point in the rendering chain, but... pix_invert corrupts the pix_buffer data too. I wasn't able to find a solution for this.

I mean, OK, in my demo for class, I'll just have to remove pix_invert and use maybe a hue shift instead. But... this can't be intentional, can it...? What is the rationale?

EDIT: pix_offset poses the same problem as pix_invert.

EDIT: pix_buf doesn't help.

hjh

@ddw_music Best to use [separator] or [pix_separator] or [pix_buf] to isolate parallel render chains.
[trigger] doesn't do it.
David.

Another variant of the same topic:

In this patch, [pix_buffer] does allow the second image to be drawn to be isolated from the pix_invert operation.

But when you turn on pix_invert (using the toggle in the middle), the right-hand image will flash between the normal and inverted colors -- that is, pix_invert operates in place, so each incoming gemlist causes the colors to flip, then flip back, and flip again, and so on.

pix-mods-3.pd

With some effort, I found a workaround. I don't think I can show it to the students though -- 1/ it's too complicated for most of them and 2/ the ones who would understand it have already switched to jitter and would just laugh at it.

pix-mods-3b-two-copies.pd

Oh well, one more for the "Really, GEM?" file.

hjh

@ddw_music I don't know. I have not attempted Ofelia as I have no coding experience since Fortran70 and Cobol.
And I have a very limited idea as to how OpenGL addresses the video card....... but I can muddle through GEM reasonably easily...... all learnt by trial and error.
I still have not really got my head wrapped around the render chain representation in GEM, because I use it very little.
Tools like TouchDesigner are easier for a noob like me and for Video Premiere Pro.
There are more modern tools for almost everything that GEM can do..... and more.
Messages in cords seem to be passing both ways in GEM....... but of course I am just not understanding the operations "behind the scenes".
David.

@whale-av OK, I'll try the separator later. I'm done for tonight.

hjh

@ddw_music nice (hacky) workarround! I did not test, but remember these kind of problems from several projects. I also remember using [(pix_)seperator] a lot. And fixing these things without this hack. This post will also help me find your fix when im desperate in front of some flickering at 4 o'clock in the morning and too dump to avoid this stuff from the beginning.

OK, [pix_buf] does avoid both problems.

I got a little thrown off because the help advises against using it for continually-updating images (maybe that remark is for 15-year-old CPUs, though) and it isn't quite clear from that example how it applies to this case.

Tools like TouchDesigner are easier for a noob like me and for Video Premiere Pro. There are more modern tools for almost everything that GEM can do..... and more.

I hadn't considered TouchDesigner because of the lack of Linux support. (That's also why Max hasn't been my first choice either.)

Also, I had hoped to keep audio and video in the same general paradigm. If I taught SuperCollider for audio and somehow got the students over their resistance to code, then a few months later it would be "OK, now for graphics, here's a totally separate language" -- fairly sure that wouldn't go well. Max/MSP/Jitter are on point for that.

Messages in cords seem to be passing both ways in GEM....... but of course I am just not understanding the operations "behind the scenes."

That sounds like in-place side effects that are not quite controlled. If pix operations are receiving pointers to data buffers, then given operations A, B and C, A and C would both feel the effects of B's modification of the data.

What I found frustrating here is that most pix_ operations seem to make a new version of the pix that is separated from others, but some do not. In fact I had never encountered the in-place behavior before the other day. "Principle of least surprise" would dictate that the effects of related operators should be similar (and if they can't be similar, the difference should be documented).

This might be one of the areas where GEM is outdated. With functional programming styles becoming more popular and more highly developed, the expectation now is that operations should in general be isolated from upstream and parallel operations. GEM may not have begun with this assumption (probably for processor-efficiency reasons).

Anyway, the lesson for me is not to assume locality.

hjh