Hello to all you GDTF-Heads, for the last 1,5 years I've been writing a little application to control GDTF fixtures, called GlowDTF (because it makes GDTFs glow). I like to call it a "technical demo" with some notable features being Partially view and validate GDTF Fixture Types (XSD validation and basically everything around Channel Functions) Visualize Mode Master Dependencies Patch Fixtures Control individual Channel Functions with sliders reflecting the DMX and ModeMaster structure Art-Net Output Check it out here: https://github.com/cueglow/glowdtf The application consists of a server written in Kotlin, running on the Java Virtual Machine (JVM). The frontend runs in a web browser and is written in React and TypeScript. While programming this has been a great learning experience, progress has been slow. I've realized that instead trying to build a full application, my time would be better spent building a basic GDTF library. And unfortunately I think the JVM is the wrong platform to do that, because only a small amount of people want to work on that platform. Therefore I decided not to develop GlowDTF further, but provide the code in case someone finds it useful. I would however like to start a discussion on how to build an Open Source GDTF ecosystem. Personally, I will be looking into Michael Hugi's gdtf_parser when I find the time. It is an already mostly functional GDTF parser written in Rust. Rust as programming language makes a lot of sense in my opinion. Open Source Lighting Software seems divided between C++, JS, C# and Python. If a single library is to be used across all these languages (since I don't think we'll be able to support multiple Open Source GDTF libraries until MA or Vectorworks step in), it needs to be written in a language that doesn't need a runtime and can be used to write C APIs. While C and C++ fulfill these criteria, Rust has been picking up as an alternative because it makes it much harder to shoot yourself in the foot, as is often easy in C/C++. This makes it such a good experience that it has been voted most loved programming language in the StackOverflow developer survey every year since 2016. If we write software in our free time, it might as well be in an enjoyable language like Rust! Combined with the hopefully lower bug count of a Rust library, I think this justifies working around the less mature XML ecosystem in Rust. What do you think? If you have questions or comments about GlowDTF or the Open Source GDTF ecosystem in general, I'm looking forward to your comments!

By the way, I think the Parsing Errors that @ARRI-GDTF has in their files is because the Builder does not accurately validate nested dependencies. Basically, imagine the following: Two ChannelFunction in a Channel Switching between the two ChannelFunctions is achieved by each depending on a different ChannelFunction in another channel. The Builder now can't tell that the two ModeMasters are mutually exclusive due to their respective ModeMasters and complains the two ChannelFunctions at the end of the ModeMaster chain overlap. I've attached a minimum working example. Test@Nested_Dependency_Parsing_Error_Bug@version1.gdtf

Description: When the attached GDTF file is uploaded to the Share, the lower panel is empty. The channel layout is not displayed, there is no possibility to comment or open the file in the builder. Expected Outcome: The lower panel should not be empty, allowing commenting, checking the channel layout and opening the file in the builder. Details: The file passes the currently available XSD and Schematron validations. Environment: Firefox 86.0 on Ubuntu 20.10 Groovy The Browser Console shows errors whenever the faulty file is opened: Path: RefContainer 4 menuObj_gma3.js:1853:49 Path: TopLevelGeometry menuObj_gma3.js:1853:49 found not parsed reference TopLevelGeometry menuObj_gma3.js:1983:41 Path: TopLevelGeometry 11 menuObj_gma3.js:1853:49 Path: OverwriteBreakTopLevelGeometry 3 menuObj_gma3.js:1853:49 Uncaught TypeError: can't convert undefined to object resolveAddress https://gdtf-share.com/js/gma3/menuObj_gma3.js:1993 addDMXFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1854 addDMXFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1768 addDMXFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1874 parse https://gdtf-share.com/js/gma3/menuObj_gma3.js:1691 createModesAndFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1464 selectFile https://gdtf-share.com/js/gma3/menuObj_gma3.js:930 onclick https://gdtf-share.com/gdtf.php?page=home&manu=Test&fix=Channel Layout Test Fixture&rev=11810:1 menuObj_gma3.js:1993:53 resolveAddress https://gdtf-share.com/js/gma3/menuObj_gma3.js:1993 addDMXFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1854 addDMXFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1768 addDMXFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1874 parse https://gdtf-share.com/js/gma3/menuObj_gma3.js:1691 createModesAndFootprint https://gdtf-share.com/js/gma3/menuObj_gma3.js:1464 selectFile https://gdtf-share.com/js/gma3/menuObj_gma3.js:930 onclick https://gdtf-share.com/gdtf.php?page=home&manu=Test&fix=Channel Layout Test Fixture&rev=11810:1 Test@Channel_Layout_Test_Fixture@v2_crazy_overwrite_break_shit.gdtf

Seems fixed. I was able to download the GDTF and upload to the Share again.

Yes, I have the same issue. When pressing upload, the popup to choose Manufacturer, Name and Revision appears. Once pressing OK in that dialog, the spinner with "Processing" appears for a second or so and then disappears. Once it is disappeared, nothing happens: No file is downloaded and nothing is uploaded to the Share.