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.
Any hints?
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).
Yes you’re right it’s not working … seems as it was to easy …
I had a new look on the patch and counld find a solution
hmmmm i’am thinking perhaps it’s possible to work with to queues chanching there textures … one is the memmory queue on is to build the new order and feeds the memmory ?!?
It’ll take a bit time for me to look through it
and fully understand its way of functioning;
concerning the vast possibilities on working with spreads
I’m a real newbie.
Tonfilm,
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 ?
