A week or two ago, I recorded some tracks to use in a fixed-media project.
This week, I wanted to add some drums. So I wrote up new processes, set them up in the sequence, recorded them.
It’s an absolute train wreck at the end of the section. The new tracks are enough of a fraction of a percentage point faster that it’s totally unusable.
I’m setting TempoClock.tempo = 116/60 always for this project, so… 116/60 is different on different days? Or, with different soundcards perhaps?
Not sure if this is a “Question” or “Development” topic… for now I’ll have to delete all the old recorded files and redo all of them. But… should I really have to?
hjh
Not that this answers your question… But in cases like this sometimes I have found reaper time stretch totally usable and transparent (there are a couple different options of algorithms to try) … In case this is preferable to redoing all your other tracks
That’s fair. In this case, the recording is automated; it’s the difference between importing and aligning three tracks vs more than that.
(Edit: In this case, I have a group of synced tracks that are pitched, and the other group is unpitched, so I can actually use Reaper’s speed adjustment without pitch correction. The ratio ended up being about 1.0003, which pitch change = .003 cents would not be detectable except perhaps to Jacob Collier. I won’t lose sleep over that.)
Thinking about it overnight, I think it’s because SC language clock time runs independently of the soundcard sample clock, where it’s probably the sample clock that varies. What I find a bit odd is that my initial recordings lay nicely on the Reaper timeline, and yesterday’s multiple attempts just didn’t. A caveat for a “record in pieces” approach (which I’d adopted to simplify the code, but which then caused other problems).
My normal workflow is live, so I haven’t had a serious problem with this until now.
hjh
Thinking about it overnight, I think it’s because SC language clock time runs independently of the soundcard sample clock
Yes, that’s the reason. Server messages are scheduled on NTP time and then dynamically converted to sample time, which is not deterministic.
You can use Supernova with s.options.useSystemClock = false, but then the latency will slowly drift over time…