Hi Nick,
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
unstable.
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
way.
The JACK Transport is a Good Thing. Some things about it that aren't easy
to understand:
* 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.
HTH,
Gabriel