Hello from someone who has worked on the same problem 👋

[Firionus]

Hey @Verschwiegener,

I saw you started following me and wanted to say hi. I've been working on GDTF a bit in my free time over the last 2 years. In that time I brought the XML Schema file up to v1.1 and developed a little demo application (https://github.com/cueglow/glowdtf). Besides a React UI and a Kotlin server it contains a working, though not fully featured, GDTF library in Kotlin. It should be fully usable from Java, as far as I understand the compatibility between the two languages.

If you want to move the corresponding code into a library, I'm happy to help if I find the time. Just open an issue there and I'll see what I can do.

But personally I've given up on open-source GDTF development for now. All the driving software companies behind that format have no interest in open source. Most things happen behind closed doors and software is kept proprietary. I've gotta say though, Petr Vanek from Robe has been great and always seemed open to the idea of open source. All of this wouldn't be an issue if a small group of hobbyists could organize on GitHub around a single GDTF project but that hasn't happened so far. People seem to look into it on their own and stop quickly as they realize what a huge task a proper GDTF library is. The format has been designed with little thought given to compatibility or simplicity, so that even the official, closed source library has unsupported features compared to the DIN spec or allows the strangest of behaviors (e.g. https://gdtf-share.com/forum/index.php?/topic/478-parsing-errors-after-correcting-channel-function-defaults/#comment-1881 or https://gdtf-share.com/forum/index.php?/topic/599-reference-fixture/#comment-1817).

I've also grown quite skeptical whether JVM is the right platform for a GDTF library. It can't be used easily from the most popular languages for lighting development (C++, JavaScript, Python). I think the community should organize around a C++ (personally, I've been trying to avoid that language) or Rust (amazing language but very young, XML tooling is mediocre) library. Read some more of my thoughts at https://gdtf-share.com/forum/index.php?/topic/648-i-built-an-open-source-gdtf-controller-glowdtf/.

I've quickly started looking into the Rust parser at https://github.com/michaelhugi/gdtf_parser but my engagement in that has stalled since neither I nor the original author seem to find any time and motivation for development.

All of this might sound a little bleak but I'm sure that open source GDTF can work. It only needs a critical mass of developers that join forces to become viable. I'm open to talk if you want to😃, otherwise have fun coding and rock on😎

[Verschwiegener]

Hey @Firionus,

Yeah i saw that you have a Rust project about gdtf. As far as i know the Kotlin code should just work fine.
Yeah the Open-Source side of gdtf is not so active are rich of projects, that is why i decided to publish this slam side project. I haven't looked so much in the behavior or execution of the spec in other programs, i just needed a file to store a fixture in for a project of mine and then i saw gdtf on the MA-Lighting Website and decided to look into it and made this very quick proof of concept.
If the JVM is the right platform for something like this, i doubt it but the project i need this library for is running on the JVM and because i didnt had enough motivation to implement it in C and the make it accessible via JNI or something.
It is really sad that there isnt much of a community around gdtf because the idea of a standard to share fixtures between different programs is a good one. I would love to exchange a bit of knowledge or to cooperate on an open-source gdtf implementation
Best regards

[Firionus]

I would love to exchange a bit of knowledge or to cooperate on an open-source gdtf implementation

If you have any questions, feel free to ask.

In terms of collaboration, I'd be open to that if we can find an intriguing concept. I personally don't have that right now. JVM has great XML tooling but limited applicability for the wider programming community. Same goes for any JS or Python project. C/C++ also has good XML tooling and is easily integrated into all kinds of projects but I really don't like touching such an unsafe language. And Rust would be great, except for the subpar XML tools. Specifically, there is no way to generate parsers, validators and serializers from XSD in Rust right now.
And I just don't have the time or will to erect a huge part of XML infrastructure for Rust. This is just a hobby, after all.

If you want to save fixture information in a project of yours, I just can't recommend GDTF right now if you don't have a lot of extra time on your hands. Maybe the Open Fixture Library would be an interesting thing for you. You wouldn't be the first to piggyback on its JSON format, for example you could just use the Dragonframe format (read details here OpenLightingProject/open-fixture-library#1511 or OpenLightingProject/open-fixture-library#1471).

If you can share more about the project you’re working on, I'd love to hear it. 😃

[Verschwiegener]

I am currently working on a Lighting Control software which is written in Java, hence the need for a java implementation of gdtf. Why on the JVM, it runs very easy on other platforms, and i didn't want to write it in c or c++. On the topic of XML tooling for Rust, i think i overheard somewhere that there is a xsd shema library but I could be wrong about that. I plan to also add the OpenFixtureLibrary format, because my software is aimed to be used at my school and there we haven't got the time or expertise on the side of the teachers, to create Fixtures. So i would like to import as many fixture types as possible, and gdtf all in all isnt that bad, appart from the fact that I dont even need nearly all of the Values gdtf provides.