AudioPlayHead::getCurrentPosition timeInSamples is strange in Cubase

#1

It was my expectation that starting playback from the beginning of a project in Cubase would give me repeatable results, however with a default audio plugin with just some DBG in the processBlock MyPluginPIP.h (6.6 KB)

I get these outputs:
Cubase 9.5 VST3

Start
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:570:570
1024:1594:1024
1024:2618:1024
1024:3642:1024
1024:4666:1024
1024:5690:1024
1024:6714:1024
1024:7738:1024
1024:8762:1024
1024:9786:1024
1024:10810:1024
1024:11834:1024
1024:12858:1024
Stop
Start
1024:0:-12858
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:468:468
1024:1492:1024
1024:2516:1024
1024:3540:1024
1024:4564:1024
1024:5588:1024
1024:6612:1024
1024:7636:1024
1024:8660:1024
1024:9684:1024
1024:10708:1024
1024:11732:1024
1024:12756:1024
Stop
Start
1024:0:-12756
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:0:0
1024:430:430
1024:1454:1024
1024:2478:1024
1024:3502:1024
1024:4526:1024
1024:5550:1024
1024:6574:1024
1024:7598:1024
1024:8622:1024
1024:9646:1024
1024:10670:1024
1024:11694:1024
1024:12718:1024
1024:13742:1024
Stop

Cubase 9.5 VST2

Start
1024:-6247:-6247
1024:-5223:1024
1024:-4199:1024
1024:-3175:1024
1024:-2151:1024
1024:-1127:1024
1024:-103:1024
1024:920:1023
1024:1944:1024
1024:2968:1024
1024:3992:1024
1024:5016:1024
1024:6040:1024
1024:7064:1024
1024:8088:1024
1024:9112:1024
1024:10136:1024
1024:11160:1024
1024:12184:1024
1024:13208:1024
Stop
Start
1024:-6364:-19572
1024:-5340:1024
1024:-4316:1024
1024:-3292:1024
1024:-2268:1024
1024:-1244:1024
1024:-220:1024
1024:803:1023
1024:1827:1024
1024:2851:1024
1024:3875:1024
1024:4899:1024
1024:5923:1024
1024:6947:1024
1024:7971:1024
1024:8995:1024
1024:10019:1024
Stop
Start
1024:-6821:-16840
1024:-5797:1024
1024:-4773:1024
1024:-3749:1024
1024:-2725:1024
1024:-1701:1024
1024:-677:1024
1024:346:1023
1024:1370:1024
1024:2394:1024
1024:3418:1024
1024:4442:1024
1024:5466:1024
1024:6490:1024
1024:7514:1024
Stop

Cubase 8.5 gives similar results for both VST2/3

In Live 10 using VST2 I get the following:

Start
1024:0:-20480
1024:1024:1024
1024:2048:1024
1024:3072:1024
1024:4096:1024
1024:5120:1024
1024:6144:1024
1024:7168:1024
1024:8192:1024
1024:9216:1024
1024:10240:1024
1024:11264:1024
1024:12288:1024
1024:13312:1024
1024:14336:1024
1024:15360:1024
1024:16384:1024
1024:17408:1024
1024:18432:1024
1024:19456:1024
1024:20480:1024
Stop
Start
1024:0:-20480
1024:1024:1024
1024:2048:1024
1024:3072:1024
1024:4096:1024
1024:5120:1024
1024:6144:1024
1024:7168:1024
1024:8192:1024
1024:9216:1024
1024:10240:1024
1024:11264:1024
1024:12288:1024
1024:13312:1024
1024:14336:1024
1024:15360:1024
1024:16384:1024
1024:17408:1024
1024:18432:1024
1024:19456:1024
Stop
Start
1024:0:-19456
1024:1024:1024
1024:2048:1024
1024:3072:1024
1024:4096:1024
1024:5120:1024
1024:6144:1024
1024:7168:1024
1024:8192:1024
1024:9216:1024
1024:10240:1024
1024:11264:1024
1024:12288:1024
1024:13312:1024
1024:14336:1024
1024:15360:1024
1024:16384:1024
1024:17408:1024
1024:18432:1024
1024:19456:1024
1024:20480:1024
Stop

Exactly what I would expect.

Reaper also gives the same expected results for both VST2 and VST3.

Presumably this is a bug in Cubase or is it something else?

How can I synchronise to the timeline in Cubase from within an audio plugin?

edit: FWIW In Live 10 the AU also gives the expected results.

0 Likes

#2

is looping turned on?

also iiuc you can cause negative values just by moving playhead.

for example:

  • start playback at pos t.
  • stop playback
  • move playhead to t-x
  • start playback
0 Likes

#3

Looping is off, literally just starting playback from 00:00:00 and my expectation was the results seen in other hosts. It’s obviously something that is achievable in Cubase, as plenty of other plugins are able to sync with the timeline, I’m just not sure how to given these odd results.

0 Likes

#4

Out of curiosity I checked when starting from a place later in the timeline, and the results are similar: Cubase gives different timeInSamples each time playback is started, Live 10 gives the same consistent value (as one would expect).

edit: I also checked and the same applies for a synth plugin, timeInSamples is next to useless in Cubase, fine in the other hosts.

0 Likes

#5

But timeInSamples is accurate relative to the initial position plus the number of samples processed so far, right? So you should be able to keep synched. If I recall, although the initial start position might differ, the data that comes in still lines up with the expected sample position. For example, the attack of the first note may now show up at a point where its sample position relative the initial starting value is different from the last time, but it’s the same absolute position. If that was not the case, then our software wouldn’t work, and it has worked fine in Cubase for many years. (If I recall, I think Pro Tools also starts at different sample positions each time you restart the transport.)

0 Likes

#6

Yes, those columns in the DBG output above are block size:timeInSamples:timeInSamples delta from last block, but I’m a bit lost, how do I query the initial starting position as either measures or absolute time on the timeline?

I assumed timeInSamples would be deterministic, i.e. if I start from 00:00:00 I would expect it to be 0 in the 1st block. If my sample rate is 44.1kHz and I start playback at 00:00:01 (1 second into time line) then I would expect the first block to give 44100 when I queried timeInSamples and 44100 + block size in the next block, ad infinitum.

This is exactly what I see in Live and Reaper for the different plugin types.

My specific use case is for a simple “trance” gate, and I’ve managed a work around by counting samples processed, but this only works if I start the playback “in time” (i.e. aligned with the start of a bar). This isn’t exactly complex, and been done a million times before and probably also using JUCE, so I’m stumped as to how I can sync my gate’s “sequencer” exactly to the host timeline without timeInSamples being deterministic.

0 Likes

#7

If you need to align absolute time 0 with the start of your internal timing, then you should probably not rely on that being the first sample to be sent for processing. (The user might intentionally start the transport at any other time, right?) Rather, you should just look for where time 0 comes in in your data. If the first three buffers are before time 0, and time 0 is someplace in the middle of the fourth buffer, then your internal time 0 would just align with the inverse of the start of that fourth buffer. (That is, if buffer #4 started at -337, and had > 337 samples in it, then absolute time 0 occurs 337 samples into that buffer.) You need to decide what to do with any data before time 0. (One of our plugins simply ignores negative time, and starts the graph at time 0.)

1 Like

#8

Ahh, OK, makes sense. So instead of just once before my main processing loop checking the timeInSamples and trying to sync there, I should check it inside based on the timeInSamples + current_sample_processed and sync to that. Thanks :smiley:

edit: I’m still not entirely sure, I will have to do some experiments to get a firmer grasp :wink:

0 Likes