I’m workin’ on a live video sampler thingie.
For buffering video data I use the ‘Queue (EX9.Texture)’-Node,
but I’m not really happy with its behavior:
it inserts a new texture at index 0 and shifts all other textures upwards;
A kind of RingBuffer for textures would rather do the thing for me,
because it inserts the Input at the given ring buffer position.
But it doesn’t exist as a prebuilt node…
Fooled around a bit, but I didn’t manage to create something with comparable functions.
So: I need help.
I attached a stripped down version of my current patch.
the index pin of GetSlice is spredable, this means you can form a new spread with 200 slices in a new order by connecting 200 values to the index.
if you insert the indices 0, 1, 2, 3, 4, 5, …, 199 (with I (Spreads) ) you get the original spread like it is stored in the queue. now just change the order of the indices to change the order of your textures.
But I’m afraid it doesn’t work like is says:
the last recorded video frames are always placed
at the end of the texture-buffer/-spread
and not at the actual position.
And because of the queue node my basic problem still isn’t solved:
With a ringbuffer the frames at the actual recording position would be overwritten;
Recording with the queue node I always lose the ‘oldest’ frames
(and that’s what I don’t want).
Am I right with the assumption that my problem
with always losing the oldest frames ( mentioned in an earlier post)
is solved in this patch, cause the node which holds the stored and edited spread of
textures is the spreaded getslice.
If yes, yippie!!!
no, thats not solved, the queue always drops the oldest frame shifts all slices by one and inserts the new one at position 0, ringbuffer inserts the new slice always at the position of the oldest one (without shifting any slice). which frame do you want to overwrite ?