22 Jan
2010
22 Jan
'10
5:44 p.m.
Hi, some of you might like to know...
All the discussion of tempo maps and sync in the Jack lists forced me
to get off my butt and finally fix MusE's midi sync in.
(Someone asked recently in the Jack lists if there are any apps
which sync properly. Here is one answer).
Until now, MusE responded to midi sync by calculating the sync's tempo.
Then, this tempo together with the sample rate and current frame,
determined what 'tick' MusE was currently at. And of course, ticks drive a
midi engine to produce the notes at particular times.
Because a tempo value was used, sub-tick (frame) resolution
was available. Trouble is, that was the problem, a too-lofty goal.
It used a complicated 24-stage clock tempo filter while playing,
and a simpler three-stage filter while idling in stop mode.
This meant it could not respond to fast changes in tempo, even a
simple step. It was prone to drift, even without tempo changes.
Considering incoming tempo can drift slightly, I had originally
recorded the incoming tempos to a list so I would have
and exact record of the whole 'time line'.
But the whole idea of using tempo seemed odd.
So my idea was to 'direct drive' (increment) the midi engine's
tick counter by the incoming sync messages.
Drift between master and slave has been essentially eliminated.
Response is instantaneous.
The only slight drawback is the resolution.
I've abandoned any notion of using a tempo or tempo map,
or to obtain sub-tick (frame) resolution, during external sync.
At standard 24 ticks per quarter note, resolution is 1/3 of a
64th note. Not too shabby, acceptable for music.
Now I'm thinking, this is probably how sync was designed to be used,
considering simple old 80's hardware - (what clock filtering?).
Extreme stress tests with a Roland TR-505 which has an
adjustable 'analog' tempo pot, and a complete song in the app,
with extra 'tick' tracks driving external synths:
Rock solid and stable, even when going absolutely nuts
with the tempo knob! No noticeable resolution effects.
In our SVN repo now.
Tim.
22 Jan
22 Jan
6:04 p.m.
On Fri, Jan 22, 2010 at 4:37 PM, Tim E. Real <termtech(a)rogers.com> wrote:
Hi, some of you might like to know...
All the discussion of tempo maps and sync in the Jack lists forced me
to get off my butt and finally fix MusE's midi sync in.
(Someone asked recently in the Jack lists if there are any apps
which sync properly. Here is one answer).
here's another:
http://ardourmidi.wordpress.com/page/3/
i don't know how much variable tempo testing Hans did; perhaps he will chime in.
--p
6:28 p.m.
On January 22, 2010 05:04:25 pm you wrote:
On Fri, Jan 22, 2010 at 4:37 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
Are the midi (pianoroll) features in Ardour's releases now?
When I install my distro's package I still can't seem to find them.
Hi, some of you might like to know...
All the discussion of tempo maps and sync in the Jack lists forced me
to get off my butt and finally fix MusE's midi sync in.
(Someone asked recently in the Jack lists if there are any apps
which sync properly. Here is one answer).
here's another:
http://ardourmidi.wordpress.com/page/3/
i don't know how much variable tempo testing Hans did; perhaps he will
chime in. 
6:31 p.m.
Tim E. Real wrote:
On January 22, 2010 05:04:25 pm you wrote:
It's Ardour 3 ;).
On Fri, Jan 22, 2010 at 4:37 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
Are the midi (pianoroll) features in Ardour's releases now?
When I install my distro's package I still can't seem to find them. Hi, some of you might like to know...
All the discussion of tempo maps and sync in the Jack lists forced me
to get off my butt and finally fix MusE's midi sync in.
(Someone asked recently in the Jack lists if there are any apps
which sync properly. Here is one answer).
here's another:
http://ardourmidi.wordpress.com/page/3/
i don't know how much variable tempo testing Hans did; perhaps he will
chime in.
6:59 p.m.
On Fri, 2010-01-22 at 16:37 -0500, Tim E. Real wrote:
So my idea was to 'direct drive' (increment)
the midi engine's
tick counter by the incoming sync messages.
Drift between master and slave has been essentially eliminated.
Response is instantaneous.
Keep that! but ..
The only slight drawback is the resolution.
I've abandoned any notion of using a tempo or tempo map,
or to obtain sub-tick (frame) resolution, during external sync.
What you can do is guess that the next tick will come approximately at
the same interval as the previous, divide that interval by four to get a
useable resolution. If a tick comes early, dump whatever notes are left
to be played up to that point. Somebody is fooling around with
variospeed fx, and there is no consistent beat or 'feel' anyway.
At standard 24 ticks per quarter note, resolution is
1/3 of a
64th note. Not too shabby, acceptable for music.
Ok for written music or if you have a tempo of 280 bpm, else not!
Now I'm thinking, this is probably how sync was
designed to be used,
considering simple old 80's hardware - (what clock filtering?).
The very first ones (like the MSQ 700 I have on display here on my DX7),
but not later ones. Roland also made a gadget you could tap, and it
would create a 24 pulse/q-note sync out of that. It could be set to
average over 2, 3 or 4 'taps' (or kicks on the bass drum, or ..)
Rock solid and stable, even when going absolutely
nuts
with the tempo knob! No noticeable resolution effects.
If you say so ...
/jma
7:41 p.m.
On January 22, 2010 05:59:06 pm you wrote:
Does not matter
tempo, any tempo works, 20 or 500.
Really the resolution it is not noticeable, even at 20BPM.
64th notes are triggered on the second third of where the note should have
been. A resolution of 1/3 of a 64th note is pretty good, for music, eh?
Cool, an
averaging tempo generator!
No kidding, this puppy is ready for any instantaneous change in
external tempo, step or otherwise. It really is usable, now.
The crazy tempo knob thing was just a stress test.
The real challenge will be supporting the audio tracks with external sync,
when (if) I finish adding time stretching, with no tempo map to go by.
Initial thoughts seemed positive on this.
Tim.
On Fri, 2010-01-22 at 16:37 -0500, Tim E. Real wrote:
Good, but
that would introduce glitches.
What if the next sync comes at two or three times as long as the last one?
One simple (slower) tempo change and the rest of the song is out of sync.
We should not guess, we cannot assume or look ahead.
The only solution seemed clear to me: Straight ahead linear real time,
no assumptions of what's to come.
So my idea was to 'direct drive'
(increment) the midi engine's
tick counter by the incoming sync messages.
Drift between master and slave has been essentially eliminated.
Response is instantaneous.
Keep that! but ..
The only slight drawback is the resolution.
I've abandoned any notion of using a tempo or tempo map,
or to obtain sub-tick (frame) resolution, during external sync.
What you can do is guess that the next tick will come approximately at
the same interval as the previous, divide that interval by four to get a
useable resolution. If a tick comes early, dump whatever notes are left
to be played up to that point. Somebody is fooling around with
variospeed fx, and there is no consistent beat or 'feel' anyway. At standard 24 ticks per quarter note, resolution
is 1/3 of a
64th note. Not too shabby, acceptable for music.
Ok for written music or if you have a tempo of 280 bpm, else not! Now I'm
thinking, this is probably how sync was designed to be used,
considering simple old 80's hardware - (what clock filtering?).
The very first ones (like the MSQ 700 I have on display here on my DX7),
but not later ones. Roland also made a gadget you could tap, and it
would create a 24 pulse/q-note sync out of that. It could be set to
average over 2, 3 or 4 'taps' (or kicks on the bass drum, or ..) Rock solid and
stable, even when going absolutely nuts
with the tempo knob! No noticeable resolution effects.
If you say so ...
8:22 p.m.
On Fri, 2010-01-22 at 18:34 -0500, Tim E. Real wrote:
Good, but that would introduce glitches.
What if the next sync comes at two or three times as long as the last one?
Say the last sync came 20 ms ago. We guess that the next will be
something like the same but and devide the next 20 ms seconds in 4
periods of 5 ms each. Three things can now happen:
a) The next pulse comes very early, perhaps after 10 ms? Dump out on the
interface whatever was supposed to play in the later, in the last
periods.
b) The next pulse comes very late, perhaps after 30ms? In that case we
have have already played everything. There will be slight gap which will
go unnoticed given the dramatic change of tempo.
c) The next sync comes approximately as expected, perhaps after 19 or
21ms? Well, then there is no problem at all :-D
One simple (slower) tempo change and the rest of the
song is out of sync.
No!
We should not guess, we cannot assume or look ahead.
Yes we can! (Hey, Roland already figured this out back in -85 or so)
The only solution seemed clear to me: Straight ahead
linear real time,
no assumptions of what's to come.
This is soo 1982 ...
Really the resolution it is not noticeable, even at
20BPM.
20BPM is a resolution of 125 ms?? I am now convinced you do not not
record yourself playing keyboard.
9:45 p.m.
On January 22, 2010 07:22:14 pm you wrote:
Sure I do.
I record my KB by turning off external sync in the app so it uses its
tempo map for precise note time measurement.
I sure wouldn't sync the app with my KB as sync master at 20BPM while
recording my live performance on the KB !
Looking at my piano roll, I have some 64th notes, and some odd time notes
here and there. But on playback it sounds great even at 20BPM playback,
considering, well, it's at 20BPM ! Even if some notes are slightly off.
Tim.
On Fri, 2010-01-22 at 18:34 -0500, Tim E. Real wrote:
Yeah well, so are some parts of some linux apps, eh? He he...
Gee, I thought my newly acquired C64 skills would translate well here.
And what's wrong with my mullet?
Ok, you've convinced me, there's room for improvement, I'll see if I can
work it in. Thanks.
Good points. When that late sync finally arrives I can
adjust and make up for time lost due to the guess, even if it means
some notes will play sooner than expected during that moment,
while still regaining sync later.
Anyway it's way better than it was, now it's even usable. Just happy
about that.
Good, but that would introduce glitches.
What if the next sync comes at two or three times as long as the last
one?
Say the last sync came 20 ms ago. We guess that the next will be
something like the same but and devide the next 20 ms seconds in 4
periods of 5 ms each. Three things can now happen:
a) The next pulse comes very early, perhaps after 10 ms? Dump out on the
interface whatever was supposed to play in the later, in the last
periods.
b) The next pulse comes very late, perhaps after 30ms? In that case we
have have already played everything. There will be slight gap which will
go unnoticed given the dramatic change of tempo.
c) The next sync comes approximately as expected, perhaps after 19 or
21ms? Well, then there is no problem at all :-D
One simple (slower) tempo change and the rest of
the song is out of sync.
No!
We should not guess, we cannot assume or look
ahead.
Yes we can! (Hey, Roland already figured this out back in -85 or so)
The only solution seemed clear to me: Straight
ahead linear real time,
no assumptions of what's to come.
This is soo 1982 ... Really the
resolution it is not noticeable, even at 20BPM.
20BPM is a resolution of 125 ms?? I am now convinced you do not not
record yourself playing keyboard.
23 Jan
23 Jan
2:31 a.m.
On January 22, 2010 05:31:11 pm you wrote:
Tim E. Real wrote:
D'oh! No wonder I could never find it. Sorry.
(Those posted Ardour graphs remind me of Phase Locked Loop
circuits' error control voltages.)
I can imagine sync was a tougher nut to crack in Ardour.
MusE's ticks per quarter note is fixed at 24, although
the 'frames per quarter note' (hence division) is variable.
And you'd want sub-tick (frame) resolution in an app like Ardour.
I want to get our MTC code working. I've got the rate
detectors working and have monitored input from Ardour Ok.
Question: Ardour supports many different timecode fps
but MTC only has two bits for the fps.
How are these other fps supported? Not for MTC?
Tim.
On January 22, 2010 05:04:25 pm you wrote:
It's Ardour 3 ;). On Fri, Jan 22, 2010 at 4:37 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
Are the midi (pianoroll) features in Ardour's releases now?
When I install my distro's package I still can't seem to find them. Hi, some of you might like to know...
All the discussion of tempo maps and sync in the Jack lists forced me
to get off my butt and finally fix MusE's midi sync in.
(Someone asked recently in the Jack lists if there are any apps
which sync properly. Here is one answer).
here's another:
http://ardourmidi.wordpress.com/page/3/
i don't know how much variable tempo testing Hans did; perhaps he will
chime in.
12:36 p.m.
On Sat, Jan 23, 2010 at 1:23 AM, Tim E. Real <termtech(a)rogers.com> wrote:
I can imagine sync was a tougher nut to crack in
Ardour.
MusE's ticks per quarter note is fixed at 24, although
the 'frames per quarter note' (hence division) is variable.
And you'd want sub-tick (frame) resolution in an app like Ardour.
MIDI clock, which is what you're syncing to, is fixed at 24 msgs per
quarter note, so there is no difference there. Ardour syncing to this
is no different than MusE.
I want to get our MTC code working. I've got the
rate
detectors working and have monitored input from Ardour Ok.
Question: Ardour supports many different timecode fps
but MTC only has two bits for the fps.
How are these other fps supported? Not for MTC
MTC only supports these rates:
enum MTC_FPS {
MTC_24_FPS = 0,
MTC_25_FPS = 1,
MTC_30_FPS_DROP = 2,
MTC_30_FPS = 3
};
the pull up/pull down "rates" are not really rates at all - just rules
about computing time.
MTC can be hard to sync to because the MTC transmitter can be bursty.
Torben Hohn recently applied some relatively sophisticated control
theory to the problem (in ardour3) which we believe should optimize
things but we haven't had a chance to really test it in depth yet.
--p
10:36 p.m.
On January 23, 2010 11:36:36 am you wrote:
On Sat, Jan 23, 2010 at 1:23 AM, Tim E. Real
<termtech(a)rogers.com> wrote:
I can imagine sync was a tougher nut to crack in
Ardour.
MusE's ticks per quarter note is fixed at 24, although
the 'frames per quarter note' (hence division) is variable.
And you'd want sub-tick (frame) resolution in an app like Ardour.
MIDI clock, which is what you're syncing to, is fixed at 24 msgs per
quarter note, so there is no difference there. Ardour syncing to this
is no different than MusE.
I want to get our MTC code working. I've got
the rate
detectors working and have monitored input from Ardour Ok.
Question: Ardour supports many different timecode fps
but MTC only has two bits for the fps.
How are these other fps supported? Not for MTC
MTC only supports these rates:
enum MTC_FPS {
MTC_24_FPS = 0,
MTC_25_FPS = 1,
MTC_30_FPS_DROP = 2,
MTC_30_FPS = 3
};
the pull up/pull down "rates" are not really rates at all - just rules
about computing time.
OK. I was curious if Ardour had somehow taken advantage of
another 2 MTC SMTPE format bits undocumented or something !
Do you mean rates like '60fps' are 'virtual' rates dependant on the
pull-up/down? (Darn I should know this...)
MTC can be hard to sync to because the MTC transmitter can be bursty.
Torben Hohn recently applied some relatively sophisticated control
theory to the problem (in ardour3) which we believe should optimize
things but we haven't had a chance to really test it in depth yet.
I studied
MTC and SMTPE and a few variants in detail, it's a bit weird.
Guess it comes from its 'tape' lineage.
Cool that it can go backwards, though. What a brain twister that is!
FYI Just committed some (more) midi sync, MMC, and MTC fixes to MusE.
No transmit/receive sync with MTC yet, just transport start and
display of SMTPE format.
I just don't know how I'm going to deal with MTC sync yet !
Tested OK so far with Ardour and Rosegarden.
Question: What happened to Rosegarden's ability to sync to
external midi clock? The option is no longer there, so it just runs
on its own time. I'm sure it had that option before.
You mentioned support in Ardour 3, which will be nice.
Tim.
5230
days inactive
5231
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Jens M Andreasen -
Paul Davis -
Ralf Mardorf -
Tim E. Real