[LAD] non-sequencer tempo drift
Gabriel M. Beddingfield
gabriel at teuton.org
Sun Oct 18 12:06:36 UTC 2009
On Sun, 18 Oct 2009, nick bailey wrote:
> I've been playing with Non-sequencer over the last few days, love the
> simplicity and uncluttered approach to the programme, however I'm
> finding if run alongside Hydrogen or Ardour, the tempo drifts out of
> sync, this occurs playing any song longer than a couple of patterns.
> The obvious answer to this is to have ardour as jack transport master,
> Non-sequencer does not like this however and crashes. I post the
Since Non is a pretty immature program, it's inflexible about the
Transport. When initializing, it always wants to be the transport master,
and doesn't take action of another program takes over. That's why it's
> question here rather than Linux Audio Users because I plan to write
> applications utilising Jack MIDI myself and am wondering the best
> approach to implement tempo in absence of alsa sequencer, which I found
> quite nice to use but still jittery even with high res timers / real
> time kernels.
The transport is the way to go. One way would be to take it upon yourself
to fix Non's transport. You will learn a lot of the in's and out's that
The JACK Transport is a Good Thing. Some things about it that aren't easy
* The program who is transport master can *lose* this
status at any time without notification. You
must not write your program with logic that says
"If I'm the master... calculate this way, but if
I'm a transport slave.... calculate some other way."
* Because of that, always program your audio code as
if it's *always* the transport slave. Set up the
Transport Master code elsewhere.
* When you supply the Bar:Beat:Tick info, it needs
to come evenly. Your ticks-per-beat and beat-per-
bar needs to align.
* Beware of frames-per-tick roundoff error. It's
natural to calculate frames-per-tick, round it to
and integer, and use that as a basic building
block. However, it will result in tempo drift.
More information about the Linux-audio-dev