Respected GEM wizards of the Internet,

Over the last few weeks I have been trying to build upon the [scopeXYZ~] object, to make its lines fade out over time (similar to analogue oscilloscopes - I assume this will be less tiring to the eye to look at than the flickering oscilloscope images I get otherwise). Because I still have little experience with GEM, my luck in the matter so far has been minimal, which is why I would like to ask for your advice or input.

My intended approach comprises adding a weakened version of the previous image output to the current scopeXYZ output at each rendering cycle, and then to render this as a texture on a square (the fastest method of display, as I understand).
So far I have managed to render the oscilloscope output to a [gemframebuffer], and to acces this pix through a different gemhead and rendering it to a square.
From here on, I would like to mix this pix with the previous output (which has been scaled down in strength) before rendering it to the square, to add a logarithmic decay to the strength of the oscilloscope traces. However, I cannot seem to succeed in this final but crucial step.

I have looked into a decent amount of documentation regarding GEM, including manuals, tutorials, examples and forum discussions, but I am a little bewildered by the functioning of GEM, and I feel stuck on this matter.
Would anybody be able and willing to give me some suggestions as to how I might approach this? Should I be working with buffers at all, for example (they seem to slow the patch down a lot), or are there other ways of mixing a current oscilloscope output with a darkened version of the previously presented output?

I have attached my current patch to this post. Any help or advice would be much appreciated.

Joska

analog_osc.pd

i am too tired right now to offer a patch, but maybe [pix_delay] will help you

Thank you for that suggestion.
It sounds like it does what I need it to, and I had not tried this object yet. However, it does not seem to have any effect in my patch.

I used [pix_snap] to output the current framebuffer as a pix, to do pix operations on it and texture map it to a square. I could apply pix operations such as [pix_gain] on this pix, but [pix_delay] did not seem to have any effect on the output, even when I was wildly swinging around the delay value by hand. I think I used the object as I am supposed to, but found the results less than impressive.
The only discussion I found from somebody trying something similar with [pix_delay] ended with the OP not managing to get pix feedback in such a way.

I have just produced an effect similar to what I intended by splitting a pix signal into two using [pix_separator] and connecting these to the left and then the right inlet of [pix_add], after applying a [pix_gain] object before the right inlet. The result looks alright, and I have applied this process iteratively (splitting and adding again) to arrive at a signal that fades out in 4 shades.
However, framerate is already starting to suffer significantly for pix sizes of 512x512 (let alone the higher resolution I hoped for), especially if applied iteratively. As I understand all pix operations are performed on the CPU, rather than on the graphics card. Would there be any way to speed this up, perhaps by involving the graphics card somehow?

I have attached a picture of the working (but slow) method that adds a current frame to the last, along with the patch.
analog_osc_pix_add.pd