Perhaps a question for Pierre? (Can't figure out how to @ people with a space in their name... @Pierre-Guillot)

I've just been fiddling around with PlugData. I found in this project's issue reports that you can use [r playhead] (same as Camomile) to get information about play state, tempo, position etc.

I would like to attach "position" messages to my scheduler object, but I don't quite understand the position values that are being reported. Documentation seems scarce.

When the project is playing, [r playhead] emits messages like:

[ position, 11.842176437378, 261120.0, 32.0, 4.0, 5.921088218689 ]
[ position, 11.88861656189, 262144.0, 32.0, 4.0, 5.9443082809448 ]
[ position, 11.935056686401, 263168.0, 32.0, 4.0, 5.9675283432007 ]
[ position, 11.981496810913, 264192.0, 32.0, 4.0, 5.9907484054565 ]
[ position, 12.027936935425, 265216.0, 32.0, 4.0, 6.0139684677124 ]
[ position, 12.074376106262, 266240.0, 32.0, 4.0, 6.0371880531311 ]
[ position, 12.120816230774, 267264.0, 32.0, 4.0, 6.060408115387 ]

To work with the scheduler, I need to be able to anticipate the next tick time. The difference between successive beats (first number) appears to be consistently 0.04644012, and this seems to be proportional to tempo (160 bpm gets 0.061919212341).

Does anyone know what the exact relationship is? I can check tomorrow if it's consistent across DAWs too, but not today.

Data collection patch is (sending by OSC because I couldn't copy/paste the log within PlugData's window):

hjh

@ddw_music Hi! The position message is actually a list of 3 floats. It contains ppq_position, samples and seconds. The ppq_position you're reading is position in quarter notes. Hope that helps!

@timothyschoen Looking at the numbers I thought it must be quarter notes, but still couldn't tie them together. So does the DAW frame rate affect the message (seems likely)....?

Ahhh... ppq_position brought me to here...... https://ccrma.stanford.edu/~jos/juce_modules/structAudioPlayHead_1_1CurrentPositionInfo.html... @ddw_music
David.

@ddw_music Yes.... buffer.
Horrible....... https://www.kvraudio.com/forum/viewtopic.php?t=462943
Some code on the third page but still not a happy bunny.
Maybe some DAWs have implemented a tempo message since then?
David.

@whale-av said:

@ddw_music Yes.... buffer.
Maybe some DAWs have implemented a tempo message since then?

Tempo must be available, since plug-ins have been doing e.g. tempo-synced delays for at least a decade already.

(In fact, it is available via Camomile: [route tempo position].)

Anyway... I've been considering solutions, and I think I can do this.

1. Set some threshold close to the beat, but before the beat, say x.9 beats.
2. For the first tick past the threshold, get "time to next beat" = roundUp(pos) - pos = int(pos + 0.99999999) - pos.
3. [delay] by this many beats ([delay] and the tick-scheduler will have been fed "tempo x permin" messages all along).
4. Then issue the tick message to the scheduler, in terms of whole beats (where the time-slice duration is always 1.0).

At constant tempo, I'd expect this to be sub-ms accurate.

If the tempo is changing, especially a large, sudden change, then there might be some overlaps or gaps. But [delay] correctly handles mid-delay tempo changes, so I'd expect these to be extremely small, probably undetectable to the ear.

Half a beat at 60 bpm + half a beat at 120 bpm does indeed = 750 ms -- so the delay object is definitively updating tempo in the middle of a wait period.

I'll have to build it out and I don't have time right now, but I don't see an obvious downside.

hjh

So I have a working prototype:

You schedule entirely in terms of beat indices and the cooperation between playhead-tick and tick-scheduler gets the messages back out on time.

hjh

@ddw_music Could you share this abstraction? I'd like to include something like this in PlugData, it would make it much easier for beginners to sync with DAW tempo.

@timothyschoen said:

@ddw_music Could you share this abstraction? I'd like to include something like this in PlugData, it would make it much easier for beginners to sync with DAW tempo.

That's the plan -- it's not finished yet, though. [tick-scheduler] is in my abstraction pack. [tick-scheduler] is recently updated to be all-vanilla btw -- it used to use pdcontainer but that's incompatible with plugdata, so I built a pure vanilla heap implementation and wrapped that in a priority queue abstraction, which the scheduler uses. (EDIT: I think I haven't pushed these changes up to github yet.) [playhead-tick] is just built today and I'm not sure the interface is totally right yet.

[r playhead] needs help to be usable for most people, for sure. AFAICS messages are repeated (redundant) when Pd's control period is shorter than the audio hardware block (which is, like, for everybody). So e.g. the "playing" message doesn't emit only when the play status changes -- I think you get dozens/hundreds of "playing 0" messages per second. Nobody needs that. In my current sketch, [playhead-tick] eats repeated values -- every message key outputs only when the first numeric value changes. You hit "play" in the DAW and my abstraction puts out one and only one "playing 1" message. It's trickier than one might expect, to do this, and average users shouldn't have to.

Anyway that's why I fiddle with things like this: something that should be easy but isn't.

hjh

OK, I just pushed them all -- go ahead and try -- https://github.com/jamshark70/hjh-abs

hjh

One more update: I just removed the second outlet from the version in the screenshot above. The idea for this abstraction is to use the cleaned-up beat-tick messages + tempo messages for scheduling, instead of raw position messages. Raw "position xxx" messages are still available from your own instance of [r playhead].

So now it's: o1 = tick messages, o2 = tempo messages, o3 = all other messages.

hjh