structure index member not returning all a queue's structure contents

strontiumDog's picture

hello i've put a qtz together where midi in takes 0->1 number, multiplies it by 500 - result output is the value input of an integrator - the integrated value output of which goes into the iterations input of an iterator: g.jpg

in my iterator a virtual watcher takes the iterations (iterator variables patch), sample&holds the patch time at that point (adds 0.0000001 to it for case where patch time = 0) and passes it into the value in of a queue. queue size of queue patch is also linked to the number of iterations so the array increases by the requisite number and i get an array of patch times: f.jpg

the output of the queue is the structure input of a structure index member. the index input of the same patch is essentially the index output from the iterator variables patch.

ok, not the easiest thing to describe but check the iterator screen shot for a closer look.

in essence, when i press my midi keyboard, as the value is multiplied massively and then uses an integrator, even a brief tap and the number of iterations goes up massively - but although the index value of the structure index member patch has the same (correct) value, the queue hasn't passed a structure with anywhere near that many members.

is this because the patch time patch is sampled over delta t, and only samples are taken when the patch time is incremented, meanwhile the queue is lengthened (relatively) massively? if this is the case is there a way i can 'fill in the gaps?'

let me know if i can clarify any points. thanks in advance s

PreviewAttachmentSize
f.jpg
f.jpg121.08 KB
g.jpg
g.jpg28.91 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

toneburst's picture
Confusing....

I must admit, I don't fully understand your explanation of what you're trying to do here. Generally, though, I'd say it's not the best idea to put a Queue inside an Iterator. What you've got in this case is an independent Queue for each iteration (remember that everything inside an Iterator is copied). If you want all iterations to make use of the same data, you have to place the Queue outside the Iterator, and feed a structure from the Queue into the Iterator. Then you can use the Iterator Variables' Index number combined with a Structure Index Member patch to pull a value from the correct slot of the shared Queue patch.

Hope this helps.

EDIT: It could also be that the Queue is one of several 'stateful' patches that don't function properly inside an Iterator.

a|x http://machinesdontcare.wordpress.com

cwright's picture
queurythmics

you're right, alex, you really don't want a queue in an iterator -- otherwise, it'll record something on every iteration (multiple items per frame), which probably isn't what you want.

strontiumDog's picture
the need for queues/rainy courtyard

the reason i'm using queues is that each iteration of the object needs to operate in it's own timespace and be completely independent of all other objects placed by the system so the queue is an array of start times, each minussed from the overall patch time to get an 'independent' zero patch start time. the full example qtz is here.

as i don't know any other way of introducing a series of objects into the scene from a moving start point, all of which move from that (different) point to a corresponding moving end point before being disabled, i'm having to use a queue inside an iterator.

i tried taking the queuing structure part out of the iterator but i'm getting unexpected results. i guess for clarity the effect i'm trying to get is like rain. imagine an uncovered square courtyard in the rain at night with no wind, with flood lights shining horizontally across the yard from under the eaves. what you can see is a series of droplets which appear from the level with the flood lights (same y value) but at otherwise random points (x, z) and as there is no wind, the only changing variable is y which decrements as the droplets move towards the ground. i'd like to vary how much rain there is, but i'd like to be working with up to 1000 droplets of rain in the light at once.

particle systems wouldn't work for this so i needed a queue and an iterator to abstract each droplet's start and end point from every other. from looking at the linked qtz am i going in the right direction?

thanks s

ps i know in the qtz the cubes move round the circumference of a circle, but the courtyard idea strips what i need right down.