lists@lowfrequency.or

I'm very curious about getting smooth animations (using OpenGL), 

especially for non-realtime (frame-by-frame, using bline to drive 

presets) recording. I created this patch as part of a system for doing 

that - starting a save, stopping a save, all without losing frames, and 

recording frame-by-frame without skipping any. Can someone look this 

over and tell me if this is an efficient method for doing this? My 

biggest issue was working out a way of banging the jit.gl.render 

object, reading that video to a matrix, saving it via jit.qt.record, 

and then banging again when done, without causing a stack overflow.

There are comments in the attached patch that explain the process. 

Basically, I use onebang as a gate after the main qmetro (which drives 

the patch) to prevent the state of the jit.gl.* objects from changing 

before the frame finishes rendering. But it's possible that I'm 

missing something, using a qmetro on one end and jit.qball on the 

other. It does seem to work very well, though.

I'm very curious about getting smooth animations (using OpenGL), 
especially for non-realtime (frame-by-frame, using bline to drive 
presets) recording.  I created this patch as part of a system for doing 
that - starting a save, stopping a save, all without losing frames, and 
recording frame-by-frame without skipping any.  Can someone look this 
over and tell me if this is an efficient method for doing this?  My 
biggest issue was working out a way of banging the jit.gl.render 
object, reading that video to a matrix, saving it via jit.qt.record, 
and then banging again when done, without causing a stack overflow.

There are comments in the attached patch that explain the process.  
Basically, I use onebang as a gate after the main qmetro (which drives 
the patch) to prevent the state of the jit.gl.* objects from changing 
before the frame finishes rendering.  But it's possible that I'm 
missing something, using a qmetro on one end and jit.qball on the 
other.  It does seem to work very well, though.

smooth-renderingwriting-to-disk

Here's how I've been doing it. Generally speaking, I give all of my

gl objects the @automatic 0 attribute. Going into the jit.gl.render

object, I have a t b b erase. The middle bang is for rendering. 

After the scene is drawn, I send a bang to the jit.gl.sketch object

and send it the command "glreadpixels mat_name 0 0 width height". I'm

a bit lazy, so I send it on every bang, but this is redundant. Just

afterward, I send a bang to the matrix which holds the rendered pixels

and pipe that into a jit.qt.record. The outlet of the record has a

delay on it to avoid feedback problems and a gate. THe gate

allows/disallows a new frame to be rendered.

If possible, I'd like to remove the delay and replace it with

something else that will immediately send a bang but still avoid

Here's how I've been doing it.  Generally speaking, I give all of my
gl objects the @automatic 0 attribute.  Going into the jit.gl.render
object, I have a t b b erase.  The middle bang is for rendering. 
After the scene is drawn, I send a bang to the jit.gl.sketch object
and send it the command "glreadpixels mat_name 0 0 width height".  I'm
a bit lazy, so I send it on every bang, but this is redundant.  Just
afterward, I send a bang to the matrix which holds the rendered pixels
and pipe that into a jit.qt.record.  The outlet of the record has a
delay on it to avoid feedback problems and a gate.  THe gate
allows/disallows a new frame to be rendered.
If possible, I'd like to remove the delay and replace it with
something else that will immediately send a bang but still avoid
scheduler overflow.

Any strategies for dealing with jit.gl.handle when recording 'non' 

ie: in your patch, running it in realtime and manipulating 

jit.gl.handle results in a camera rotation. turning off the qmetro 

and banging manually results in unsteady rotations (jit.handle is 

still rotating behind the scenes, the render context isnt being 

any ideas on how to deal with this, as I use a jit.gl.handle 

abstraction in my patches to control many gl objects, and non rt 

Any strategies for dealing with jit.gl.handle when recording 'non'  
realtime?

ie: in your patch, running it in realtime and manipulating  
jit.gl.handle results in a camera rotation. turning off the qmetro  
and banging manually results in unsteady rotations (jit.handle is  
still rotating behind the scenes, the render context isnt being  
updated).

any ideas on how to deal with this, as I use a jit.gl.handle  
abstraction in my patches to control many gl objects, and non rt  
rendering would be fun to play with.

Good question. I'm not entirely sure it's possible if @auto_rotate is

enabled. I tend to calculate my own rotations, so I've not had to

Good question.  I'm not entirely sure it's possible if @auto_rotate is
enabled.  I tend to calculate my own rotations, so I've not had  to
deal with this.

I usually use a javascript to deal with this, that rotates objects a 

Although, it would be cool if jit.gl.handle had an @automatic attribute 

I usually use a javascript to deal with this, that rotates objects a 
certain amount each frame.
Although, it would be cool if jit.gl.handle had an @automatic attribute 
also!

That's what I was doing before, but the stack overflows and jerkiness 

were a real problem. Thus, using the onebang object to gate the main 

qmetro, so you can both use the patch for realtime feedback, and then 

set the qmetro speed to something very low and render to disk as fast 

That's what I was doing before, but the stack overflows and jerkiness 
were a real problem.  Thus, using the onebang object to gate the main 
qmetro, so you can both use the patch for realtime feedback, and then 
set the qmetro speed to something very low and render to disk as fast 
as possible.

you sir, know how to read a girls mind. exactly what I was hinting at.

Some good ideas in this thread. I spent a lot of time this winter 

working on a recording patch. The interest here is prompting me to 

clean it up for sharing earlier than I was planning to, like in a 

Some good ideas in this thread.  I spent a lot of time this winter  
working on a recording patch.  The interest here is prompting me to  
clean it up for sharing earlier than I was planning to, like in a  
couple of days, so please stay tuned.

this text seems to be incomplete.
can you please post this again.

smooth rendering/writing to disk?