jack_transport is not intended to act as a the time master.
providing BBT information requires some kind of tempo map. This is
beyond the scope of jack_transport.
the non-clearing of the transport state information is a bug, for sure.
On Thu, Jul 2, 2015 at 8:20 AM, Tobias Hoffmann
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?
Jack-Devel mailing list