CPU/GPU

no. Even if you could, you'd have to upload your results to the GPU, which would slow down the GPU (having to service IO stuff) and the rest of the system (extra bus bandwidth used to ferry more data between GPU and CPU).

Typically, in games at least, low cpu usage means you can throw in fancier stuff like physics, AI, etc. In QC, it means your fan doesn't kick on as loudly I guess.

(Note that Grand Central and OpenCL in SnowLeopard might rebalance this playing field -- trying to hack it in before then is almost certainly guaranteed to be a waste of time and effort).

i'm thinking that as i've got a qtz which timelines for a couple of minutes in what would be a really nice way if i could keep the frame rate about 35+ fps (and not dipping to 25) and if i could use some redundant power just to follow it through with value historian so i could eventually end up with a .mov which looked like it was from blender, that would be enough.

arbirarily, is it possible, and if so how do i do it?

There's no way out of the box to accomplish this.

You'd have to write custom patches to start accomplishing this. (though I'd be impressed if it helped usefully)

I notice that you say that ending up with something that is closer to a .mov from Blender would be enough... you definitely want to check out Quartz Crystal for rendering with anti-aliasing, if it doesn't have to a be a real-time qtz. You can also set the frame rate to whatever you want (I have never bothered going above 60fps, and that is very vivid... but I know it can go much higher), it makes HD size movies if desired, just about every video codec in the book, etc...

... and maybe in Snow Leopard they will run in real time better when you dig them back out? ... or maybe they won't run at all, hard to say :o)

unfortunately, i've gone round the quartz crystal route: all but the bg in my qtz is triggered by the midi in patch and that's not good for quartz crystal, i tried it and sir christoph confirmed the point.

i'm moving onto value historian in the hope i can take the existence of x numbers generated for the gpu and store them so i may be able to get them to mov that way.

really, i need to look again at my qtz the way i've cabled it and look at ways of reducing the number of points in use at the same time.

There is always the movie exporter plugin, but it probably isn't going to give you the quality you are looking for, and you have to put everything inside of a render in image patch most likely... I think it's somewhere in the developer plugin examples.

you're definetly right. however, once the KnM guys had the wonderfull idea to dev. a patch called KnM GL Read Pixels, that actually does what it says: it reads the GL pixels, so you don't have to put everything in a Render in Image patch. Just put this patch connected to the movie exporter at the end of your chain (= the last render #ID), and you' re done. OMG, KnM guys are kewl...

Ah, shame on me for forgetting to mention that. :o) GL Tools rocks.

I knew there was something wrong with that, and why I don't use this patch much... unless I am incorrect, GL read pixels only captures a still. I admit, I have not connected it to the movie exporter to try an export...

Yeah, due to the way it's coded, it only captures one frame per execute -- you can get it to re-execute by dragging it around in the editor (fun QC bug)... otherwise, I guess we'll have to fix that for the next GLTools release (and get depth buffer stuff working...)

That's funny! I noticed that it would redraw if I moved it, sometimes! But I was also usually connecting/disconnecting noodles, and I was trying to figure out what was the rhyme or reason to the redraw... now that you say it is a bug, it makes sense.

I could see it actually being cool to still have the option to take just a snapshot like this if you do update it to be more like the render in image in function.

so to confirm, as i've got a full timeline of stuff which i want to effectively have output as a .mov (so i can use resolume as well/instead of vdmx5) i'll try the movie exporter patch first as i've got about 100 patches so cabling up value historian looks like it might quite a big job.

i'll keep an eye on quartz crystal for when i can record qtz screen output created by live incoming external sources like osc/midi.

cheers s

Don't hold your breath on QuartzCrystal recording OSC/Midi data -- doing so is difficult to do correctly, while ValueHistorian does it without hacks.

Not trying to say you should abandon ship and use VH now, just saying where the roadmap is pointing for the foreseeable future...

ok thanks. i'll be looking at value historian.

s