1 Jul
2004
1 Jul
'04
10:19 a.m.
Hi,
A friend of mine owns a Roland vs-1680 harddiskrecorder. It has a
feature that allows for recording and playing back a midi clock signal
alongside the audio tracks. This makes it possible to create a tempo
map with a (hardware) sequencer, record it on the vs-1680, and use it
to keep the sequencer in sync with subsequently recorded audio tracks .
We work together on a project, and i would like to be able to record
and play back the audio mix from the vs-1680 to my computer together
with the midi clock data (he takes his machine home to work on the
audio part). That way i can work on the sequences on my mpc1000, and
play back the audio whith the sequences synced midi clock slave.
I believe there is currently no linux app that can do that, so i am
considering to try to create a utility for it. But i have little
programming experience and none regarding alsa and jack, so i would
like feedback on my ideas.
My plan is to write a little program that opens 2 midi ports (in and
out) and 2 jack ports (in and out). The program wil monitor the midi
input port for midi clock messages. It will write zero's to the jack
output port but when it recieves a midi clock message it will write a
value of 1 to the jack port. This way i can store the midi clock
signal in a audio file, for example with ecasound. I know, this is
ugly! For playback i would have the program monitor the jack input port and
output a midi clock message when a sample value of 1 passes by.
I hope this explains my plan clear enough. I have looked at the
example programs for alsa and jack and to me it looks like i could
copy and paste something together, that could be my lack of
experience. What do you think? Is this possebly going to work or do i
overlook major difficulties?
Any advice would be very welcome!
--
Greetings, Gerrit
1 Jul
1 Jul
11:28 a.m.
New subject: [linux-audio-dev] Utility for recording audio track with midi clock
We work together on a project, and i would like to be
able to record
and play back the audio mix from the vs-1680 to my computer together
with the midi clock data (he takes his machine home to work on the
audio part). That way i can work on the sequences on my mpc1000, and
play back the audio whith the sequences synced midi clock slave.
getting a general purpose computer to output MIDI Clock (and/or MIDI
Time Code, just so nobody confuses the two of them) is a very hard
problem. There are 24 MIDI Clock messages per quarter note. This means
that for a piece in 4/4 at 120bpm, you need to output 1 MIDI byte
every 20ms. Not so bad - its a nice even multiplier of the system
interrupt frequency. However, just change the tempo or the time
signature, and all of a sudden you have situations where the MIDI
Clock byte needs to be output every 18ms or every 32ms or ever 9.7ms
or every 56.5ms.
until the high resolution clock timers patch is solid enough to be
used by any system, there is no way to schedule MIDI output with this
kind of resolution, and if you can't schedule it, then the receiver of
your MIDI clock signal will see a lot of jitter and may refuse to lock
to it. Even if it locks, its not clear what it will do with the jitter.
signal in a audio file, for example with ecasound. I
know, this is
ugly! For playback i would have the program monitor the jack input port and
output a midi clock message when a sample value of 1 passes by.
JACK does block structured audio. This won't work. If the "1" is in
the model of a JACK process cycle, when does it actually get delivered
to the MIDI output port?
We'd love to provide this kind of functionality in Ardour, BTW, so if
you're serious about doing the research and work needed to check on
the HRT patch etc etc etc, we'd love to see it done in a way that we
could use too.
--p
12:46 p.m.
New subject: [linux-audio-dev] Utility for recording audio track with midi clock
[Paul Davis]
until the high resolution clock timers patch is solid
enough to be
used by any system, there is no way to schedule MIDI output with this
kind of resolution, and if you can't schedule it, then the receiver of
your MIDI clock signal will see a lot of jitter and may refuse to lock
to it. Even if it locks, its not clear what it will do with the jitter.
fwiw, i'm achieving quite satisfying results driving MIDI out from a
1024 Hz RTC thread, with external hardware locking steadily onto the
output MIDI clock stream, even at tempi up to 240 bpm.
MIDI out jitter is about the audio block size at max. DSP load (~1.3
ms) during audio processing cycles, a fraction of a millisecond for
the difference between 1024 Hz and the wanted MIDI clock frequency
otherwise; however this seems to be no problem for the hardware
attached (a fairly recent synthesizer and infrequently an aging cheap
drum machine).
at lower RTC frequencies, the jitter effect on the MIDI h/w becomes
noticeable (erratic rubato) but it still locks on.
thus, i must disagree with your 'no way'.
tim
1:10 p.m.
New subject: [linux-audio-dev] Utility for recording audio track with midi clock
fwiw, i'm achieving quite satisfying results
driving MIDI out from a
1024 Hz RTC thread, with external hardware locking steadily onto the
output MIDI clock stream, even at tempi up to 240 bpm.
OK, I guess i think about this too theoretically. I suppose that with
"reasonable" limits on the quarters-per-minute, the error in the
delivery time is relatively small. I tend to think in the abstract
about this, and it clearly fails for "absurd" tempo like 1300 bpm. At
240bpm, a 1ms error in the delivery time is only 10% of the
inter-message frequency, and I suppose that with a little
interpolation/smoothing by the receiver, that will work OK.
I guess I take back what I said, although it makes me uneasy :)
--p
3:06 p.m.
New subject: [linux-audio-dev] Utility for recording audio track with midi clock
On Thu, Jul 01, 2004 at 09:19:06AM -0400, Paul Davis wrote:
getting a general purpose computer to output MIDI
Clock (and/or MIDI
Time Code, just so nobody confuses the two of them) is a very hard
problem. There are 24 MIDI Clock messages per quarter note. This means
that for a piece in 4/4 at 120bpm, you need to output 1 MIDI byte
every 20ms. Not so bad - its a nice even multiplier of the system
interrupt frequency. However, just change the tempo or the time
signature, and all of a sudden you have situations where the MIDI
Clock byte needs to be output every 18ms or every 32ms or ever 9.7ms
or every 56.5ms.
This by itself is not the main problem. Using a 1000 Hz RTC to schedule
MIDI output as suggested by Tim, this requires something similar to the
Bresenham algorithm. Assuming there are no further random delays, the timing
jitter will be +/- 0.5 ms, or 0.29 ms RMS. A well designed receiver, using
an adaptive bandwidth PLL or an adaptive open loop algorithm, should be
able to estimate instantenuous tempo to within say a percent relative
error and be able to follow tempo changes up to say 5 Hz. (based on some
quicky calculations).
The real problem is probably that most Midi clock receivers are not designed
to tolerate too much jitter.
--
FA
2 Jul
2 Jul
3:54 a.m.
New subject: [linux-audio-dev] Utility for recording audio track with midi clock
On tor, 2004-07-01 at 18:56, Alfons Adriaensen wrote:
On Thu, Jul 01, 2004 at 09:19:06AM -0400, Paul Davis
wrote:
FWIW: My experience with external sequencers is that they'll output all
notes due up to the most recently received time, which is also what is
expected. Real People do flat steptime compositions and then later
manually add a slight ritadando (slowing down) close to the end.
I remember Roland had some device where you could adaptively tap the
tempo with your finger (or attach to the kickdrum), but this is
different from Midi clock.
Midi clock devices will never go further than the most recently received
clock. You are supposed to be able to conduct the tempo of your music in
realtime even to the point of a full stop.
SMPTE time would be the one to call for if you want to lock timing
between devices.
mvh // Jens M Andreasen
BTW: Outputting a single byte makes no sense. You can safely write (at
least) a full 3 byte message and let the hardware (or driver) take care
of buffering.
getting a general purpose computer to output MIDI
Clock (and/or MIDI
Time Code, just so nobody confuses the two of them) is a very hard
problem. There are 24 MIDI Clock messages per quarter note. This means
that for a piece in 4/4 at 120bpm, you need to output 1 MIDI byte
every 20ms. Not so bad - its a nice even multiplier of the system
interrupt frequency. However, just change the tempo or the time
signature, and all of a sudden you have situations where the MIDI
Clock byte needs to be output every 18ms or every 32ms or ever 9.7ms
or every 56.5ms.
This by itself is not the main problem. Using a 1000 Hz RTC to schedule
MIDI output as suggested by Tim, this requires something similar to the
Bresenham algorithm. Assuming there are no further random delays, the timing
jitter will be +/- 0.5 ms, or 0.29 ms RMS. A well designed receiver, using
an adaptive bandwidth PLL or an adaptive open loop algorithm, should be
able to estimate instantenuous tempo to within say a percent relative
error and be able to follow tempo changes up to say 5 Hz. (based on some
quicky calculations).
The real problem is probably that most Midi clock receivers are not designed
to tolerate too much jitter.
6:30 a.m.
New subject: [linux-audio-dev] Utility for recording audio track with midi clock
On Fri, Jul 02, 2004 at 07:48:29AM +0200, Jens M Andreasen wrote:
FWIW: My experience with external sequencers is that
they'll output all
notes due up to the most recently received time, which is also what is
expected.
IF that is all that's required then sending MIDI clock from a 1000 Hz RTC
should work perfectly. The added jitter of +/- 0.5 ms is less than the time
it takes to transmit a 3-note chord (2.24 ms, with running status) from
a keyboard (assuming someone can play that accurately).
But iff the receiver wants to compensate for the transmission delay, it
will need to have some idea of the 'current speed'.
--
FA
8:10 a.m.
New subject: [linux-audio-dev] Utility for recording audio track with midi clock
On fre, 2004-07-02 at 10:20, Alfons Adriaensen wrote:
On Fri, Jul 02, 2004 at 07:48:29AM +0200, Jens M
Andreasen wrote:
Midi time (the quarter note varaint) has no idea of "current speed".
Your sequencer probably shows a measure of BPM, but this is not
reflected anywhere in the protocol. Also, the time resolution is really
bad. You can't use it for jazzy realtime impressions where *exact*
timing matters (unless you pull up BPM well beyond 240, but then you'll
loose bandwith ...).
If you want to interpolate between clock events, then midi-smpte is the
only reliable route to go.
Keeping arpeggiators (etc) in sync with each other is better done with
midi-time though.
To clarify:
midi-time is your (somewhat whimsical?) conductor.
midi-smpte is the wall clock (on some wall.)
mvh // Jens M Andreasen
FWIW: My experience with external sequencers is
that they'll output all
notes due up to the most recently received time, which is also what is
expected.
IF that is all that's required then sending MIDI clock from a 1000 Hz RTC
should work perfectly. The added jitter of +/- 0.5 ms is less than the time
it takes to transmit a 3-note chord (2.24 ms, with running status) from
a keyboard (assuming someone can play that accurately).
But iff the receiver wants to compensate for the transmission delay, it
will need to have some idea of the 'current speed'.
7247
days inactive
7248
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
5 participants
participants (5)
-
Alfons Adriaensen -
Gerrit Niestijl -
Jens M Andreasen -
Paul Davis -
Tim Goetze