RDMNet (GDTF & PSN)

Hi,

after another six months I wanted to find out more about the current state of affairs in RDMNet.

Is it likely that RDMNet will soon be implemented in the main ETC products (gateways, Eos family)? An early implementation would be really desirable.

I would also be interested in what the status looks like in the case of GDTF and whether there are plans to implement PSN.

Such protocols are becoming more and more important in our industry than they already are and unfortunately, in my eyes, ETC is now a bit behind in these points, as one concentrates more on other competencies and thus neglects the important basis of the system a little.

Of course you can help yourself by integrating third-party solutions in the system to cope with tasks, but that is actually not the "sense and purpose of the exercise" ...

Please do not get me wrong, I see what has been achieved in all this time and I am very grateful for it, but, in my opinion, important topics should not be too neglected.

Parents
  • I don't know anything official, but I think you can take something from the fact that ETC currently has one of the most complete implementations of RDMnet available here: https://github.com/ETCLabs/RDMnet. The RDMnet standard was only ratified about a year ago, and I'm interested which other products you are using that support RDMnet and which this is causing you issues with?

    As far as GDTF goes, I'm intrigued what the value you think this gives you. Eos has an extensive fixture library already, as does Hog. The GDTF share site currently only has about 300 fixtures available, and I expect you'll find every single one of those is already in the Eos and Hog libraries.

    If you're interested in PSN, you should check out the OTP https://otprotocol.org which is an ESTA ANSI ratified tracking protocol. Augment3d only released about 6 months ago, and prior to that there was little practical use for tracking in Eos. I'm sure ETC has exciting plans coming.

  • GDTF is more then just a fixturelibrary. We have a fantastic color picker in EOS, but if the lights are not calibrated against this, then unfortunately this is just a... color picker.

    GDTF should, if I understand it, also contain data even for the colors that the lamp can produce and this should then be able to be used in the color picker so that the lamp's output matches what we see on the screen. Biggest question, is this something that could be implemented in EOS color picker easily or is the years of years working with the color picker hard to implement on so It takes years before we see it in consoles by ETC? Pandemic or not, softwareupdates could be done outside the office. ;)

    If the manufacturers of new lamps work with GDTF, then with each new fixture you will have calibrated colors in the system together with a correct fixture setup and no bad fast-loading library that you have to redo to make it to work when the fxtures is new and not implemented in the large fixture library.

    If manufacture make a GDTF-file when they produce new fixtures an upload it to the GDTF-library you can at a demo download it and start testing the fixture whitout asking ETC for a fixturefile or making one of your own... more  intresting... RDMnet... let the fixture keep the file into the fixture and send the GDTF-.file via RDMnet to the console. Just plug in the new fixture on network and consoles get the right fixture setup from the light, patch it and you are up and running whitout hunting the right library. :)

Reply
  • GDTF is more then just a fixturelibrary. We have a fantastic color picker in EOS, but if the lights are not calibrated against this, then unfortunately this is just a... color picker.

    GDTF should, if I understand it, also contain data even for the colors that the lamp can produce and this should then be able to be used in the color picker so that the lamp's output matches what we see on the screen. Biggest question, is this something that could be implemented in EOS color picker easily or is the years of years working with the color picker hard to implement on so It takes years before we see it in consoles by ETC? Pandemic or not, softwareupdates could be done outside the office. ;)

    If the manufacturers of new lamps work with GDTF, then with each new fixture you will have calibrated colors in the system together with a correct fixture setup and no bad fast-loading library that you have to redo to make it to work when the fxtures is new and not implemented in the large fixture library.

    If manufacture make a GDTF-file when they produce new fixtures an upload it to the GDTF-library you can at a demo download it and start testing the fixture whitout asking ETC for a fixturefile or making one of your own... more  intresting... RDMnet... let the fixture keep the file into the fixture and send the GDTF-.file via RDMnet to the console. Just plug in the new fixture on network and consoles get the right fixture setup from the light, patch it and you are up and running whitout hunting the right library. :)

Children
  • The presence of GDTF doesn't actually impact calibration, it just provides an open method of defining calibration. Someone still has to do the calibration and then provide that data in the GDTF format. There's no reason why manufacturers can't already do that, and provide the data in a text format which could then be added into the Eos library, but they don't.

    All you need to do is go and take a look at the pdfs most fixture manufacturers provide for their fixtures to realise the information is severely lacking. They don't always even explain correctly how the DMX profile actually functions.

    The issue is that GDTF doesn't solve any of this, it is just a data format which make it easier to read/write the data. What we actually need is for manufacturers of fixtures to start taking responsibility for providing accurate full information about their fixtures.

Related