Detailed steps on how to reproduce the bug
Build any JUCE LV2 plugin that reads getPosition() in processBlock().
Load in Jalv with a JACK transport master providing BBT.
Start transport.
getPosition() returns valid data for one cycle, then nullopt thereafter.
Suggested fix
Remove the invalidate() call so that the last received PositionInfo persists until overwritten by the next time:Position atom. Optionally, extrapolate ppqPosition and timeInSamples forward each cycle based on the last known BPM and speed.
What is the expected behaviour?
In juce_audio_plugin_client_LV2.cpp, PlayHead::invalidate() (line 549) sets info = nullopt at the start of every run() cycle. It is only repopulated if a time:Position atom arrives that cycle (line 571).
Per the LV2 Time extension spec, hosts send time:Position atoms only when transport state changes — not on every cycle. During steady-state playback, no atoms are sent. This means getPosition() returns valid data for one cycle when transport starts, then nullopt on all subsequent cycles until the next state change.
This breaks any plugin feature that depends on getPosition(): arpeggiators, tempo-synced effects, beat-synced LFOs, etc.
Spec reference from the LV2 Time extension author (David Robillard):
https://drobilla.net/2012/11/17/lv2-plugin-transport-synchronisation.html
"The host sends updates whenever the transport has changed in a way the plugin can not anticipate (anything but rolling along at the same speed/tempo/meter)."
Both Jalv (the LV2 reference host) and Ardour follow this convention.
Why VST/AU aren't affected
Those formats provide position info every callback (pull model). LV2 is push model — the wrapper applies pull-model assumptions to a push-model protocol.
Operating systems
macOS
What versions of the operating systems?
This is an LV2 bug, it presents on all operating systems.
Architectures
Arm64/aarch64
Stacktrace
Plug-in formats (if applicable)
LV2
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the develop branch
The bug is present on the develop branch
Code of Conduct
Detailed steps on how to reproduce the bug
Build any JUCE LV2 plugin that reads getPosition() in processBlock().
Load in Jalv with a JACK transport master providing BBT.
Start transport.
getPosition() returns valid data for one cycle, then nullopt thereafter.
Suggested fix
Remove the invalidate() call so that the last received PositionInfo persists until overwritten by the next time:Position atom. Optionally, extrapolate ppqPosition and timeInSamples forward each cycle based on the last known BPM and speed.
What is the expected behaviour?
In juce_audio_plugin_client_LV2.cpp, PlayHead::invalidate() (line 549) sets info = nullopt at the start of every run() cycle. It is only repopulated if a time:Position atom arrives that cycle (line 571).
Per the LV2 Time extension spec, hosts send time:Position atoms only when transport state changes — not on every cycle. During steady-state playback, no atoms are sent. This means getPosition() returns valid data for one cycle when transport starts, then nullopt on all subsequent cycles until the next state change.
This breaks any plugin feature that depends on getPosition(): arpeggiators, tempo-synced effects, beat-synced LFOs, etc.
Spec reference from the LV2 Time extension author (David Robillard):
https://drobilla.net/2012/11/17/lv2-plugin-transport-synchronisation.html
"The host sends updates whenever the transport has changed in a way the plugin can not anticipate (anything but rolling along at the same speed/tempo/meter)."
Both Jalv (the LV2 reference host) and Ardour follow this convention.
Why VST/AU aren't affected
Those formats provide position info every callback (pull model). LV2 is push model — the wrapper applies pull-model assumptions to a push-model protocol.
Operating systems
macOS
What versions of the operating systems?
This is an LV2 bug, it presents on all operating systems.
Architectures
Arm64/aarch64
Stacktrace
Plug-in formats (if applicable)
LV2
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the
developbranchThe bug is present on the
developbranchCode of Conduct