Add NTP support

[JonathanParticipant]

It’s not a huge deal, but NTP support on the dlive would be handy for logs. And just seeing what time it is. The built-in clock isn’t very accurate and gets off quite a bit in just a matter of months.

[SteffenRParticipant]

I will not connect the desk to the internet in most of the cases, so NTP makes no sense

[Mfk0815Participant]

NTP also works without internet;-) and a common time basis over all devices in the network would be nice. Then both the sound engineer and the guy on the lightning desk knows exactly when to finish the job;-)

[WolfgangParticipant]

don’t you have a watch on your smartphone or on your wrist? 😉

[Mfk0815Participant]

I do not own a wrist mount watch for the last 30 years, there is no need for that for me;-) hmm, afaik is the Base OS for the console unix/linux. So it shouldn‘t be that big deal to use NTP.
BTW. I am relativly new to dLive, so sorry for that question. Is at least a mechanism implemented to synchronize the watch of the stagebox/mixengine with the connected surfaces?

[SteffenRParticipant]

let me clarify some… mostly we will use the system with stageboxes, mixrack and surface, maybe sometimes a laptop
so there is still no ntp server involved
then it makes no sense to have a ntp client in the system

a good idea would be to sync the time of the system against Director instances available in the system…

[Mfk0815Participant]

Hmm Windows can act as NTP Server, MacOS as well, Linux also…
and when the Director Software will be the time master I will suggest to use NTP as a well known, stable sync protocoll instead of reinventing the square wheel.
Just my 2 cents.

[abenessParticipant]

Another vote for NTP. Just because one person doesn’t connect the system to a network doesn’t mean that no one does. iPad control is essential for us, so we do connect our system to a network. Time is front and center on the main screen. Adding an optional NTP client to the system would be a trivial thing, and would eliminate one of those basic things that is best left to software to manage (well, for the last 30 years or so, anyway). You would be free to use it or not.

No, I don’t use my smartphone while mixing a live show, nor have I worn a wristwatch for 25 years, nor do I have a clock nearby when our board is out in our balcony for a musical. 😉

[Mfk0815Participant]

Having a common time basis on all used devices during a show is always a bonus. Even if it is not that important how to implement such feature it is always a good idea to use an existing solution like NTP, which is now standard across all OS platforms, than reinventing the sqare wheel by creating a new mechanism.
So my vote also goes to (X)NTP.

[jfParticipant]

Hello Guys,

Basically, the easiest way to handle all this without much development effort would be to implement a TeamVievwer solution in the Dlive. this to be useful at least in 2 cases.
– Assistance and Maintenance from the internet.
– In local mode, one could easily manage the multirack of a soundgrid or a recorder type REAPPER from the screen of the console!
Personally I would not mind paying a TeamViewer license to have these features!

[dockopenbrookParticipant]

Hey guys,
nice discussion and I can see some good points in NTP as well.

However I would like to have PTP. I think this will become a more and more important and some kind of the next timeclock. Broadcasters already try IP based workflows and their using this protocol to sync the equipment. With PTP you could not only keep the time in sync, the clock in the entire network would be consistent.

By the way: I think Dante is using this protocol or part of this as well…

[DanParticipant]

We use a dual monitor Director PC as our “Monitor Desk”, so being able to time sync to the PC would solve the problem.

[msteelParticipant]

+1

I mean, the open source software licensing information lists QNTP as a component. So there is already an NTP client existing in the firmware. Just implement a way in the UI for us to specify a server.

Of course then you’d also have to have a way to specify time zone, with the possible issue of daylight saving time in some places, etc. So I understand it may not be as simple as just turning it on.

The solution proposed by some of using Director to set the time could work also (but it also has its potential gotcha’s like, if there are two instances of Director then which time wins….

If nothing else, can we have a MIDI command to set the time? The X32 family has an OSC command that sets the time and that has been used to keep that console from drifting.

[DaveParticipant]

The solution proposed by some of using Director to set the time could work also (but it also has its potential gotcha’s like, if there are two instances of Director then which time wins…

You raise a good point. Being able to designate a “master” Director instance would solve the issue. I suspect most of the time there’s only zero or one instances of Director connected, so a “first instance to connect” approach would probably work, although I’d think there should be a way to switch which one sets the time. Or maybe throw up a warning if they disagree by more than a half second or so?

[WeatherNo108Participant]

If developers decided to implement a clock it would better be accurate. Many systems are installed ones with access to an NTP server. Setting a clock manually, keeping up with daylight savings and dealing with drifts are quite outdated in 2023. Making the NTP sync available with an hourly update frequency is not a big deal really.

Fields should be:
– NTP server IP address
– UTC offset
– DST enable / disable
– DST start: Month / week of month / day of week / hour
– DST end: Month / week of month / day of week / hour

Thank you!

[Author]

Posts