I am currently testing a Fostex R8 8-track R2R recorder a friend of mine lent me. One thing I want to try is to sync Ardour to LTC on the tape (to be able to print some tracks from Ardour to tape and then rerecord them in Ardour from there).
I am running a fresh copy of Ardour 8.1 on Fedora. Using the builtin LTC generator I was able to record six minutes of timecode on track 8 of the R2R. But I am probably missing something as I cannot get Ardour to recognize and chase the timecode.
LTC is coming in on input 16 of my soundcard and can be heard when monitored on Ardour’s mixer. In the “transport master” window I set the radio button to LTC and choose the right input. But no timecode is detected when the tape is running. The fields remain empty.
Below the play button I click on “int” to make Ardour sync to LTC. This changes the button to blinking “LTC”. Still no timecode is detected, neither in the “transport master” window nor in the master clock display. But when I switch back to “int” the master clock shows the last received LTC frame. So I guess it is actually decoded.
I did read the chapter on external sync in the reference manual, but might still be missing something. I am grateful for any hint.
Assuming the LTC Reader showed a valid signal, the issue might be fixed since Ardour 8.1.148.
There was a bug that resulted in any Timecode master to be disabled, when it was disconnected. In older versions of Ardour you can work around this using Window Connection Manager instead of the dropdown. First disconnect the LTC input and then manually connect it (here to input 16).
Then again there could well be some other additional issue, but LTC sync works here now in a quick test.
Thanks for the quick and extensive help. The LTC Reader plugin recognizes the timecode. Unfortunately disconnecting/reconnecting the input doesn’t work, neither in the “Transport Master” nor the “Connection Manager” window. The version is 8.1.0, the current official binary.
I think I will try to compile from git. Unfortunately the Fedora version is quite old (another todo). Getting all required libraries could be a challenge. Let me see.
What a coincidence. I just checked the Lua code of the plugin and saw that it is just a wrapper around Ardour’s LTC Decoder. And while looking for the build dependencies found the nightly builds. Then I saw your answer.
I will give it a try tomorrow. Need to catch some sleep first as it is 1:38am here.
For comparison I created a new session with 8.1.148, but that didn’t make a difference. The timecode you see below the master clock is only updated once when I toggle the time master LTC → int → LTC. Each time the delta keeps growing as the Ardour playback is not rolling.
Just a small sidenote: When you change the connection in the “Audio Connections” window the dropdowns in the “Transport Master” window don’t update themselves.
My educated guess is that this is unrelated, because it doesn’t work with a fresh session either. Interestingly the port is connected, as the timecode is displayed below the master clock every time I toggle LTC → int → LTC.
Looking at your last commit 0786be8, I wonder if the change in PortManager::remove_session_ports () completely solves the new found bug. I am not familiar with the Ardour code, so hopefully this doesn’t sound too stupid.
In the for-loop you check i->second->flags () & TransportMasterPort, but the PortFlags type has two more transport-related flags: TransportGenerator and TransportSyncPort.
Maybe you could define an inline method in the Port class that checks, whether the port is a session port / of a special family. If it makes sense you could check the additional flags there and it would be easier to spot this, when new port types are added.
A while ago (Ardour6) Ardour’s sync engine was re-worked into a finite state-machine. This lead to transport-masters (which control the session’s transport) to be moved out of the Session.
As a result, ports that control session transport now exist globally (without a session).
This had no effect on timecode generators (which do require a session, and are part of the session).
Last but not least, TransportSyncPort indicates that the port is not part of the normal session processing. Notably it is excluded from being resampled during vari-speed. This applies to both TransportMasterPort and TransportGenerator (in fact it is bitwise OR of those two flags).