[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.

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!

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

I've implemented DAW synchronization using midi messages start/continue/stop/reset and 24 ppqn clockticks (that should get scheduled quite precisely).

However in current development is a simple [r _hv_dpf_bpm] receiver for the current BPM value, that I am now using for synchronized delay effects.

Any ideas to improve DAW integration here are appreciated

@ddw_music Have you tried the DPF plugin export using Heavy inside of PlugData yet?

I'm not familiar with any of that, sorry. I found DPF online but Heavy, no idea.

hjh

https://plugdata.org/images/hvcc.png

From there you can then output a plugin binary of your patch (VST2/VST3/LV2/CLAP).

Oh I'm sorry. I am referring to https://github.com/Wasted-Audio/hvcc which we have integrated in PlugData:

https://plugdata.org/images/hvcc.png

From there you can then output a plugin binary of your patch (VST2/VST3/LV2/CLAP).

Ah ha, very nice! So a publicity narrative could be "PlugData: Max4Live for every DAW; PlugData-hvcc: RNBO for free" (more or less) and this all seems to have happened very quickly.

FWIW I think this kind of narrative could help attract users. I'm teaching in mainland China. Recently I was talking with a professor in Beijing who said Pd will never catch on in China, because software piracy is the norm -- so their logic is, why use minimal-core Pd legitimately when I can have all of Max+Jitter for free? A counterargument is, then: If you use Max, then you can integrate with only one DAW. If you use Pd, you can integrate with your choice of DAW. Cycling '74 isn't offering that, and won't. (I used PlugData recently in Reaper to add another sample to a kick drum in some recorded material -- filter --> onset detector --> sample player -- worked a treat! I very much appreciated having the flexibility to use Pd wherever I want.)

However I might have to cave in and go Max in class, because GEM is showing more and more compatibility problems, especially on Mac.

hjh

So they still use Macs, but pirate all the software for it? Kind of odd.

But yeah the "max4live except everywhere" is the narrative that I've been telling people as well.
The advantage over RNBO is that we don't need to use some online compiler either. The toolchain we use with Plugdata is all integrated!

So you can build a VST or program a microcontroller straight from the DAW

So they still use Macs, but pirate all the software for it? Kind of odd.

The rich kids use Mac. Most use Windows. And Linux...? While it barely exists for consumers in the West (I'm a 13+ year Linux user btw, and I have no plans to switch to a commercial OS, but I'm honest about Linux's market share), it doesn't exist at all over here.

There seems to be an assumption that commercial software is always better than free... which is often true... so it's "why would I deal with a smaller feature set and less elegant UI in, say, GIMP when cracked PhotoShop is a few clicks away?" (I do use GIMP myself.) There are exceptions, though (e.g. AFAIK there's nothing like SuperCollider in the commercial sphere). So I like these edge cases where FLOSS ends up being more broadly usable.

hjh