Nice!

As I explained earlier, SMPTE/MTC is a software level control option and does not effect the clock of the ADC. It probably makes no sense to you because you got a bum steer about how this all works from the start and you're having a hard time reconciling it... which is what you have to do, as many people do.

That's pretty funny....."bum steer". :D
That sure is a great answer and explanation you put up! :facepalm:

So I guess even when various, respected DAW applications, make CLEAR references in their manuals saying that the DAW's clock gets "varispeed" in order to stay in sync when it's set to chase incoming SMPTE/MTC from less than perfect/always fluctuating analog tape sources...

....they also got a "bum steer"...?

I guess the developers who wrote the code for their DAWs don't understand how their apps are really working. :rolleyes:
 
That's pretty funny....."bum steer". :D
That sure is a great answer and explanation you put up! :facepalm:

So I guess even when various, respected DAW applications, make CLEAR references in their manuals saying that the DAW's clock gets "varispeed" in order to stay in sync when it's set to chase incoming SMPTE/MTC from less than perfect/always fluctuating analog tape sources...

....they also got a "bum steer"...?

I guess the developers who wrote the code for their DAWs don't understand how their apps are really working. :rolleyes:

Funny you should ask. Lets take the manual for the Echo Layla 24 for example. The original manual seemed to imply something about MTC effecting the converter clock, but it was not clear exactly what clock they were talking about. In 2001 the Echo support forums lit up with comments and questions because that section of the manual was misleading. Consequently, in later versions of the manual the explanation in that section was omitted.

No, you really can't depend on manuals either. They aren't written by design engineers anymore than marketing brochures are. That's why there's a demand for aftermarket manuals. The factory manuals are often incomplete or confusing. If manuals were written how they should be in the fist place forums like this wouldn't be so full of questions, and maybe we wouldn't need forums at all.

Here's one of the differences between trained engineers from my day and amateur recordists of today. A learned engineer knows even when a manual has errors and can identify them because the claims defy reason and known design parameters... what is possible and what is not. So instead of being thrown off on a wild goose chase because of a typo, we recognize it as a typo. That's probably the real test of whether someone knows what they're doing or not.

Would be fun though to start a thread about typos in product manuals. I can think of a couple dozen really funny ones right off the top of my head.

I recommend people look at things like the MIDI Spec or even the design patent for a given device if they really want to understand how things work. Browsing other web forums and looking for some consensus is no way to do research or arrive at a definitive conclusion. What we have here in music forum land is the children running the classroom. The majority are seldom right. The one or two people who have really been there and done that are right.

And if you put your hands in the pockets of the person in front of you, you too can be a bum steer! (It's like riding a horse... nothing to it) :D
 
Beck...if you want to assume that it's manual "errors"....that's your choice.

The same kind of stuff is found in in my Samplitude manual, in the Cubase manual, I beleive based on what sweetbeats said earleir, and even the Reaper manual I was looking at yesterday alludes to the clock being affected by the SMPTE/MTC...and I'm I could find more DAW manuals that cover that subject the same way.

I don't think they are all just printing errors.
 
Guys, I think you are arguing about diffrent things.
The word "clock" was/is being used somewhat loosely (in manuals or wherever the word "clock" was/is being used. :D )
So, please, figure it out, will'Ya? :)

"clock" this, "clock" that., .... heh heh :drunk:

>>>
Real time Digital system: a hard oscillator and bunch of soft calculators (bunch of organized triggers and switches, that is ;) )

As such "system" gets damn complex, many "things" in it can be and are being referred as "clock".

take it easy,

:guitar:
********

p.s.
Give me the Master Oscillator and I'll control the world. Uhhhhh... Huh Huh Hu Huh ....
 
Well...there may be something getting lost in translation as to which clocks anyone is refering to...

....but the only point I've been making is that when slaving the DAW to an external analog device, like a tape deck...the SMPTE/MTC off the analog device will never be as steady as the DAW (I think everyone agrees with that)....
...so for the DAW to keep pace to the SMPTE/MTC tape fluctuations AND also maintain digital audio integrity...it has to internally resample on the fly (which is going to be a clock-driven event) and then spit out a sync-adjusted track at the desired project clock rate (44.1/48/88.2/etc).

The DAW manuals clearly describe this and confirm this.
Beck seems to think the manuals are all wrong.... ?

Other than that....we're both calm and taking it easy. :)
 
..there may be something getting lost in translation as to which clocks anyone is refering to...
I'd say something had gotten lost. :)
... when slaving the DAW to an external analog device, like a tape deck...the SMPTE/MTC off the analog device will never be as steady as the DAW...
I'd guess, mathematically it can be just as steady as "The Matrix" itself, but practically - just as good as it gets ;)

.....so for the DAW to keep pace to the SMPTE/MTC tape fluctuations AND also maintain digital audio integrity...it has to internally resample on the fly (which is going to be a clock-driven event) and then spit out a sync-adjusted track at the desired project clock rate (44.1/48/88.2/etc).
Geez louise :D , heh heh, speaking of CLOCK "being used somewhat loosely".
"clock-driven event" - any event in "The Matrix". No other kind of events in it. :drunk:
uhhhhhhhh,
To make life a bit easier I would think of "keeping pace" as a type of "non-destructive" real time effect, and forget about technicalities :) It's a software calculator: monitor / calculate(compare) / adjust / monitor. That calculator can be "written" well or poorly, it can be a good calculator but hardware may not handle it well, or it can be all just OK ...etc...

....The DAW manuals clearly describe this and confirm this
Nop. The DAW manuals don't not tell you a thing about how they work, they tell you bunch of things so you coud use them, it's a user manual (or is it not?) :p
Sonar manual , for example, explaining how "full chase lock works" talks about cars on highway and telling thing like "Sonar learns" "Sonar knows" ... :D

....Beck seems to think the manuals are all wrong.... ?
Huh Huh! :D
ManUALS?
Man-Universal Ammunition Loading Systems?



....we're both calm and taking it easy
Yeah! keep it that way :) Cheers :drunk::drunk:
 
The funny stuff was funny...:D...but this is not really a word game issue.

The DAW must resample on-the-fly when it is set to chase incoming tape SMPTE/MTC.
To do that...the clocking of the audio must change minutely up/down to match any SMPTE/MTC tape fluctuations.

That's as basic as it gets...and we don't even have to agree on how each DAW does that, or what "clock" really refers to...it's just the way a DAW has to work to make the sync sample-accurate in chase mode.
 
Refer to the attachment below for what my Cubase Studio 4 manual states specific to synchronization and how it handles different types of devices and protocols, and then proceed.




I'll be interested to read what, if anything, Tim provides in response. I'm not sure if all of what is stated in the above 2-page excerpt agrees with what Tim has been saying and vice-versa, but I hope it does.

The thing that jumped out to me is how Steinberg decided to handle the integrity of the synchronized system components, juxtaposed with the audio, and that is presented on the second page. They set the priority on the audio in a sense and basically, if I'm reading it correctly, the system components remain locked but the audio freewheels. I think it is safe to assume that, generally speaking, the audio sync issues will come out in the wash. In other words, over the course of a reel of tape, the sync between the analog audio and the digital audio will shift this way and that (secondary to the innate fluctuations of the mechanical transport and the digital audio "freewheeling"), but because the system remains in sync (the timecode reference coming off tape as master and the digital clock reference of the DAW chasing), there shouldn't be overall drift from start to finish between the analog and digital audio. The digital clock reference will be able to stay in tight sync with the analog transport (depending on the quality/make/model of the transport), and depending on HOW timecode was striped to the tape (ideally in some fashion that is referenced to the digital clock during striping, which I believe Tim spoke of earlier), things should be suitably consistent between from start to finish, and any momentary fluctuations resulting from the mechanical transport's normal anomalies will be give and take throughout and we should end up satisfactorily spot-on at any given point in the timeline even though the *audio* isn't "locked". Its pseudo-locked because (if we did it right), the timecode reference striped to the tape was generated from a device referenced to the same clock reference as the digital workstation at the time of striping, AND during recording/reproducing.

Don't know if I have this right, and Tim I'd love you to pick it apart if I don't (if you can stomach having to continue corresponding with us "children" :rolleyes:) just so I can thoroughly understand.

The invitation to "pick it apart" is sincere and genuine and expressed with respect, Tim. The bit about "children" is a bit of a poke...no, its just a plain poke. Tim you've made this kind of statement in the past, and I (correctly or incorrectly) sense frustration and sometimes I have to wonder why you continue to hang out with the "children" if it is that much of a consternation. You've been a tremendous resource here, and other venues I'm sure, but the "I'm blessing you little people with my presence" tone, which is how it comes across to me, is a poor representation of the kind of person of you that *does* provide a great deal of resourceful and helpful information. I just think its unfortunate.

Anyway, if I've got it reasonably right with how Cubase operates as a slave to a mechanical transport, it would work quite well with the exception of certain material. For example, if this system arrangement had been used during mixdown of a combination analog and digital tracks on something like Steve Reich's Different Trains with Pat Metheny, I think there may be audible problems...phase distortion because of some of the tracks' rapid and repetitious layered parts. So that is one situation I can think of where the mechanical transport as master could pose a problem. The easy solution in that case would be to set the digital "transport" (or rather the digital transport's clock reference) as master. BUT...there would have to be some pretty weird circumstances, or rather poor planning on the part of engineering or production, to cause the project to be at mixdown with a hybrid of digital and analog tracks. Realistically this wouldn't happen and naturally ISN'T how it happened. I'm just citing an example where IF that was the case, ATR as master could be bad if the system configuration and behavior was like it is (in my present understanding) with Cubase 4.

It would be interesting for me to scope and compare the output of a tone on my MRL test tape from my BR-20T when it is locked to its internal reference vs under control of the MicroLynx. I should be able to see differences in frequency and amplitude (secondary to speed fluctuations) and more importantly artifacts of cogging if present.
 

Attachments

  • Cubase Studio4 manual excerpt 2008_4_2 .pdf
    38 KB · Views: 5
Last edited:
...because (if we did it right), the timecode reference striped to the tape was generated from a device referenced to the same clock reference as the digital workstation at the time of striping, AND during recording/reproducing.

This is key.

With both the DAW and tape deck referenced to one source, could be the synchronizer's clock, and syncronizer may also be referenced to some form of "house sync" for its "clock"....then yes, set the DAW to chase/lock, and all will rock-n-roll, but stay in sync, and the DAW will spit out a fixed-clock audio track from that.

To rewind this thread and what was key to the depth of this debate...was in how the OP was doing it...and the implication was that the only thing the DAW needed was SMPTE/MTC source...that otherwise, there was no need for a sync refernce source, just the SMPTE time source, that there was no resampling, no reclocking going on, and yet that was still perfect sync with no drift at *sample-accruate level* (not talking about practical drift that is acceptable to the ear).

PS....your attachment link doesn't work.

If I get a chance tonight or maybe tomorrow night....I will scan/copy the section from my Samplitude DAW manual, which is pretty clear on the whole resampling thing when the DAW is chasing the tape deck.
 
Cubase Studio4 manual excerpt 2008 said:
The fact that Cubase’s playback is synchronized to the
timecode does not affect the playback of the digital audio.
It still relies on the perfectly stable, built-in clock in the audio
hardware.
As might be expected, problems will appear when the perfectly
stable digital audio gets related to the slightly varying
speed of a system synchronized to timecode.
The playback timing of each event will not be in total accordance
with the tape or the MIDI playback, since the
playback speed of the audio is determined by the digital
audio hardware’s built-in clock....

Short version of the above:
The fact that Cubase’s playback is synchronized does not mean that digital audio is being synchronized.

verdict: Cubase Studio4 is not a good Audioslave.

******
miroslav said:
this is not really a word game issue....
Yeah, I know, it's not.
On the other hand it's b-board, and so words is all we got, another words - every and each word counts.
Back to the "issue": when discussing technical issues, if you are not careful with words pretty soon you get "GAME OVER!" :p.

...take it easy, guys :D :drunk:
 
verdict: Cubase Studio4 is not a good Audioslave.

Well, that's not really the point I was trying to make...I would actually say it is a GREAT audio slave AS LONG AS THE TIMECODE STRIPED ON THE ATR WAS GENERATED BY A DEVICE REFERENCED TO THE DAW CLOCK REFERENCE. That will minimize or even completely mitigate drift, and with the digital audio immune to the minor fluctuations as the system proceeds through the timeline it will remain pure while the overall system stays in relative consistent sync since the atr timecode was generated by a DAW-clock-referenced generator.
 
....when discussing technical issues, if you are not careful with words pretty soon you get "GAME OVER!" :p

Yeah....that can happen, but my point was that often when these debates run aground and get stuck (neither side of the argument is seeing the other side)....then people will sometimes segue off with silly side arguments about ever shrinking points...and/or the very fine meaning of "words"....when in reality, both sides know what the other side means, they just don't want to accept it or agree with it...so little side debates start to spin off and you loose sight of the key point of the initial argument....
...and that was starting to happen here, which is why I wanted to take it back to the initial point relative to what the OP was doing with sync.



...AS LONG AS THE TIMECODE STRIPED ON THE ATR WAS GENERATED BY A DEVICE REFERENCED TO THE DAW CLOCK REFERENCE.

Yes!

This was what I learned when I added my MicroLynx, and then also the video black-burst as the master sync reference.
It's clearly described in the ML manual, how to achieve that near 100% perfect sync, with minimal impact on the tape deck W&F, and in some cases, an improved W&F with the deck's capstan under full control of the ML.

I know you haven't gone the video gen black-burst route with your ML rig...but adding a small SIGMA video-gen box is less than $50. I picked up a used one for $20...but as I mentioned once before, I then added the Aardvark Aardsync with an on-board BB generator...so the Sigma is a backup at this point.

As I outlined before, my sync rig is like this:
Aardsync w/video gen --- the video output goes to the MicroLynx, which is then set to ExtVid for sync ref.
The Aardsync video gen also drives it's WC, so then I take the WC output from the Aardsync and feed it to an Aardvark clock DA, that way I can send WC to my 3 Layla24 boxes, and also a fourth WC line to the MicroLynx ACG (in case I ever need to use the ACG).
Then from the DAW/Layla #1, I feed MTC back to the MicroLynx.
The Otari MX-80 is tied to the ML, with two-way SMPTE connection, and the SMPTE stripe is done as per the ML manual, using the black-burst as reference sync, and the deck in "wild", free-run mode, only during the striping, then after that the deck is put back on Ext sync with the capstan under full control by the ML.
Once I get the triple "L L L" on the ML keyboard display (within a couple of seconds of tape spin-up)....everything is locked and stable down to sub-frame level, and since the DAW is master, the digital audio is sample-accurate on every pass.
 
Guys, I think you are arguing about diffrent things.
The word "clock" was/is being used somewhat loosely (in manuals or wherever the word "clock" was/is being used. :D )
So, please, figure it out, will'Ya? :)

"clock" this, "clock" that., .... heh heh :drunk:

>>>
Real time Digital system: a hard oscillator and bunch of soft calculators (bunch of organized triggers and switches, that is ;) )

As such "system" gets damn complex, many "things" in it can be and are being referred as "clock".

My point exactly earlier in the thread... and I actually do think it is very much a "Word game" issue in as much as people are interpreting things (words) and defining things differently. People are confusing a standard time code, which is clock-on-the-wall based, with word clock and other clocks. SMPTE/EBU and its MIDI MTC counterpart are clock-on-the-wall based. That is, hours, minutes, seconds, with the addition of frames and subframes. The "clock" in a DAC is running at thousands of cycles per second, but has no self-awareness of were it is in time. The computer which the audio interface is in has its own clock for processing, but it doesn't know where it is in time either. Software and/or firmware gives a DAW (and the computer it runs on) reference to how we mark time in hours, minutes, seconds, etc. A DAW is a complex system of clocks... some hardware running the same all the time and others in software, which is where MIDI functions live in a DAW.

Those of us who went from analog tape to digital tape long before computer DAWs were around, and those of us who were "MIDI musicians" syncing devices to tape long before DAWs were around, and those of us who were into sampling long before affordable digital recording was common place, have a marked advantage in conceptualizing SMPTE/EBU time synchronization as it really works. I'm no teacher. Trying to explain it all is probably beyond the scope of a thread on a web forum. It shouldn't be as hard as people are making it... but it's been like pulling teeth!

dammit2.jpg
 
Now you're just talking around the topic....and constantly referring back to the pre-DAW days has zero bearing.

While the clock in the DAC has no awareness of the actual time/position of an audio track...it still controls how that audio is recorded/sampled.
When tape SMPTE fluctuates....the DAW has no option but to "adjust" to the incoming code. When it "adjusts" the speed varies to keep time with the incoming SMPTE....and when the speed varies, the digital sampling must vary in sync with it, and the only way is for it to re-sample on-the-fly....which IS tied back to the digital clock.
If it's not doing that...then it's running free on it's clock, and so is the tape deck...and you got drift from pass to pass.
One single pass from a multitrack is not at question...since all tracks drift identiclly...we're talking multiple/different passes.

So while the digital clock is not aware of the time/position, it is still tied to the SMPTE/MTC. That's a plain as it gets, and the two MUST work together in sync, so as one varies to incoming SMPTE/MTC, so does the other.
I think that is certainly not beyond the scope of this thread. ;)

Here's an excerpt from my Samplitude ProX DAW manual:

CHASE LOCK SYNC - ADAPT SPEED BY RESAMPLING
Samplitude supports real chase lock synchronization, i. e. audio playback can be controlled by an incoming timecode signal. In this case not only the starting point of audio playback is controlled externally, but sync also controls playback speed if "Chase Lock" is activated. Samplitude is therefore capable of following analog tape devices or VCRs that always feature some slip over longer periods.

If fluctuations in speed occur, Samplitude can make adjustments in slave mode that ensure exact temporal synchronization. This function is called "chase lock". Use chase lock in case a device involved in the synchronization cannot be clocked centrally via Blackburst, Wordclock, or the digital input and Samplitude is the "slave". This is the case if the timecode is located on a track featuring a multitrack machine.

I think most folks can grasp that concept...and it covers everything I've been saying....to include the mention of using Blackburst/Wordclock as the other means of centrally controlling the devices.

In the case of the OP in this thread, and the central topic....there's NO sync reference and control of either device, so without "chase lock" option in the DAW, there will be some drift, and with a "chase lock" option in the DAW, there won't, but the DAW must re-sample to stay locked with tape fluctuations.

I know the manual is not in error, because I spent quite a bit of time testing the various sync options....which is why I now use the MicroLynx locked to Blackburst reference sync, and everything falls into place after that. I run DAW or tape deck as master....and it's all in sync either way, though by using the DAW as master, it doesn't have to do audio re-sampling. :)
 
Tim, how far off or on track (no pun intended) was I in my last post as far as my understanding of what's happening in Cubase when an analog transport is the master?
 
Now you're just talking around the topic....and constantly referring back to the pre-DAW days has zero bearing.

No I am not doing that at all. And understanding how we got where we are today technology wise has everything to to with it! Understanding history on any topic is the most important understanding a person can have. Otherwise people constantly try to reinvent the wheel because they're unaware of what people have done... how things were done... how standards and best practices came into being and were codified. I'm attempting to relate to another thing most people don't understand... namely how digital open-reel machines or ADAT, which are tape-based, function apart from the speed of the tape moving on the transport. The sample accuracy of those formats is not effected by tape speed or presence of wow & flutter. Just like a hard drive based system, the converter and its clock are only part of the system. Understanding this is key to grasping device synchronization in a setup using a DAW, MDM or any other kind of digital "recording" device.

You can discuss the hypothetical all you want, but experience is always about time and what you did/learned during that time... and how well you remember after. You can't get there from here. That is, people who've come into recording with a computer orientation or have become acclimated to that way of thinking will have a different vocabulary... similar words... different meaning. I see people trying to frame analog in digital terms all the time on these forums... because that's all they know (even though most don't even know that very well as they imagine).
 
You can discuss the hypothetical all you want....


There's nothing "hypothetical" in anything I've posted.

I've posted quite a bit of factual info, and a lot of quotes taken from various manuals that support that factual info.
The most you've done is to dismiss that info as all "errors" in the various manuals, and you just keep talking about how it it was "back in the day".
I said earlier that it was good to know the history...but in this thread we're talking about DAW---Tape Deck sync, and more specifically how a DAW does that when it's set to slave mode.
I've clearly described that and provided supporting info....so again, there's nothing "hypothetical". :)

All that other stuff about "words" is just distraction away from the main point.
 
The invitation to "pick it apart" is sincere and genuine and expressed with respect, Tim. The bit about "children" is a bit of a poke...no, its just a plain poke. Tim you've made this kind of statement in the past, and I (correctly or incorrectly) sense frustration and sometimes I have to wonder why you continue to hang out with the "children" if it is that much of a consternation. You've been a tremendous resource here, and other venues I'm sure, but the "I'm blessing you little people with my presence" tone, which is how it comes across to me

When I say things like "The children are running the classroom" I'm reminding people where the industry is today and that on amateur anonymous web forums when a consensus is established the majority that establishes it could be and often is made up of 15-year-olds who've learned most of what they know on web forums from other 15-year-olds. But no matter what age, I think each person should be honest with themselves about where they came from, how long they've been doing this and how they learned what they think they know. I don't think people would use these same kind of sources to learn how to practice medicine, or learn how to fly an airplane. I hope not anyway. Discussions on web forums, whether this one, gearslutz, prosoundweb, harmony central, music player, etc, are all the same. You may find clues for further research (preferably offline), but nothing, not even my contributions should be viewed as definitive.

I missed your earlier reply, so I'm reading that now... well after I run out and get some more Coca~Cola. BRB ;)
 
Back
Top