I don’t see a clock on the SQ, am I missing it? If it does not have one, adding one to the upper right hand corner of the screen would be great.
See here: https://community.allen-heath.com/forums/topic/date-time
Basically, SQ doesn’t have the necessary realtime clock hardware, so this isn’t possible.
I was surprised when I learned the SQ can’t tell time. It would be very helpful if the SQ could time stamp save dates of Scenes and USB recordings.
+1
In my opinion itd definetly a bug, that all records have the same time stamp. With the “no rename” option of the SQ its horriblbe to find the rigth files on USB. Even with multitrack records.
So please give an option to edit the filmename of the recorded audio or bring the rigth timestamp on it. Maybe with the name of the show or scene in front of file number
+1000 for any form of clock functionality.
I am aware the SQ has no RTC hardware, but that in no way means this can’t be implemented.
It shouldn’t be too complicated to develop a software process loop which sleep()s for one second then increments an integer containing a standard UNIX timestamp. There would quite likely be some drift without a stable clock source but it would be much, much better than nothing. Adding an NTP client would be icing on the cake for all the SQs which are already network connected, but having to adjust the clock once per startup isn’t really a deal-breaker in many SQ applications. It would be a very small price to pay to be able to see the time in the corner of the touchscreen, and users who don’t care can opt not to use it; I‘d imagine it wouldn’t appear until set.
Failing that - take a cue from my old Korg synthesiser (which also doesn’t have any real-time clock). In the utilities menu you can enter in a date/time that’s only used for saving files; it even remembers the last entry for next time. While it’s a pain to update it every time I save, it certainly helps with organising files later.
I would very much welcome the Allen & Heath staff giving this feature some further thought.
+1
This is the number one issue I have with the SQ5, not knowing when I made the recordings. How about something like this: a menu selection on the recording screen that indicates [SetDate]. A window pops up with a keypad and a six digit entry screen that allows you to enter YY MM DD and this date is used as the date for all of the files that are created until the unit is turned off. The screen then should indicate the date. This could be for stereo, multitrack and show files. The time is not that important to me. That could also be a 5th option on the main screen.
+1
A clock or ability to rename recordings would be great. It’s difficult to go through a list of recordings to find what I’m looking for.
A clear explanation of the possibilities for this to be a retro fit with a software update or is it a hardware issue that needs to be included in future models. Perhaps Keith could provide us realistic info pursuant to this very important issue.
Hugh
It’s a hardware issue. There is nothing that operates while the board is turned off to keep track of what time and date it is.
There will never be a clock in an SQ.
D.
So glad to have so many professional software developers in the forum who know what will/can/could never come…
How exactly would software know what time it is without a clock?
Sometimes I wish for a clock on the SQ, but mostly another nearby device is my reference for showtime.
But just to clarify about the “impossibility”, there is no need for an RTC on-board if the SQ (or any device for that matter) is network connected (and the clock - that only runs when powered on - is implemented in the firmware). Of course, there is no time on the SQ until the remote NTP time server is queried (because there is no on-board RTC to hold that time)…
Of course, maybe SQ4You or SQMixPad could give the time to the SQ?
my 2c to keep the idea alive… 
By setting the time manually or as Said before by NTP Server. The Idea with SQ Pad is new for me but on Connect also SQ Pad could Set the time. Great Idea, thank you.
Best Regards.
Great idea of using NTP or some other method of looking up the time. I’m not sure what’s involved in that, but it could surely be done with software and not require hardware changes. Even though there would be cases where the lookup would not be possible (e.g. not connected to the network, network devices do not provide enough info to determine the time), for those of us connected to a compatible network (probably many of us), this would be a great addition.
Well even using a NTP to sync the time, the console will need a RTC circuit in hardware to count on from the time recieved from the net.
Without the RTC it would have to constantly ask the ntp for the time, using cpu/fcpga ressources for that instead of processing the audio.
A way to set the date for the show, to keep easier track of recordings should be doable though.
It seems like that would still be helpful for one-time events like saving shows, saving recordings, etc., even if it’s not feasible to have a running clock on-screen.
Hi guys,
really – I kindly ask to inform you first – then talk tech.
Every CPU and Operating System counts its milliseconds since start of itself. If you have a time information for only once – does not matter if from NTP or manula set or SQ Mix Pad – the System can then just count the time onwards from there until next shutdown.
RTC only means, that time will be preserved if unit is powered down.
Best Regards,
Tobias
Agreed, it’s quite a loss not having a RTC:
- While it sounds pathetic, it’s really helpful having a clock permanently visible at mix position.
- It would make identification of recordings infinitely easier.
- It would make identification of old scenes infinitely easier.
It’s almost like A&H made a decision to make their folder/file structure obtuse, and then decided to avoid a RTC to make life even harder for the user.
Obviously, to be implemented properly would require hardware that’s not in the SQ design. It would also need a battery, which would have a finite life, but that’s an issue I’d happily accept that I needed to handle.
Such a shame - especially when it appeared to be no problem for Behringer to do in the “cheap & crappy” X32. For a company that got so much right, it’s surprising to see the little (but killing) things it got wrong.