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.