OS: Windows10,
Touch Vers: 2021.12380
Hey there,
I’ve encountered a strange Bug/Effect that I wanted to share. Unfortunately this is in the midst of a massive job with super NDA energy so I can’t share proper Tox/Toe files but I wanted to flag this and offer a potential solution for whoever may run into a similar issue. I plan on doing a blog post post-mortem at the end of the gig when we go live in September.
Anyway, In short, I effectively have a DMX map driven by video running in an Engine comp, The Tox within the Engine comp takes a video, and maps it to various DMX channels, very standard. I am feeding the source video from the main Touch patch into the Engine comp via a Top-in.
When in Design mode, the Engine comp beautifully translates the DMX Video to the physical fixtures (not actually lights in this scenario). However, once I enter perform mode, there is a noticeable lag in the physical fixtures’ reaction times. As if the source video is lagging. However, the source video is in the primary patch and actually runs smoother in perform mode.
My instinct is that this has to do with the frame buffer time between the touch threads (ie the main patch and the engine comp toe), but I have no idea why it would run fine in Design mode and be choppy in Perform.
Regardless, the Solution I found for this was:
Instead of using a Top-In for the Engine Comp Toe, I utilized a Memory Share In Top (and a paired Mem Share Out Top in the main patch), both set to Global. It immediately removed any latency between the main patch and the Engine Comp Toe in both Design and Perform Mode.
Again, would love to provide source but unable, hope that if anyone else runs into the same problem this may offer a quick fix. Come Fall I aim to have a full breakdown of this colossal patch.
Thanks for the report. We’ve been trying to recreate this - it sounds like you can’t, but if you are able to share tox and toe files to support@derivative.ca (just reference this thread so they end up forwarded to me) that would help a lot - otherwise answers to a couple of questions might help:
What DMX interface are you using?
What are the dimensions of the video that’s input to the Engine COMP, and how many inputs are there on how many Engine COMP instances?
There is one TouchEngine issue we’re currently looking at with textures being recycled too soon under pressure - but that is usually manifest as jitter rather than lag.
The parameters on the Engine COMP may be affecting this - on the Tune page, turn In Buffer Auto to Off, and experiment with a low fixed number of In Buffer Frames. If you have no outputs on the Engine COMP you can set Out Buffer Auto to Off and Out Buffer Frames to 0 - otherwise find a low fixed number which doesn’t drop output in use.
Hey bangoise,
Apologies for the delay here. I’ll try to hack together the exact .toe and .tox files I’m using when I’m next by the media server (~early July), and send them to the Derivative team. Unfortunately, as we’ve discovered, this is an issue that I can’t replicate digitally either. It’s only noticeable in the real-world fixture reaction.
Worth noting (and I apologize for not mentioning more clearly) the DMX translation actually was changed to some custom electronics my team has built. This Touch patch is actually outputting UDP values not direct DMX via artnet or an entec kind of jam. (We started with some DMX interfaces but given our fixtures they just didn’t play too nicely).
Our custom electronics (that do the UDP to DMX translation) are based on some custom PCB cuts and coded in C based libraries, I believe they’re ARM based (will try to confirm). From touch, we’re using a UDP out DAT triggered by a chop execute. (Is that just bad form?)
As for the Engine Comp tune-params, I definitely futzed around with the settings and couldn’t find anything that had any visible change in the problem encountered. Though this may be due to my own ignorance.
To sum: we’re not actually outputting DMX on perform/designer mode, however, the designer mode has no lag in the fixture reaction, while performance mode does (unless there’s a texture memshare), though perhaps this is due to my own misunderstanding of the Tune-Page of the Engine comp or poor practice of UDP communication.
Sorry if this is too labyrinthian and vague, will aim to send some proper files to the dev team as soon as I can.
Thanks!
Thanks for the details. I’ve tried with a CHOP Execute DAT triggering UDP Out (which is a perfectly reasonable thing to do) from a large changing texture input but unfortunately still can’t see any difference in Perform Mode.
Hopefully once you can get us files we’ll be able to narrow this down.