Working together? #2
Replies: 2 comments
-
I'm well aware of your parser 😄 You might remember me from michaelhugi/gdtf_parser#1. I didn't contribute there because you weren't responsive and I wanted to try a different architecture here: I'm aiming for a higher-level API (because I don't deem low-level APIs for GDTF very useful), built on a tree-based parser and a more lenient architecture that even under error conditions provides most of the file info. This is because I've seen so much invalid stuff in the GDTF space and I think throwing your hands up when encountering something strange is just not an option if you want build something actually useful.
As in Firionus/artnet_packer#1 I agree with your approach and overall goal.
Next best thing is to embed MVR in another zipfile and add metadata. But please no more XML…
I think the logic similar to GDTF isn't all that useful, GDTF is really quite horrible in some ways (no thought on validation, possibly invalid references everywhere, unclear semantics, …). And I can get something resembling the GDTF structure with a tree parser already, so I thought, why keep the token parser up to date? Hence I went and tried something new here.
Sure, what would you want help with? Can you open issues for what it is you would want? What do you plan on working on next?
Not necessarily for myself, but I think it's important to think about the wider community, and e.g. a Java library just isn't portable (see https://gdtf-share.com/forum/index.php?/topic/648-i-built-an-open-source-gdtf-controller-glowdtf/) |
Beta Was this translation helpful? Give feedback.
-
Is there any particular reason you're not answering that I can help with? I'd love to have some back-and-forth with you |
Beta Was this translation helpful? Give feedback.
-
Hi
I saw you started a gdtf parser in Rust. I did the same here: https://github.com/michaelhugi/gdtf_parser
My goal is an open source lighting software that can be used in professional environment. I planned to do everything in rust for good real-time performance and easy cross platform compatability.
The project should be split up in small encapsulated rust libraries, so a community can develop and only use the parts of the software that they want. In my oppinion this could bring the industry forward if it gets easier to create a new lighting software if someone has an idea.
Also I'd like to introduce a standard on how show files are stored so they might be compatible across lightning softwares that are written with the libraries. (I have no idea how I would do that and if it's even possible)
My library is quite far. All it should do is to parse a gdtf file into a Rust struct with similar logic than in the gdtf. Would you be interested in working together? You want interfaces to other languages as I understand. In my library I don't have the goal for that, but we could easily make a project that uses the rust library and adds the interfaces. What do you think? What are your goals?
Beta Was this translation helpful? Give feedback.
All reactions