Sync, rendering and display
Jun 26 2020 | 10:53 am
I struggled to have flashes synchronized with the rendering engine.
Actually, I used this and since years. it does the job well. Theoretically, it shouldn't, from a strict point of view, but it does.
BUT, the problem is the display. In practice, sometimes it goes very well, and sometimes it is not bad but not totally ok.
I got the fact of asynchronous flow of operations: the rendering engine is ok, it sends a flash, very short, and if the display (screen, videoprojector) got the display loop not completely sync or fast or whatever, the flash is not seen properly well.
Touring, you never get the same kinf of display, so it has to be testest, adjusted (?) and checked at each show.
Increasing rates helps.. of course (even if the sync problem is not solved, getting faster pratically decreases it, actually it increases the luck of having things like synced)
My question to you: how would or do you manage this ?
Any ideas or suggestions would be very interesting for me :-)
Take Care,
Julien
- Jun 26 2020 | 2:20 pmJulien, I'm wondering if you really need this "frameQuantize" bang: the quantization is really happening because of the "draw" bang. Wouldn't this version work just as well - or I must be missing something?
- Jun 26 2020 | 5:28 pmfor tight timing of display-synched on/off events, on the order of 1 or a few frames, the only object you should use is counter triggered by your jit.world bang out. any other timing mechanism will drift.If you need variable timing, i would build some mechanism that switches from max-event based timing, to frame-counter timing once the timing interval drops below a certain threshold (e.g. 10ms or whatever feels right to you).
- Jul 15 2020 | 12:12 amHi Julien, for the tightness i use a simple phasor..
and after the bang, i have a Shutter-Dial what controlls a [line] object and the time how long the flash is alive.. this helps to keep the flash alive over some frames..
maybe this helps.. Cheers Markus
