Been working on this for awhile, only this week had a chance to record the material.

[abl_link~] (in Deken) has existed for awhile for Ableton Link sync. PlugData is more recent for Pd to run in a DAW, with timeline sync.

With both approaches, however, you'll crash into a handful of problems whose solutions are not at all obvious. This project is all about: What does it really take to have Ableton Link, or DAW timeline, sync working properly. 49 minutes a bit longer than I expected.

(This is exposing some rough edges in Pd's interfaces. Unfortunately rough edges can end up being a feedback loop -- something is hard, so people avoid it, and as a result, it remains hard and people continue to avoid it. I hope this will break the feedback loop in some crucial places and make these types of sync more approachable.)

hjh

PS Note one correction in the video's description.

@ddw_music

Nice tutorial!

I've just rewritten the automation parameters system, so DAW interaction should be even smoother in the future:

I'm interested in fixing some of the problems you're describing with [playhead], I agree that the outputs are confusing and unhelpful, so it might be worth it to add a new object, with a similar interface to your [playhead-tick] object, maybe call it [beat]? I think I was planning to do that already, but I forgot about it!

I could also replace the regular [playhead] object, though it might be nice to leave it in for backward compatibility, compatibility with Camomile, and because it provides a lot of low-level information in case you need that.

I also want to think about whether we can reduce the rate at which that data comes through, I could implement something to at least filter out the redundant messages. Your tutorial made me realise that I'm sending the playhead data every Pd audio block (64 samples in plugdata) instead of every DAW audio block, which is useless!

@timothyschoen said:

I'm interested in fixing some of the problems you're describing with [playhead], I agree that the outputs are confusing and unhelpful, so it might be worth it to add a new object, with a similar interface to your [playhead-tick] object, maybe call it [beat]?

Sure, that would be nice.

Actually I wasn't using [playhead] (though it might be easier if I were) -- I'm reading the raw messages from [r playhead].

A couple of things that [playhead-tick] does that I find really crucial:

• The beat triggers are generated by anticipating the beat (position --> [wrap] --> [moses a_threshold] where the default threshold is 0.9 -- then take 1 - the wrapped (fractional) part of the position and delay. This is because the resolution of the position values is limited by the hardware block size. The anticipate-and-delay approach should be on time for any hardware buffer configuration (and if it doesn't, just allow more of a gap: [playhead-tick 0.2] --> threshold = 0.8).

• I found it very useful to know not only that playback has started or stopped, but at what time. My [playhead-tick] did some tap dancing to get it. With [playhead] it would be:

I could also replace the regular [playhead] object, though it might be nice to leave it in for backward compatibility, compatibility with Camomile, and because it provides a lot of low-level information in case you need that.

I think it's probably better to have both.

Your tutorial made me realise that I'm sending the playhead data every Pd audio block (64 samples in plugdata) instead of every DAW audio block, which is useless!

I agree. There is not much benefit in getting the same position value 4, 8 or 16 times.

(Is it possible to adjust this for [r playhead] too?)

hjh