OF to Syphon to Max
Hi there,
beside making music with capacitive mushrooms driving karplus strong within a pi's RNBO export, I'm now focusing on a new feature for my late developments for a new a+v live performance.
Using OpenFrameworks for generative & procedural visuals is a strong way I already work with for many projects. I'm talking about agents drawing on the screens, different rules & contexts etc.
I built a small but efficient system for having different context, using OSC from Max for control purposes etc. Very cool.
Textures traveling through Syphon. Solid... on the paper side.
Actually, I cannot have a constant fps on Jitter's side and the classic (but sometimes too much theoretical) moving element from left to right is PERFECTLY drawn on OF side BUT on Jitter side... some subtle but visible stutter effect. I mean... the circle travel sometimes jitter a very bit at slow speed.
Most noticeable at 1080p than 720p and yes that could be performances problem too (M1 Max 64Gb) but OF side is really showing a ... PERFECT movement. Even with A LOT of circles etc.
Max 9.0.7, M1 Max 64Gb
Overdrive + Scheduler in Audio Interrupt enabled (tried also to disable them)
I'm wring through FBO on OF. Very conventional.
The subtle stutter probably comes from Max/Jitter pulling Syphon textures asynchronously within its UI scheduler, while openFrameworks pushes frames at its own perfectly stable GPU clock.
This pull-based texture retrieval lacks frame-perfect sync, causing micro jitter even at high FPS.
It is a structural limitation of Syphon client-side rendering in Max, not a performance bottleneck.
My question: should I expect a better quality rendering with any stutter or that way, if some tested it, always involves this kind of things ?
Shouldn't I instanciate syphon things on Max side on a different way ?
Let me know if you want variants for your forum posts or internal notes.
Any ideas, words, discussions around it would be very cool :-)
One thing I notice is that you are saying OF is sending at 60 FPS, but it looks like your jit.world is outputting 120 FPS. You may want to set @displaylink 0 so that you can lock your FPS at some rate that is not display refresh driven, which may help eliminate stutters. If you have displaylink enabled then the fps attribute is ignored.
other than that, the standard answers about eliminating stutters in jitter apply, which is to ensure no GUI elements are updating in your patch. If you need GUI elements you can run 2 instances of Max and send control data from the GUI instance to the render instance over OSC.
Hi Rob, thanks a lot
Displaylink. May I add that I never HAD use it until today ?!
Actually, it has stabilized the fps and let me set it statically yes
It HAS improved the texture pulling and no UI update in that patch, yes.
In the final patch, I'll "abstract" that syphon pulling in a proper different patch as the patch controlling it, even if NO gui update stricto sensu, may contain message $1, etc. That's not easy in my setup to abstract this but I'll need it I understand.
Rob,
that two different patches have always been touchy for me (us) as it is driven by the underlying way patches are running on the computer, which we don't know completely of course.
In my case,
I have a visuals system which manages EVERYTHING from audio analysis + midi parsing.
I take care of this : https://cycling74.com/forums/gl-rendering-context-switching-gl-objects-and-cpugpu-saving so nothing is rendering or drawing for nothing, actually.
I also take care of upgrading UI elements but indeed, I may forgot a couple and actually that patch doesn't only render because for before rendering I need to alter OB3D elements, jit.movie textures etc.
When you wrote "If you need GUI elements you can run 2 instances of Max", doesn't it mean GUI elements upgrading ? if I "protect" them by gating, if I disable midi + audio in subpatcher, etc can it be rendered in one instance as well ??
The syphon part that pulls textures from OF could be a proper instance, actually, yes. But I'm stuck as the whole visuals system should then get the texture from it, so no improvement compared to the visuals system that would pull it directly from OF.
As all my other textures sources, if I don't need it, I disable it. I can also do that with my syphon thing. In any of my a+v live performance context where I need it, I enable it and pull what I have to pull from OF, when it is no more required, I stop pulling. The OF part is very well manage so, by itself, it is stop drawing anything (even not pushing to syphon anymore) if not required.
The only question that could summarize what I have in mind here: what should I put in another instance here ? Indeed, my rendering context contains control (no GUI... but events+audio) as I need that. If you mean the jitworld only, which I don't think you mean that, ok... but even, I'd need to get my rendering from my node in my context ... to that jit.world... across instances... wow.
Any word, even few, about that would give me more food for thoughts :-)