Process COMP - Clock process - Xen structure

With the Process COMP coming out soon, I think it could be a really interesting feature if the main clock/timeline of TouchDesigner actually ran as a process of it’s own, and then the “main process” of your network editor would technically be inside of a Process COMP (whether visible or not) so that any “main process” stall, would not actually stall the main timeline/render ticks of other process comps.

I think it could be conceptually similar to a xen server, where your clock/main application process (but not the actual network editor) would be the dom0, and then your main network editor where you’re working by default would technically be equivalent to a domU, and then if you were to make more Process COMPs for yourself, they would be further domU’s, would could draw time from the clock dom0.

It might sound a bit semantic, but I think it’ll make using the Process COMPs and TouchDesigner in general a bit more intuitive even if it sounds more complex. Because I imagine the default use for most people using the Process COMP is to have timers/clocks from their main process communicating to the secondary process, so most of the time a stall in the main process will probably negatively effect the secondary process regardless, unless they’re pretty unlinked (like the old press-play-at-the-same-time-on-both-audio-and-video style of controlling multiple processes). Whereas if there was some kind of master clock that was in and of itself threaded separately, it could make for more easy to link elements across different threads.

And then if it was extensible somehow where maybe in the clock dom0 you could say take different control inputs like timecode or midi clocks or ableton link or whatever, and you’d know it would always be locked and all domU’s would be slave to it without interfering with each other if something was to stall, that’d be pretty cool.

1 Like

+1 (with a 40% discount so +0.6 since it’s from Elburz :smiling_imp: ). More seriously interesting stuff, following.

Definitely beyond excited for the process comp as well.
I can see the benefit of having things setup that way if using the timeline.

For me my use case (at least at first) would be about offloading the rendering non essential screen visuals that are more to the aid of the user not meant for actual output.

So for example if I were to render a dozen moving light beams for use as visualization I could in theory pass in camera xform info etc, the instancing data, then what comes out would be a render I could overlay back onto the main render stack.

Is the process comp going to be like a container comp? Or base comp? I feel like this will Impact how people use it too.