[LV2] LV2 vs. Ardour: unexpected time.Position events and time.frames values
sjaehn at jahnichen.de
Sat Oct 26 09:40:50 PDT 2019
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
PS: B.Shapr is Ardour-compatibly fixed in the meantime.
More information about the Devel