Yes, the very intention of GDTF is that the format itself is open and free to implement and use, the builder is free to use and intentionally it encourages you to upload the file publicly online, as the whole intention of GDTF has been to fix the issue of proprietary vendor lock in formats. It still allows design studios to design custom stuff for clients either via Builder and delete, or via custom software implementations, which are very simple, given the open and also readable nature of the whole specification. We do not do any dark pattern stuff on the server or in transit to keep or look at the files. Once the files are sitting on the server, they are publicly accessible. Hope this helps, Cheers Petr

Hello @walter.lutzu, thank you for the report. I believe this was already addressed, but am not sure if that version has been released yet (this is more for the VW forum), but let me add @klinzey of VectorWorks here in copy (thank you Kevin!), cheers Petr

Hi all, we have released a big update of the GDTF Builder, which includes several months of work on improvements, bugfixes and features. Our main focus has been on enhancing the user experience of the editing workflow and on eliminating bugs. To help to reduce crashes and issues, we have now deployed Sentry.io, application monitoring platform, to help us to reproduce bugs and fix issues faster. This is the reason why we have re-enabled the consent with Terms of use screen, on first signing in. The list of changes is very long and includes more then 100 items, let me describe few of them in more detail: Localization The builder has been translated to Czech, French and Chinese, here are some localized Sign-in screens: Language switching is automatic, based on browser defined preference (which can be changed in browser settings if required), here are examples from Chrome and Firefox browser Settings (these are browser settings, not builder settings): Gobo image preview Images in Wheel Slots now load faster and are displayed with their transparency on a typical checker background, to be able to visually see if they look correct: Geometry drag and drop When using drag/drop, the editor now highlights the selected drop target: DMX values editing Lots of work has been done to improve DMX values editing and care has especially been taken to cover cases, where values are entered-in in 8bit resolution, for channels defined as 16bit. This works really well and allows authors to edit values very quickly. Also, authors have full control and good visual overview of consecutive values and ranges: When editing Mode Dependencies in Channel Functions, DMX values are now displayed in currently selected resolution: Channel Functions now also indicate linked Wheel Slot, Emitter or a Filter. This is great in order to visually confirm linking without having to enter the Additional Properties screen. Channel Function copy/paste Copying channels between DMX Modes has been possible for a while, now we have added the possibility to copy/paste individual Channel Functions. The pasted Channel Function will also remember it's Mode Dependency channel/function and values. This is one of the greatest feature additions of this version and it can dramatically speed up GDTF file authoring. Same as with copy/paste of DMX channels, the Channel Function copy/paste also works between different tabs of the same browser, meaning - you can copy/paste between different fixture files. When changing Manufacturer or device Name, the builder prompts the author to change the UUID, to prevent duplicated IDs in the share: In many places, we have added error and extended validation checking, as well as indications of discovered editing errors - for example incorrect values or missing data. See example of Channel Function error here, where Color1 attribute is selected but Color Wheel is not linked: All errors and their description are now visible on the Summary page: Macro editing We have fixed a critical bug on the Macros page, which could lead to loss of data. So this was a quick overview of some of the most visible features and additions. We hope that this will help to all people working on General Device Type Format files. Please give this improved builder a spin and let us know in comments in case of any issues or further ideas. You already know the address: https://fixturebuilder.gdtf-share.com/ We are currently working on adding the GDTF 1.1, DIN SPEC 15800 features into the GDTF Builder, this will be released later this year.

Dear @Paolo.Prolights, this looks like good work, few changes here and there, mostly nit-picking: - RDM missing, but might not be included - you use "Parent physical" in most places, which is mostly fine, except Wheels, where you should use ChannelSet PhysicalFrom/PhysicalTo values, to indicate whether the these are proportional or step values - the models is slightly bigger then needed (vertex wise) but i would not change it - if i understand it right, the Strobing could all be within one ChannelFunction, with ChannelSets defining the Slow/Medium/Fast DMX + PhysicalFrom/To values. Do note that i did not test in visualizer like MA3 or Vision. I think that you have a good grasp of what and how to do. The virtual tilt is a nice touch. Cheers Petr

Hi @tk11de, on the beginning of this week, we have rolled out a big maintenance update to the builder, which (besides a bunch of good new features) includes several fixes against data loss. Kind Regards Petr

Dear all, it is great to see all the interest in GDTF specification, GDTF Builder and also the GDTF Share. As the Share is a source of data for several different interested parties with different levels of needs and understanding, we have to ensure that the content provided in the Share remains organized and useful. The GDTF Share usage policy is given by Terms of use, available here: https://gdtf-share.com/help/terms_of_use_gdtf_help.htm This short document explains principles used for moderation of the content in the GDTF Share which we will start to be enforcing, to keep the GDTF Share a useful resource. As long as the above stated Terms of use are fulfilled, the main assumption for the GDTF Share moderators is that GDTF Share users have the following possibilities: - everyone can contribute - everyone can modify existing content At the same time, users should ensure, that they do not create confusion by incomplete, missing or confusing data, naming of files (devices), manufacturers (folders) or revisions. There are following types of user content in the GDTF Share, which receive extra moderation in order to keep the GDTF Share organized: - User names - Manufacturer names - Fixture names - Revisions User name User names should not collide with names of manufacturers, in order to not create confusion for other users. User, who's name contains a manufacturer's name, where the user is not representing the manufacturer, might be warned to change their name and/or their name might be changed by moderators. Manufacturer name Manufacturer name should be based on manufacturer's preference, is possible. The Manufacturer name is used as a section/folder in the share and there should typically only be a single section/folder per manufacturer in the GDTF Share. User Tests folder There is a dedicated folder for testing, files not meeting stated criteria will be moved or asked to be moved there. Please use this folder extensively when testing and do clean your creations after testing. We are also planning to clean the User Tests from time to time. Fixture names Ideally, official full fixture name should be used. The GDTF specification provides dedicated fields for Short Name and also for Long Name - a name with special characters. As GDTF file can contain multiple DMX Modes, do not create individual GDTF files for individual modes. Revisions Revision text, especially after the initial release and corrections, should try to explain what changes have been done to the file. If a user is modifying another user's file (creating another revision), the revision text should clearly state what the changes are. Fixture type unique identification Each fixture type's UUID (universally unique identifier) in the GDTF Share must be unique. What is UUID? Each fixture type has a universally unique identifier (UUID), this is typically generated by the GDTF Builder. Different revisions of the same fixture type have the same UUID, but different fixture types must have different UUIDs. Upcoming steps If you are a GDTF files author, we would be happy if you can check if the files you have uploaded meet the above criteria and make changes as needed. If you are a GDTF-Share user, we would appreciate if in cases where you see a file not meeting the above criteria, please contact the author - either through the forum or via the "Comments" under each file, so they have a chance to make the adjustments themselves. If you see that the author does not react, use the "Report this file" with a description of the issue, so we can take care. Thank you for helping us keeping the GDTF Share organized, happy editing, Petr

>I built it initially in grandMA3 v1.1.4.2, and then exported it as gdtf to tweak in the builder.  Thank you for the report. I think @dmuellerwill be interested in this. I will also report to the Builder team.

Yes, fix has been deployed to the server.

Hi @Ryan Kanarek, sorry about the issue. This is because you started from https://www.gdtf-share.com rather then the non www version https://gdtf-share.com . What also happens nowadays is that browsers like to hide the www, so you do not notice. You might have to clear your browser history, because Chrome will keep sticking the www there all the time now. I have reported this, so it can be looked at. Happy editing! ? cheers Petr

Hi @hantoo, sounds great. Is the result available somewhere or is this internal only? I do not think such gdtf file exists or makes much sense, but there is the XSD: https://gitlab.com/petrvanek/gdtf-libraries/-/blob/master/gdtf.xsd Also, you can see most frequently used attributes in the attached report. You can try our (Robe) files and report if anything seems odd, but as they are assembled by the GDTF Builder, they should be all semantically good. Hope this helps Petr a.html

Dear all, here is a great news to share: DIN Spec validates GDTF as an open standard for the entertainment industry worldwide. You can read official PRs on links below: https://www.malighting.com/news/article/major-step-1023/ https://www.robe.cz/news/vectorworks-ma-lighting-and-robe-announce-din-spec-15800-recognition-for-gdtf/ https://www.vectorworks.net/news/press-releases/vectorworks-inc-ma-lighting-and-robe-lighting-announce-din-spec-15800-recognition-for-gdtf- https://blog.vectorworks.net/gdtf-becomes-entertainment-standard-with-din-spec-15800 The DIN SPEC 15800 is here for pre-ordering: https://www.beuth.de/en/technical-rule/din-spec-15800/324748671 Besides all the work on DIN certification, version 1.1 brings some good improvements, here is list of changes: Added connectors collect to the physical description. Added media server attributes. Edited existing media server attributes. Added geometry types MediaServerLayer, MediaServerCamera, MediaServerMaster, Display Added detailed definition how a gobo image is interpreted. Added more detailed definition of Geometry Type "Beam" Changed value type of Channel Function XML attribute "Name" Added XML property "CanHaveChildren" to fixture type node. Added LegHeight to the properties collect Added description about the origin of a fixture Added XML attribute "InitialFunction" to DMX Channel, Moved Default from DMX Channel to Channel Function Updated XML attribute "Color" of Emitter, Filter and Wheel Slot Updated XML attribute "LuminousFlux" of Geometry type Beam Note: The default meshes for Base, Conventional and Scanner were updated. The origin of the meshes is now the mounting plate. We have been implementing changes of 1.1 into the GDTF Builder, it is a work in progress, once done, we will announce it's release. Kind regards Petr

Hi @tk11de, i am very sorry for the data loss. I know exactly what this feels like, and it is a terrible experience. I have raised a priority of this in our tracker. For the most time, the builder is very, very stable, but the Macro tab has something wrong, which causes even the local session to be corrupted. Please make incremental saves in the meanwhile, before fix is deployed. Kind regards Petr

@Paolo.Prolightsthank you for the report and sorry about the issue, i have reported it to developers. Hopefully we can catch the bug. It is the Macro tab which can cause it sometimes, so make sure to always save before going there. If you find a way to replicate this issue easily, let me know, for me this does not happen every time (i replicated this only once). Thank you Petr

FYI, CCT was working in Vision last time i tried. cheers P.

Btw here is the GDTF Share in numbers as of this morning. gdtf_share_report_May_7_2020.html

Thanks @mgeasey@clearallvisualsllc.comand others for the GDTF conversation on LD at Large Podcast. Good conversation, questions and answers. Here is the episode: https://plsn.com/podcasts/gdtf-or-gtfo-podcast/ Below are some of my notes and comments, mostly from the Robe side, feel free to ask for more clarification. - Matt kicks the discussion off by explaining that GDTF is not only a DMX profile but a container with data which a console, planning tool or a visualizer can use for their internal use cases. - Discussions about Media Servers, "standard vs custom" mapping/profile, the bottom line is: besides "standard profiles", Media Server can generate GDTF on the fly, even for a "non standard mapping", the GDTF advantage is that now it can be implemented by the software only once in a open, standard format → GDTF, rather then having to implement each manufacturer's library type/style. Plus, there are media server specific features in GDTF 1.1. - Discussions about attributes and naming: - will attributes grow out of proportion while still allowing custom ones? The development group tries to be flexible and at the same time good gatekeepers of attributes. For a simple explanation, Attributes, for the most time, describe real-world behavior, which is then implemented by visualizers. This can help a lot when choosing/searching for a correct attribute. - can channels be named by the user? Yes, GDTF provides possibility of naming channels/channel functions via the Pretty (this is used in a global context on MA3). The first ChannelFunction of a channel would also be considered when looking for a channel name, so it's Name and OriginalAttribute values should be used, by convention. - where do we request new attributes? Requests for attributes can be submitted via forum. - where do we request new attributes/features? Either via forum or developers can join our technical meeting. People do actually join, on occasions or regularly. We do see representatives of ETC, Chamsys and others in the bi-weekly Zoom call. - Is detail about shortcut of movement of an element defined - Yes, this is supported via dedicated attributes. - Can random strobe be 100% emulated? At this point not to the extend to 100% replicate exact behavior (algorithm) which often is not available, but randomness is supported. - Are weight, power draw of a device supported by GDTF? Yes, these parameters are part of the soon to be published 1.1 version. - What about clamps weight? Clamp/adapter/accessories can be an extra GDTF file. Also, GDTFs could be linked to each other. The planning software then can use there values to calculate total weight. - Is iris open/close at 0/1 or 1/0? We define the real world behavior in GDTF. User then can modify the behavior of the console in the console. - Who "signs off" a GDTF file? Ideally, a fixture manufacturer is the one who makes the file. Having responsibility for one file (GDTF) is, while still quite complex, possible. Cheers Petr

Thank you, issue reported.

@Paolo.Prolightsyes, we have seen the same. After some testing and seeing the 25.4 multiplier, it became clear that this is mm to imperial conversion issue. Setting Skepchup to mm did not help. Simply re-converting in other tool (meshlab) did fix the problem.

At this point, i do not think anybody else besides Robe has manufacturer's label, from what i can see. Nice to see Arri and Ayerton now have these too, great! Per my stats, the entire library is some ~850MB (with some possible duplicates in my data, i will take care of those in the future).

Thank you. Yes, this request is now already being tracked.

Hi @Hanz_Brech, the intensity in beam and in corresponding IES should be the same. IES gives you much more precision and information → this being details how the measurements have been taken and also about the field of the beam. But then, it depends on how much precision is needed in your application. More precision can also also more calculating power... cheers P.

Hello, for "color temp" you can use attribute CTO and define from/to color temperature. This is the Attribute: Controls the fixture's "Correct to orange" wheel or mixing system. CTO For your filters, if i understand correctly, the best is to create a Wheel (in the wheel tab), add Slots and assign them colors. Then, link these wheel slots to your Colors in ColorWheel or better color ColorMacro attribute's ChannelSets, in DMX. Hope this helps Petr

@szapocan you please elaborate further on your use-case please? Thank you Petr

Hello @Hanz_Brech, thank you for your interest. The provided spectral data, provided in GDTF right now, are about intensity, color and color spectrum. IES files are about light/intensity distribution. What you do with the data and how you apply is completely up to you. So feel free to grab the provided files and cross compare or apply in any other way. Kind regards Petr

Hello @szapo, at this point, this function is not available but we are discussing it's future return. Cheers Petr cc: @dmueller