How to overcome stop watch (and intergrator) not working inside an iterator?

jrs's picture

Hi All,

Does Anyone have any thoughts/ideas as to how I can overcome the stop watch patch not working inside an iterator? (oh and an integrator - http://kineme.net/forum/Discussion/DevelopingCompositions/IteratinganInt... )

I've attached an example where I have a small macro representing an "action" - this works fine for a single instance as shown up the top. When I put this macro inside an iterator though it dies due to stop watches (and integrators) not working inside an iterator.

Does anyone have any idea how I could achieve the same functionality inside an iterator?

Cheers in advance - James

PreviewAttachmentSize
ActionTest-List.qtz127.47 KB

jrs's picture
Re: How to overcome stop watch (and intergrator) not working ...

btw - I'm trying to this without JS, but I really can't see a way around it. I'm thinking I can use a queue to store the state from each iteration? I can see how to do this for the integrator but its the stop watch that's getting me - currently my thinking is as follows:

Convert the stop watches to sample and holds and use the patch or system time to track the time between frames. Add these to a queue and then use that queue as state input the next frame.

This approach seems like it should work but its late and I've been stuck on this for a while now so I'm wary of jumping in (I'm pretty sure I'm locked into thinking about it the wrong way) - Initially I tried to do the action macro with a sample and hold but ran into troubles.

P.S - I have read the post IteratinganIntegrator ( http://kineme.net/forum/Discussion/DevelopingCompositions/IteratinganInt... ) and understand that sample & hold, stop watch etc kind of work in an iterator.... just not the way I need or would expect them to work.

P.P.S - Does anyone have any idea at what point the overhead of using a JS patch matches native QC? ie iterators are slow but is JS slower? or if you use more than lets say 10 native patches (I know it depends on the patch - think sample & hold, logic, math, conditionals)

jrs's picture
Re: How to overcome stop watch (and intergrator) not working ...

Ok so I've made a virtual stop watch patch (attached) which almost works the same as the original except for a small time difference which I have no idea as to why its happening - any ideas?

I initially thought this was due to the slight difference in time between patch execution but if i make multiple version of each I don't see this (which makes sense as I'd assumed patch time was locked each frame) - also if you stop and start the macro lots of times this discrepancy grows - weird no?

PreviewAttachmentSize
StopWatch-Manual-Listb.qtz55.94 KB

itsthejayj's picture
Re: How to overcome stop watch (and intergrator) not working ...

just a quick one because i'm chiming whilst on the road, i'll try and knock up a composition later.

But i use patch time and sample and hold when i have this problem. Sample the patch time when you would start the stop watch and take that away from the current patch time, should work

jrs's picture
Re: How to overcome stop watch (and intergrator) not working ...

Hi All - If your like me and don't keep up religiously with the mailing list you may have missed

A thread by memo title "another workflow questions. OOP with QC :)"

find it here - http://lists.apple.com/archives/quartzcomposer-dev/2010/Oct/threads.html...

It has a heap of relevant discussion and also an example by memo comparing iterator to js performance (JS wins)