Closed LxLasso closed 1 year ago
GDTF and MVR are designed to work toegheter.
Sure, but this doesn't prevent a situation from arising where there is no GDTF file for a fixture.
VectorWorks currently deal with this by generating a fake fixture, and so do we at Capture. In lack of any guidlines of what such a fake fixture should contain we have pretty much done exactly as VectorWorks has. This feels pretty shaky. I think it would be wise to have a paragraph in the MVR spec that outlines how such a situation should be handled, possibly also specifying what a minimal fake GDTF should look like (that might go in the GDTF spec though I guess).
We had discussed the what information we need for the "fake" GDTF. The result we had is that what we have don't with Vectorworks. We export:
For sure fake Dimmer, Pan/Tilt etc could be generated, but I think this would lead to more confusion as it helps.
The idea behind this was, that you have all the information to just will out the DMX data when you only have the DMX Sheet.
For sure fake Dimmer, Pan/Tilt etc could be generated, but I think this would lead to more confusion as it helps.
I agree.
I would say the largest issue at the moment is indicating the correct DMX mode. A single channel fake DMX mode makes every fixture like this look like a practical/conventional. The name of the mode could be correct though. We considered generating additional fake channels to match the channel count of the intended mode, but that brings us back to the point above.
I think the dummy GDTF approach has proven to be the solution.
It is unavoidable that there will be cases where no GDTF definition is available for a fixture. Rather than forcing a fake GDTF definition it would be better have a structured way of describing the fixture.