I'm still using debian's jackd1/libjack0 package (0.124.1) and have not
tried to reproduce this with git master yet (at least, I haven't seen an
obvious fix in the commit log since 0.124.1).
In one terminal window I run jack_showtime.
In the other window I do:
tempo 96 # just in case
play # does not
jack_showtime correctly shows the state, but no BBT information. From my
own client I know that jack_position_t::valid==0.
Some testing revealed that the timebase() callback in tools/transport.c
is *not called at all*, although jack_set_timebase_callback is called
and returns without error.
- But everything works fine when I switch to the jack2 stack...
And in some cases, when switching between/enabling/disabling different
jack_position_t::valid retains the JackPositionBBT flag (and stale
information) -- but no-one updates them any more...
Maybe related: I've seen some strange values (*very* large negative
number) for bar_start_tick when using ardour4.1.
The very first time (and after rewind?) it contains 0.0 and is not
updated. A quick glance into the ardour source code reveals that this
field is not implemented yet. I could probably live with that.
BUT: After stopping+starting the playback, these strange values
appear... How can I know whether some value in this field is usable at
all -- except for some heuristics?
Back to the original topic... in both cases the jack_position_t struct
contains stale/random values, instead of starting from a "clean" base --
maybe memset(,0,) is all that is needed here?