MOTUnation.com

I noticed my DP 4.6 give me this an error message when the time of recording session exeeds the twelve hours...
If I set up the position of whiper after 12 hours I have the same message:

DP not receive clock sync from audio hardware...

I Use a 896 Hd and a Traveller, and I have the same problem whit both.

Anyone have the same problem or a suggestion?

(My music is not as long... I would want to work in this way when i record for video productions, in which it is demanded to record evermore...)

Thanks, Beppe

just got this problem this weekend on a big shoot. i was freaking out like crazy. it happened in DP 4.12, then i installed 4.6 and still had the same problem. i'm using an 828mkII.
also, at any timecode the freewheel option doesn't help one bit. DP stops recording no matter what. i put the freewheel options as high as i could without going to infinite, started recording, pulled smpte cable and timecode was gone. no freewheeling at all.

i guess we shall have to email motu about this stuff

If you are in record mode for 12 hours, you are not using this or any music creation software morgram effectively. Not to mention being abused by your clients.

DP and other music software can handle several hours of recording easily, but a 12 hour sequence is so unrealistic, I doubt you will get any positive responsesand certainly no solutions. Sort of like saying "damn, it hurts when I poke this stick in my eye."

Don;t poke your eye with a stick and you should be fine.

well, you're not recording the entire time. however, timecode is rolling the whole time and matches the time of day. 12:00:00:00 = noon, 13:00:00:00 = 1:00pm. you could try to record 5 minutes of audio on one track, but if you try to sync it with timecode at say 12:30 in the afternoon, you're screwed. it's a sync and resolve issue.
and it's something that protools can handle and DP can't...i know MOTU will be happy to want to catch up on that.

digging90650 wrote: ...and it's something that protools can handle and DP can't...i know MOTU will be happy to want to catch up on that.

Well, unless something has changed with PT v.7, Pro Tools can't handle anything longer than a 12 hour timeline either. If you're recording on location and using time-of-day timecode, you need to make two sessions. One can handle your first 12 hours and the second can handle the second 12 hours of the day; just make sure your session start time is changed for the second 12 hour period. If you're crossing from midnight to 1:00 AM on a take, your session will probably get confused, although it might free-wheel over the gap.

I don't use timecode often with DP (although I do with Pro Tools), and was unaware of the timeline limitation, but I have seen this problem with Pro Tools and auto-conform software frequently. Sounds like a similiar situation.

wow protools has the same problem...i wasn't aware of that. none of my protools friends said that they had the same prob when i told them of my experience. good to know that it may just be some wierd issue with smpte and the program or hardware.
strange thing i just tested and discovered...DP didn't have a problem recording or syncing after 12:00:00:00 when it was syncing to the powerbook's internal clock. so it looks as if this may be an issue with the firewire hardware or something along those lines.
very interesting...need to do more testing!!!!!

I still say you are not really thinking this out. You can record in segments and adjust the start times so that you are not 12 hours into a sequence, can't you? There is simply no reason in the real world to run a 12 hour sequence. Needless to say, there is also nomediacommercially available to record such a work.

You need not justify WHY you want to do this. It is simply not going to work well. No to mention that it will probably bog down even your processor in calculating where you are in the sequence.

i understand your confusion on the issue. that's a great question and it's even a great solution you've presented. there are a few very good workarounds just like you've stated.
biggest problem is most of the time you don't get to think things through very well while on a shoot. everyone rushes and sound gets the least amount of consideration out of anyone on the set. when you hold up a production even for a minute...you can feel the tension build.
the other major problem is matching everything up in post. things get very confusing very quickly when there are multiple shoot days, multiple cameras, and multiple tapes. matching all of these things up at the end is a huge, confusing task on it's own...add in that little extra amount of confusion and you start getting calls from the producer saying "hey what the hell did you do?" that's the point where you also start getting less referrals and less work and less money...this is bad.
it would be nice if everyone was patient and nice, but that's just not the way the world of entertainment is.

the bigger issue i have with DP or the 828 is the freewheel not doing what it's supposed to do. i can't wait to do some tests on that and see what wierd things happen.

I understand the terror of a shoot, which is why I am not a recordist. But I do post production sound with DP and get the days and days of recordings to sift thru (when the sound guy just gives up they usually hand it off to me and say "finish it.") I cut my teeth recording since about 1970, so I am not intimidated by long code, or even a razor blade I even still have my 2340! Two of them, in fact. But neither has been fired up in many years.

But in pretty much everything I've worked on in the last few years, SMPTE code had little to nothing to do with it. DP makes it so easy to sync stuff!

I just want to chime in and support digging90650.

Wanting to use time-of-day code is entirely normal and it is inexcusable that the software can't handle timecodes greater than 12:00:00:00.

FYI I am a developer of a audio product that tracks timecode, so I know what I am talking about. It sounds like a stupid bug in the firmware to me.

But a possible workaround you might try using is to re-gen the timecode before it hits your 828, subtracting, say, an 8 hour offset. That will allow you to work from 8 in the morning to 8 at night without hitting this limitation.

Using an external timecode box can also help you work around your freewheel issue.

Also, take a look at the MIDI Timepiece for SMPTE. I used one extensively a few years ago and I'm sure I would have noticed if it had either of those problems. (I was using the old serial-port version though).

[quote="digging90650"]...DP didn't have a problem recording or syncing after 12:00:00:00 when it was syncing to the powerbook's internal clock... quote]

On internal sync the timeline is just a ruler so it's not having to calculate where the samples are located with reference to incoming timecode. It's my understanding that all DAW's actually interpret incoming timecode to samples to know where to place the audio on the timeline. So with over 12 hours x 48,000 samples per second, you have 2,073,600,000 possible sample locations to keep track of in a 12 hour session. Sure, it's a computer, but that's a lot of math, and that's before you even get to any playback processing.

Anyway, how about using chunks to split the session into more manageable pieces? Seems you could use a new chunk for each scene set-up and change the start time to current time-of day. It's really easy to change from chunk-to-chunk in a session, and you'd keep your session setup the same. Haven't tried it, but it might be a good work-around. Keep us er, posted!

So with over 12 hours x 48,000 samples per second, you have 2,073,600,000 possible sample locations to keep track of in a 12 hour session. Sure, it's a computer, but that's a lot of math, and that's before you even get to any playback processing.

Wow, you REALLY don't get it.

2,073,600,000 samples is within the range of a signed 32 bit integer. That is probably the FASTEST calculation that can be done on a modern processor.

But DP can work with up to 192K audio (I assume, since some of their
hardware goes that high). That's 16,588,800,000 samples for a 24 hour
period, or about 8,244,400,000 for a 12 hour period.

Both of those numbers overflow an unsigned 32 bit integer so they BOTH would have to be stored in a 64 bit integer. So it's NO DIFFERENT to go to 24 hours than it is to go to 12 hours.

calculations with 64 bit integers are slower... But still lightning fast. So fast that it's just not an issue for anything.

Going through these calcuations, I think I now see why we have this limitation in the 828 MKII.

The 828 MKII can only do 96K audio. Which means that for 12 hours, that is 4,147,200,000 samples. That just barely fits into the range of an unsigned 32 bit integer. So it would be very tempting for the programmers to just say "nobody needs more than 12 hours" and use an unsigned 32 bit integer because it is slightly easier than using a 64 bit integer (especially in an embedded environment, where the compiler may not directly support 64 bit math).

But it really is inexcusable. These are professional products that claim to support SMPTE. SMPTE goes to 24 hours. If you don't go to 24 hours, than you don't support SMPTE. It's that simple.


[/quote][/code]

But it really is inexcusable. These are professional products that claim to support SMPTE. SMPTE goes to 24 hours. If you don't go to 24 hours, than you don't support SMPTE. It's that simple.

If I Sound designed a 2 hour film and locked some of my gear to smpte
WITH Dp, does that mean it supports smpte?
Your points about smpte are certainly well taken, but to say that smpte
is not supported is not completly true is it.
Of course it should go to 24 hours though, no disagreement there.

lnx wrote:I just want to chime in and support digging90650.

Wanting to use time-of-day code is entirely normal and it is inexcusable that the software can't handle timecodes greater than 12:00:00:00.

FYI I am a developer of a audio product that tracks timecode, so I know what I am talking about. It sounds like a stupid bug in the firmware to me.

But a possible workaround you might try using is to re-gen the timecode before it hits your 828, subtracting, say, an 8 hour offset. That will allow you to work from 8 in the morning to 8 at night without hitting this limitation.

Using an external timecode box can also help you work around your freewheel issue.

Also, take a look at the MIDI Timepiece for SMPTE. I used one extensively a few years ago and I'm sure I would have noticed if it had either of those problems. (I was using the old serial-port version though).

ABSOLUTELY!!!!

This is the perfect response to this bug.

BUMP BUMP BUMP!

Wow, you REALLY don't get it.

Well, thanks Inx, I guess I really needed a math lesson as well as a thorough chastising on the capabilities of a modern processor. I feel so much better now.

Just trying to offer some constructive comments on how to fix digging90650's actual problem. I think your suggestion of regenerating timecode with an 8 hour offset shows that you don't understand how production sound works. If you recorded all your takes with an 8 hour offset, how are you going to autoconform your session to the picture editor's EDL? All your timestamps will be wrong. Just syncing dailies to picture would be a major nuisance. I would think you'd probably be fired after the first day. And, what are you going to do when there are picture changes and you have to re-conform?

I don't know the reason why there is a 12 hour limit in Pro Tools (it has been discussed on the DUC ad-nauseum, and Digidesign apparently can't or won't fix it), and I don't know the reason that DP apparently exhibits the same behavior. If you can shed some light on that subject and leave the smoke-and-mirror mathmetics proofs at home, I'd welcome your comments. We try to be respectful and helpful here, even if we may disagree.