Who relies on VstTimeInfo.ppqPos?

[chordwizard]

Hey plugin developers, I would like to get your thoughts here.

I was recently debugging the VST (v2.4) hosting functions of the new version of our app Songtrix.
If you're interested, it is currently beta testing and you can get a copy from
http://www.chordwizard.net

I discovered that some plugins seem to have a real dependency on the ppqPos value of the VstTimeInfo structure supplied in response to audioMasterGetTime.

I was supplying zeroes here, and declaring this by leaving the kVstPpqPosValid flag clear, which I read as being valid host behaviour from the spec. But some plugins were choking on this, and freezing on the audio thread, typically when playing a sample triggered through the plugin's GUI.

I was able to correct this by filling ppqPos with a calculated value (based on samplePos, sampleRate, and a hardwired tempo of 120). So no new information added, just a parallel value tracking with samplePos, based on other values also supplied to the plugin.

So this is great. But I find it really strange.

Since the midi event timing is specified completely in VstMidiEvent.deltaFrames from the start of the current buffer, I can't see why ppqPos should be needed, unless the plugin is actually exchanging midi events with the host, or displaying musical timing in its GUI.

In Songtrix, at the point of dispatch to the plugin, the audio thread has limited awareness of the musical timing of the original sequence, and works only with sample timing. In many cases, there simply isn't a musical timing, where midi events are being generated interactively.

So who uses ppqPos in their plugin and how? Is that need so severe that you would let your plugin choke if it was supplied as zero every time?

[davidguda]

Not entirely sure I get it all but it's used to know where the host is playing right now. That is a different thing from midi input.
I have a plugin DrumR which has a small (drum) sequencer which has an auto-play mode. Knowing where the host is playing now is needed to keep the drums in sync.
In my case that is mostly needed when making a pattern rather than when triggering a specific pattern from MIDI.

[chordwizard]

Hey David, thanks for the comment. I think I see what you are saying.

If the plugin self-generates audio from timing information only, that is when it is needed.

But if it generates audio only from incoming midi events, then maybe not.

Many plugins offer Arp presets, I guess that might be a case that uses both - the midi event to trigger the arp sequence, and the ppqPos to handle the sequence timing so it syncs with the song.

[davidguda]

Yep arpeggiators inside synths might very well try to sync it with what is playing in the host.
Consider all plugins (like my EnvelopR) that offer some kind of "ducking"/pseudo-sidechain. You'd like that to be synced to host and wouldn't want to trigger each round with midi... that would even be a bad thing to do in the ducking example.

[Richard_Synapse]

In general it is a good idea to look at what Cubase does, and try to replicate that as closely as possible in your host. The VST spec allows you to deviate from what Cubase does in many ways, but in practice any deviation is likely to cause some plugins to fail. ppqPos is certainly something that is used by quite a few plugins, so I'd implement that one for sure.

Richard

[kingozrecords]

I thought it was fl studio dependent. Though, I could be mistaken. However, if not; in the same light I've found ppq to be a way of referencing timing, and flawlessly I may add.

[Markus Krause]

We are using ppqPos in most of our plugins. Mostly to sync the arpeggiator