[LV2] LV2 vs. Ardour: unexpected time.Position events and time.frames values

[Sven Jaehnichen]

Hi,

I'm wondering about a strange but very reproducible of some of my LV2 
plugins (B.SEQuencer, B.Shapr) in Ardour. I'm not sure if this is a LV2 
feature or an Ardour's bug.

#1 For the two plugins mentioned above, I need both time.Position to get 
the bar / beat position and MIDI. Initially, I used two separate atom 
input ports. One with "atom:supports time:Position" (and designated as 
control) and the other one with "atom:supports midi:MidiEvent". I 
discarded this version as the plugins reproducibly crashed upon loading 
in Ardour (but everything worked fine in jalv and carla). Later I found 
out why (see #3).

#2 Putting both "atom:supports time:Position" and "atom:supports 
midi:MidiEvent" into a single atom input port seemed to work fine. But I 
accidentally found out that no time.Position events were received by the 
plugin from Ardour in this case. Once again, it works as expected with jalv.

#3 Once again split the atom inputs to one control port with 
time.Position and one MIDI port and recorded LV2_Atom_Event sequence. 
The protocol of the control port showed everything as it should show. 
But the MIDI port LV2_Atom_Event sequence now also contained 
time.Position (although it was not declared in the .ttl (and it didn't 
show up in #2 where it was declared)). In contrast to all other events 
where time.frames <= n_samples in run(), time.frames of time.Position in 
the MIDI port (and only there) contained a high 32 bit value in the most 
but not all cases. And it was counted down. This unexpected value made 
my plugins crash (#1), shame on me. The midi_Events however had 
time.frames <= n_samples in run() in the right way.

Does anybody know the meaning of this backward counting 32bit 
time.frames value for time.Position in a MIDI port?

Thanks in advance
Sven

PS: B.Shapr is Ardour-compatibly fixed in the meantime.