19 Feb
2010
19 Feb
'10
7:40 p.m.
for more information's read here.
http://en.wikipedia.org/wiki/MIDI_beat_clock
my question, exist something like this for alas. i am interested to send midi beat clock
signals from hydrogen to external hardware synthesisers/arpeggiators. and i am explicit
not interested to sync them to any timecode. because the external machines have to run
independent and in a randomly order. they only have to sync there beats.
here the mbc specs.
midi beat clock defines the following real time messages:
* clock (decimal 248, hex 0xF8)
* tick (decimal 249, hex 0xF9)
* start (decimal 250, hex 0xFA)
* continue (decimal 251, hex 0xFB)
* stop (decimal 252, hex 0xFC)
and about ticks.
i fond out that linux audio apps all have other or there own definitions about the
quantity of ticks per beat.
make it sense to find out an accordance about ticks per beat. or is this irrelevant for
any syncing. especially i mean here syncing via jack-transport.
greetings wolke
19 Feb
19 Feb
7:47 p.m.
On Sat, Feb 20, 2010 at 01:40:22AM +0100, m.wolkstein(a)gmx.de wrote:
my question, exist something like this for alsa.
For ALSA, I'm not sure. For JACK, the closest thing would be the transport
BBT information. You can just ignore the bar/beat numbers and look only at
the ticks if you prefer.
i fond out that linux audio apps all have other or
there own definitions
about the quantity of ticks per beat.
make it sense to find out an accordance about ticks per beat. or is this
irrelevant for any syncing. especially i mean here syncing via
jack-transport.
The timebase master decides the number of ticks per beat and broadcasts this
to the clients.
Arnout
8:34 p.m.
On Fri, Feb 19, 2010 at 7:40 PM, m.wolkstein(a)gmx.de <m.wolkstein(a)gmx.de> wrote:
i fond out that linux audio apps all have other or
there own definitions about the quantity of ticks per beat.
make it sense to find out an accordance about ticks per beat. or is this irrelevant for
any syncing. especially i mean here syncing via jack-transport.
its irrelevant for syncing.
MIDI clock defines itself via 24 messages per quarter note. this isn't
enough to provide true sync, because it does not convey the time
signature (meter) of the timeline. thus, to get real sync, both sides
(master & slave) must either be manually set to the same meter, or
they must use some other mechanism to share the meter.
if you make the default assumption, as so much stuff does these days,
that music normally comes in 4/4, then sync will generally work out of
the box. but on a piece in 5/8 or 9/4, let alone with a meter shift
somewhere in the middle, and more work is required.
--p
8:49 p.m.
On 02/20/2010 12:40 AM, m.wolkstein(a)gmx.de wrote:
for more information's read here.
http://en.wikipedia.org/wiki/MIDI_beat_clock
my question, exist something like this for alas. i am interested to send midi beat clock
signals from hydrogen to external hardware synthesisers/arpeggiators. and i am explicit
not interested to sync them to any timecode. because the external machines have to run
independent and in a randomly order. they only have to sync there beats.
here the mbc specs.
midi beat clock defines the following real time messages:
* clock (decimal 248, hex 0xF8)
* tick (decimal 249, hex 0xF9)
* start (decimal 250, hex 0xFA)
* continue (decimal 251, hex 0xFB)
* stop (decimal 252, hex 0xFC)
this is all about midi clock and song position pointer (spp) events.
question is: which devices, hw or sw, are there that sync to midi clock?
i'm afraid there's none.
but wait, there are some that respond to spp: ardour, qtractor,... maybe
many others ;)
and about ticks.
i fond out that linux audio apps all have other or there own definitions about the
quantity of ticks per beat.
make it sense to find out an accordance about ticks per beat. or is this irrelevant for
any syncing. especially i mean here syncing via jack-transport.
that's also called "midi resolution", usually expressed in
"ticks-per-beat" or "pulses/ticks-per-quarter-note" (ppqn/tpqn).
i have this dogma, and please have a note, that in midi realm, a "beat"
do translate to "quarter-note", "semiquaver", "seminima",
etc. no matter
which time signature you're into.
ppl holding strong or deeper music (tempo) theory should come forward now ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
9:09 p.m.
On February 19, 2010 07:51:58 pm Rui Nuno Capela wrote:
On 02/20/2010 12:40 AM, m.wolkstein(a)gmx.de wrote:
MusE-1 syncs to midi clock, and responds to start, stop, continue
and spp.
It also transmits them. It also recognizes tick but doesn't use it.
From what I understand, tick is nothing more than a periodic 'keep alive'
signal, not a sync signal. I could be wrong though...
for more information's read here.
http://en.wikipedia.org/wiki/MIDI_beat_clock
my question, exist something like this for alas. i am interested to send
midi beat clock signals from hydrogen to external hardware
synthesisers/arpeggiators. and i am explicit not interested to sync them
to any timecode. because the external machines have to run independent
and in a randomly order. they only have to sync there beats.
here the mbc specs.
midi beat clock defines the following real time messages:
* clock (decimal 248, hex 0xF8)
* tick (decimal 249, hex 0xF9)
* start (decimal 250, hex 0xFA)
* continue (decimal 251, hex 0xFB)
* stop (decimal 252, hex 0xFC)
this is all about midi clock and song position pointer (spp) events.
question is: which devices, hw or sw, are there that sync to midi clock?
i'm afraid there's none.
but wait, there are some that respond to spp: ardour, qtractor,... maybe
many others ;) and about ticks.
i fond out that linux audio apps all have other or there own definitions
about the quantity of ticks per beat. make it sense to find out an
accordance about ticks per beat. or is this irrelevant for any syncing.
especially i mean here syncing via jack-transport.
that's also called "midi resolution", usually expressed in
"ticks-per-beat" or "pulses/ticks-per-quarter-note" (ppqn/tpqn).
i have this dogma, and please have a note, that in midi realm, a "beat"
do translate to "quarter-note", "semiquaver", "seminima",
etc. no matter
which time signature you're into.
ppl holding strong or deeper music (tempo) theory should come forward now
;)
cheers
9:47 p.m.
On 02/20/2010 01:00 AM, Tim E. Real wrote:
On February 19, 2010 07:51:58 pm Rui Nuno Capela
wrote:
excellent
On 02/20/2010 12:40 AM, m.wolkstein(a)gmx.de
wrote:
MusE-1 syncs to midi clock, for more information's read here.
http://en.wikipedia.org/wiki/MIDI_beat_clock
my question, exist something like this for alas. i am interested to send
midi beat clock signals from hydrogen to external hardware
synthesisers/arpeggiators. and i am explicit not interested to sync them
to any timecode. because the external machines have to run independent
and in a randomly order. they only have to sync there beats.
here the mbc specs.
midi beat clock defines the following real time messages:
* clock (decimal 248, hex 0xF8)
* tick (decimal 249, hex 0xF9)
* start (decimal 250, hex 0xFA)
* continue (decimal 251, hex 0xFB)
* stop (decimal 252, hex 0xFC)
this is all about midi clock and song position pointer (spp) events.
question is: which devices, hw or sw, are there that sync to midi clock?
i'm afraid there's none.
but wait, there are some that respond to spp: ardour, qtractor,... maybe
many others ;) and responds to start, stop, continue and spp.
well, i've made the cardinal sin to put "start", "stop" and
"continue"
in the same bag as of "spp" ie. song position pointer. which all refer
to midi-clock aka midi-metronome time base, whatever
It also transmits them. It also recognizes tick but
doesn't use it.
From what I understand, tick is nothing more than a periodic 'keep alive'
signal, not a sync signal. I could be wrong though...
this "tick" signal (0xf9) must be (is it?) some leftover from ancient
midi times, if ever used effectively. i fail to recognize its use but
being just, uh,... _undesirable_ noise:)
i'll turn off
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
20 Feb
20 Feb
12:48 a.m.
On February 19, 2010 08:49:37 pm Rui Nuno Capela wrote:
On 02/20/2010 01:00 AM, Tim E. Real wrote:
Yes that's what I read, only a few
things use it. Roland being one I think...
On February 19, 2010 07:51:58 pm Rui Nuno Capela
wrote:
excellent
On 02/20/2010 12:40 AM, m.wolkstein(a)gmx.de
wrote:
MusE-1 syncs to midi clock, for more information's read here.
http://en.wikipedia.org/wiki/MIDI_beat_clock
my question, exist something like this for alas. i am interested to
send midi beat clock signals from hydrogen to external hardware
synthesisers/arpeggiators. and i am explicit not interested to sync
them to any timecode. because the external machines have to run
independent and in a randomly order. they only have to sync there
beats.
here the mbc specs.
midi beat clock defines the following real time messages:
* clock (decimal 248, hex 0xF8)
* tick (decimal 249, hex 0xF9)
* start (decimal 250, hex 0xFA)
* continue (decimal 251, hex 0xFB)
* stop (decimal 252, hex 0xFC)
this is all about midi clock and song position pointer (spp) events.
question is: which devices, hw or sw, are there that sync to midi clock?
i'm afraid there's none.
but wait, there are some that respond to spp: ardour, qtractor,... maybe
many others ;) and responds to start, stop, continue and spp.
well, i've made the cardinal sin to put "start", "stop" and
"continue"
in the same bag as of "spp" ie. song position pointer. which all refer
to midi-clock aka midi-metronome time base, whatever
It also transmits them. It also recognizes tick
but doesn't use it.
From what I understand, tick is nothing more than a periodic 'keep alive'
signal, not a sync signal. I could be wrong though...
this "tick" signal (0xf9) must be (is it?) some leftover from ancient
midi times, if ever used effectively. i fail to recognize its use but
being just, uh,... _undesirable_ noise:)
i'll turn off
If you have something that uses it and want to see if it's
working
open MusE (best is SVN) and check out the sync window.
Blinky lights galore...
Which app is it? Like to see If it works 'cause I've never encountered the
message !
Tim.
7:14 a.m.
hi, thx to all. i learn something more.
in my case i was only interested on midi clock. but now i plan to make a flexible
standard
implementation in this way.
hydrogen will support midi clock as slave and master.
as slave hydrogen receives:
midi clock (0xF8) 24midi clocks in every quarter note,
midi start (0xFA),
midi stop (0xFC),
midi continue (0xFB),
to snap to songpositions if status is stop h2 get position informations via song position
pointer(spp) (0xF2).
as master, hydrogen sends information in the way it receive the information's.
if internal sequencer is stopped hydrogen sends spp.
if people arrange songs with complexer beats than 4/4, all involved sequencers have to
know the timeline.
e.g 3/4|4/4|3/4|7/8| and so on.
i think user interface can looks like this.
status led blinks in quarter notes. red as master, green as slave.
for humans the led can blink yellow or what ever on each first quarter into a bar.
two check-boxes or buttons switch all conditions.
button one can toggle the whole midi clock on/off.
button two switch between master/slave.
more words over syncing the playback you can find here.
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec.htm
i will use this specs as reference.
greetings wolke
11:43 a.m.
On Sat, Feb 20, 2010 at 01:14:37PM +0100, m.wolkstein(a)gmx.de wrote:
in my case i was only interested on midi clock. but
now i plan to make a flexible standard
implementation in this way.
hydrogen will support midi clock as slave and master.
as slave hydrogen receives:
midi clock (0xF8) 24midi clocks in every quarter note,
midi start (0xFA),
midi stop (0xFC),
midi continue (0xFB),
to snap to songpositions if status is stop h2 get position informations via song
position
pointer(spp) (0xF2).
Hydrogen is already a JACK Timebase Master and Slave. However, a quick glance
suggests it does not emit BBT information when acting as a Master, and does not
understand it when acting as a slave - i might be running a slightly outdated
version though.
If Hydrogen could be extended to produce (should be doable) and understand
(harder, but should be doable) JACK BBT information, the MIDI stuff could be
implemented as a separate JACK application that is not directly tied to
hydrogen.
Looks like Gabriel's http://www.teuton.org/~gabriel/jack_midi_clock/ already
implements one side of such a bridge.
Such a solution would certainly be more complex, but also more flexible
compared to building this into hydrogen completely.
Arnout
12:03 p.m.
Arnout Engelen wrote:
On Sat, Feb 20, 2010 at 01:14:37PM +0100,
m.wolkstein(a)gmx.de wrote:
As a user with lots of MIDI equipment from the 80ies, I would prefer a
separated JACK application doing this. It's not only for Linux, but for
all computers and stand alone equipment that MIDI sync among some
combinations of applications and/or hardware is ok, while it isn't ok
among other combinations, e.g because of master and slave issues and
sometimes just because of voodoo.
If Linux apps would use JACK transport the coders only would have to
take care to handle this. Just having on app doing sync among JACK and
eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
of such an app too ... I didn't read the whole thread, perhaps this was
mentioned before.
Just a note by an user, becuase of "the MIDI stuff could be implemented
as a separate JACK application": Full ACK.
hydrogen will support midi clock as slave and
master.
as slave hydrogen receives:
midi clock (0xF8) 24midi clocks in every quarter note,
midi start (0xFA),
midi stop (0xFC),
midi continue (0xFB),
to snap to songpositions if status is stop h2 get position informations via song
position
pointer(spp) (0xF2).
the MIDI stuff could be implemented as a separate JACK application
2:19 p.m.
On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
If Linux apps would use JACK transport the coders only
would have to
take care to handle this. Just having on app doing sync among JACK and
eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
of such an app too ... I didn't read the whole thread, perhaps this was
mentioned before.
this isn't true.
one of the most deliberate and conspicuous design decisions of the
JACK transport API is that there is no support for varispeed.
sync requires knowing two things: where we are, and how fast we are
going. JACK transport has only 2 answers the the second question
(stopped, rolling). this isn't adequate to fully capture the notion of
sync.
3:36 p.m.
Paul Davis wrote:
On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
My bad, I made this error in reasoning once before. Now I do remember.
If Linux apps would use JACK transport the coders
only would have to
take care to handle this. Just having on app doing sync among JACK and
eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
of such an app too ... I didn't read the whole thread, perhaps this was
mentioned before.
this isn't true.
one of the most deliberate and conspicuous design decisions of the
JACK transport API is that there is no support for varispeed.
sync requires knowing two things: where we are, and how fast we are
going. JACK transport has only 2 answers the the second question
(stopped, rolling). this isn't adequate to fully capture the notion of
sync.
3:48 p.m.
On February 20, 2010 01:19:52 pm Paul Davis wrote:
On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
MTC: Maybe veering OT a bit but if we could just touch on this for a moment.
Was going to ask about this anyway, as we had talked about it a bit.
I thought "it's too bad we can't adjust Jack's sample rate on the
fly"
thus allowing Jack to behave like a Voltage Controlled Oscillator in a PLL,
syncing to MTC frame.
I was thinking the VCO 'control' signal would come from a client.
Else Jack itself would have to support MTC.
But raises the question - which Jack back-ends allow dynamic sample rate
changes? And with a finite resolution small enough?
I concluded that the best way for me to sync Jack audio with an
external MTC is with app-side audio time stretchers.
Tim.
If Linux apps would use JACK transport the coders
only would have to
take care to handle this. Just having on app doing sync among JACK and
eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
of such an app too ... I didn't read the whole thread, perhaps this was
mentioned before.
this isn't true.
one of the most deliberate and conspicuous design decisions of the
JACK transport API is that there is no support for varispeed.
sync requires knowing two things: where we are, and how fast we are
going. JACK transport has only 2 answers the the second question
(stopped, rolling). this isn't adequate to fully capture the notion of
sync.
3:56 p.m.
Tim E. Real wrote:
On February 20, 2010 01:19:52 pm Paul Davis wrote:
Hm, perhaps apps with audio tracks always should be master, to avoid
resampling. If it would be possible to make the software clear, that
somebody just is using a MIDI sequencer, without audio tracks, than
there should be the possibility to be MTC slave too.
I'm not a coder, but I guess that the resampling issue won't be solved soon.
On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
MTC: Maybe veering OT a bit but if we could just touch on this for a moment.
Was going to ask about this anyway, as we had talked about it a bit.
I thought "it's too bad we can't adjust Jack's sample rate on the
fly"
thus allowing Jack to behave like a Voltage Controlled Oscillator in a PLL,
syncing to MTC frame.
I was thinking the VCO 'control' signal would come from a client.
Else Jack itself would have to support MTC.
But raises the question - which Jack back-ends allow dynamic sample rate
changes? And with a finite resolution small enough?
I concluded that the best way for me to sync Jack audio with an
external MTC is with app-side audio time stretchers.
Tim. If Linux apps would use JACK transport the coders
only would have to
take care to handle this. Just having on app doing sync among JACK and
eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
of such an app too ... I didn't read the whole thread, perhaps this was
mentioned before.
this isn't true.
one of the most deliberate and conspicuous design decisions of the
JACK transport API is that there is no support for varispeed.
sync requires knowing two things: where we are, and how fast we are
going. JACK transport has only 2 answers the the second question
(stopped, rolling). this isn't adequate to fully capture the notion of
sync.
4:07 p.m.
On February 20, 2010 02:56:15 pm you wrote:
Tim E. Real wrote:
I also concluded that with MTC, since it is purely frame-based, it is up to
the slave apps to translate that into BBT for midi engines.
Thus *requiring* local tempo/signature maps be in use.
Well, that is until we get that shared tempo map thing happening...
Stretchers are playing a very important role in my designs now.
Even just using tempo maps requires them with audio tracks, if the
user wants to change a tempo AFTER recording an audio track.
Tim.
On February 20, 2010 01:19:52 pm Paul Davis
wrote:
Hm, perhaps apps with audio tracks always should be master, to avoid
resampling. If it would be possible to make the software clear, that
somebody just is using a MIDI sequencer, without audio tracks, than
there should be the possibility to be MTC slave too.
I'm not a coder, but I guess that the resampling issue won't be solved
soon. On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
MTC: Maybe veering OT a bit but if we could just touch on this for a
moment. Was going to ask about this anyway, as we had talked about it a
bit.
I thought "it's too bad we can't adjust Jack's sample rate on the
fly"
thus allowing Jack to behave like a Voltage Controlled Oscillator in a
PLL, syncing to MTC frame.
I was thinking the VCO 'control' signal would come from a client.
Else Jack itself would have to support MTC.
But raises the question - which Jack back-ends allow dynamic sample rate
changes? And with a finite resolution small enough?
I concluded that the best way for me to sync Jack audio with an
external MTC is with app-side audio time stretchers.
Tim. If Linux apps would use JACK transport the coders
only would have to
take care to handle this. Just having on app doing sync among JACK and
eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
of such an app too ... I didn't read the whole thread, perhaps this was
mentioned before.
this isn't true.
one of the most deliberate and conspicuous design decisions of the
JACK transport API is that there is no support for varispeed.
sync requires knowing two things: where we are, and how fast we are
going. JACK transport has only 2 answers the the second question
(stopped, rolling). this isn't adequate to fully capture the notion of
sync. 
5:28 p.m.
On 02/20/2010 08:57 PM, Tim E. Real wrote:
Stretchers are playing a very important role in my
designs now.
Even just using tempo maps requires them with audio tracks, if the
user wants to change a tempo AFTER recording an audio track.
frankly, i haven't heard any stretchers that weren't totally abysmal. it
probably depends on what you do (single instrument tracks can work
ok'ish), but for anything like an ambience microphone, stretching is not
an option (and won't be, for the forseeable future).
i really doubt it's worth all that work...
5:38 p.m.
On February 20, 2010 04:30:56 pm Jörn Nettingsmeier wrote:
On 02/20/2010 08:57 PM, Tim E. Real wrote:
Sorry forgot Zita was only resampling. I still want Zita as resampler.
Got SRC already.
Stretchers are playing a very important role in
my designs now.
Even just using tempo maps requires them with audio tracks, if the
user wants to change a tempo AFTER recording an audio track.
frankly, i haven't heard any stretchers that weren't totally abysmal. it
probably depends on what you do (single instrument tracks can work
ok'ish), but for anything like an ambience microphone, stretching is not
an option (and won't be, for the forseeable future).
i really doubt it's worth all that work...
If you mean stretching, darn, I hope not. I mean I hope so. It seems fun.
But resampling I do need. Beats hand-resampling all my tracks in another app
and saves space.
5:32 p.m.
On February 20, 2010 02:38:19 pm Tim E. Real wrote:
On February 20, 2010 01:19:52 pm Paul Davis wrote:
I forgot to add that if one
is faced with external MTC (or any frame-based
sync signal) then it should really be fed (somehow) into the sound card
as a sync signal, shouldn't it? Everything supports SPDIF, but MTC?
Then sound card + Jack + apps are happy, as they all run off it.
And using MTC to send sync between apps just seems odd, as they're
using Jack already, for audio.
On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
MTC: Maybe veering OT a bit but if we could just touch on this for a
moment. Was going to ask about this anyway, as we had talked about it a
bit.
I thought "it's too bad we can't adjust Jack's sample rate on the
fly"
thus allowing Jack to behave like a Voltage Controlled Oscillator in a
PLL, syncing to MTC frame.
I was thinking the VCO 'control' signal would come from a client.
Else Jack itself would have to support MTC.
But raises the question - which Jack back-ends allow dynamic sample rate
changes? And with a finite resolution small enough?
I concluded that the best way for me to sync Jack audio with an
external MTC is with app-side audio time stretchers. If Linux apps would use JACK transport the coders
only would have to
take care to handle this. Just having on app doing sync among JACK and
eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
of such an app too ... I didn't read the whole thread, perhaps this was
mentioned before.
this isn't true.
one of the most deliberate and conspicuous design decisions of the
JACK transport API is that there is no support for varispeed.
sync requires knowing two things: where we are, and how fast we are
going. JACK transport has only 2 answers the the second question
(stopped, rolling). this isn't adequate to fully capture the notion of
sync.
5:34 p.m.
On Sat, Feb 20, 2010 at 4:22 PM, Tim E. Real <termtech(a)rogers.com> wrote:
> I thought "it's too bad we can't
adjust Jack's sample rate on the fly"
> thus allowing Jack to behave like a Voltage Controlled Oscillator in a
> PLL, syncing to MTC frame.
> I was thinking the VCO 'control' signal would come from a client.
> Else Jack itself would have to support MTC.
>
> But raises the question - which Jack back-ends allow dynamic sample rate
> changes? And with a finite resolution small enough?
none. and AFAIK, only RME hardware allows true varispeed via the sample clock.
5:54 p.m.
On February 20, 2010 04:34:29 pm you wrote:
On Sat, Feb 20, 2010 at 4:22 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
(Hope the original poster still finds this sync stuff useful...)
Paul does true varispeed mean fully locked all the time, not wavering up and
down to compensate for quantization in the sample rate values?
Once, I observed this wavering effect as a 'swishing' effect in SBLive cards
when mixing an original signal with the output.
This was done at 44100Hz to turn on SBLive's (notorious?) always-on
conversions to 48000Hz.
> I thought "it's too bad we can't
adjust Jack's sample rate on the fly"
> thus allowing Jack to behave like a Voltage Controlled Oscillator in a
> PLL, syncing to MTC frame.
> I was thinking the VCO 'control' signal would come from a client.
> Else Jack itself would have to support MTC.
>
> But raises the question - which Jack back-ends allow dynamic sample rate
> changes? And with a finite resolution small enough?
none. and AFAIK, only RME hardware allows true varispeed via the sample
clock.
16 Mar
16 Mar
11:27 p.m.
Am Sat, 20 Feb 2010 13:14:37 +0100
schrieb "m.wolkstein(a)gmx.de" <m.wolkstein(a)gmx.de>de>:
hi, thx to all. i learn something more.
in my case i was only interested on midi clock. but now i plan to make a flexible
standard implementation in this way.
hydrogen will support midi clock as slave and master.
as slave hydrogen receives:
midi clock (0xF8) 24midi clocks in every quarter note,
midi start (0xFA),
midi stop (0xFC),
midi continue (0xFB),
to snap to songpositions if status is stop h2 get position informations via song
position pointer(spp) (0xF2).
as master, hydrogen sends information in the way it receive the information's.
if internal sequencer is stopped hydrogen sends spp.
if people arrange songs with complexer beats than 4/4, all involved sequencers have to
know the timeline. e.g 3/4|4/4|3/4|7/8| and so on.
i think user interface can looks like this.
status led blinks in quarter notes. red as master, green as slave.
for humans the led can blink yellow or what ever on each first quarter into a bar.
two check-boxes or buttons switch all conditions.
button one can toggle the whole midi clock on/off.
button two switch between master/slave.
more words over syncing the playback you can find here.
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec.htm
i will use this specs as reference.
greetings wolke
hi,
i have made a hydrogen send/receive midi-clock, start/stop and spp implementation.
at first only for alsa.
i test the spp and midi clock functionality mostly with renoise.
this happens because i dont' know how muse, rosegarden and qtractor will send midi
clock :/.
the renoise settings are simple to understand for me. at least to get all things working
as espected.
known problems:
1. send spp do sometimes strange things. mostly if the hydrogen patten size is > 16.
2. the preferences midi clock slider to adjust tempo violations/drifts on midi targets
have to adjust on first start. this is because the the hydrogen.conf becomes new
nodes.
this is obsolete if you install this version of hydrogen by using scons install. than
the new default.hydrogen.conf will also installed.
if not you can edit the hydrogen.conf and include this lines.
already existing lines:
<hearNewNotes>true</hearNewNotes>
<quantizeEvents>true</quantizeEvents>
-----8<------
new lines:
<receiveMidiClock>false</receiveMidiClock>
<sendMidiClock>false</sendMidiClock>
<midiClockCompensationValue>22000</midiClockCompensationValue>
<receiveSpp>false</receiveSpp>
<sendSpp>false</sendSpp>
<receiveMidiStartStop>false</receiveMidiStartStop>
<sendMidiStartStop>true</sendMidiStartStop>
-----8<-------
here is a screen shot from the new hydrogen midi sync settings-tab.
http://popez.org/~wolke/hydrogen/images/prefdialogsync.png
if somebody is interested to test the feature, please checkout the midiclock_spp branche.
http://svn.assembla.com/svn/hydrogen/branches/midiclock_spp
greetings wolke
20 Feb
20 Feb
12:33 p.m.
Rui Nuno Capela wrote:
0xf9 - "MIDI Tick" is a fixed and real sync signal, sync independently
from the tempo, the "keep alive" signal is 0xfe - "Active Sense", very
useful for a master keyboard during a live performance, assumed
receiving devices do know what to do, if "active sense" unexpected would
stay away.
It also
transmits them. It also recognizes tick but doesn't use it.
From what I understand, tick is nothing more than a periodic 'keep alive'
signal, not a sync signal. I could be wrong though...
this "tick" signal (0xf9) must be (is it?) some leftover from ancient
midi times, if ever used effectively. i fail to recognize its use but
being just, uh,... _undesirable_ noise:)
i'll turn off
2:47 p.m.
On February 20, 2010 11:33:04 am Ralf Mardorf wrote:
Rui Nuno Capela wrote:
0xf9 - "MIDI Tick" is a fixed and real sync signal, sync independently
from the tempo, the "keep alive" signal is 0xfe - "Active Sense",
very
useful for a master keyboard during a live performance, assumed
receiving devices do know what to do, if "active sense" unexpected would
stay away.
Oops. My mistake. Mixing up signals again.
Tim.
It also
transmits them. It also recognizes tick but doesn't use it.
From what I understand, tick is nothing more than a periodic 'keep
alive' signal, not a sync signal. I could be wrong though...
this "tick" signal (0xf9) must be (is it?) some leftover from ancient
midi times, if ever used effectively. i fail to recognize its use but
being just, uh,... _undesirable_ noise:)
i'll turn off
3:36 p.m.
Tim E. Real wrote:
On February 20, 2010 11:33:04 am Ralf Mardorf wrote:
I didn't know MIDI tick before, but I wondered that Rui was talking
about noise, while you were talking about active sense. It makes me
wonder, because active sense should be send every 300ms, but it also
would be okay after active sense was send for the first time, that there
is any signal within a second, e.g. active sense every 800ms instead of
every 300ms, so this won't be a problem. I need to read about MIDI tick
and yes, it has to be send exactly every 10ms. 100 times a second is
more traffic :D. MIDI tick seems to be something relative new for MIDI,
Pedro mentioned this before.
Rui Nuno Capela wrote:
0xf9 - "MIDI Tick" is a fixed and real sync signal, sync
independently
from the tempo, the "keep alive" signal is 0xfe - "Active Sense",
very
useful for a master keyboard during a live performance, assumed
receiving devices do know what to do, if "active sense" unexpected would
stay away.
Oops. My mistake. Mixing up signals again.
Tim. It also
transmits them. It also recognizes tick but doesn't use it.
From what I understand, tick is nothing more than a periodic 'keep
alive' signal, not a sync signal. I could be wrong though...
this "tick" signal (0xf9) must be (is it?) some leftover from
ancient
midi times, if ever used effectively. i fail to recognize its use but
being just, uh,... _undesirable_ noise:)
i'll turn off
2:09 p.m.
On Saturday, February 20, 2010, Rui Nuno Capela wrote:
0xf9 is Undefined (Reserved), according to:
http://www.midi.org/techspecs/midimessages.php
Or the MIDI specification 1.0, which is embedded in many books, like this one:
http://books.google.com/books?id=S-T6a9OXwGQC&lpg=PA236&pg=PA234#v=…
The "keep alive" message is 0xfe (dec. 254) Active Sensing. And by the way,
here is another mirror of the Jeff Glatt's MIDI docs:
http://home.roadrunner.com/~jgglatt/
It is an useful site, because the official MIDI specification is not published
online my midi.org, but it is not an official source. I would like to know
the origin of this "tick" 0xf9 message. Is it an addition from some
manufacturer?
Regards,
Pedro
On 02/20/2010 01:00 AM, Tim E. Real wrote:
> On February 19, 2010 07:51:58 pm Rui Nuno Capela wrote:
>> On 02/20/2010 12:40 AM, m.wolkstein(a)gmx.de wrote:
>>> here the mbc specs.
>>> midi beat clock defines the following real time messages:
>>> * clock (decimal 248, hex 0xF8)
>>> * tick (decimal 249, hex 0xF9)
[...]
It also
transmits them. It also recognizes tick but doesn't use it.
From what I understand, tick is nothing more than a periodic 'keep alive'
signal, not a sync signal. I could be wrong though...
this "tick" signal (0xf9) must be (is it?) some leftover from ancient
midi times, if ever used effectively. i fail to recognize its use but
being just, uh,... _undesirable_ noise:)
i'll turn off 
4:21 p.m.
On Sat, 20 Feb 2010, Pedro Lopez-Cabanillas wrote:
> this "tick" signal (0xf9) must be (is
it?) some leftover from ancient
> midi times, if ever used effectively. i fail to recognize its use but
> being just, uh,... _undesirable_ noise:)
[snip]
0xf9 is Undefined (Reserved), according to:
http://www.midi.org/techspecs/midimessages.php
[snip]
It is an useful site, because the official MIDI specification is not published
online my midi.org, but it is not an official source. I would like to know
the origin of this "tick" 0xf9 message. Is it an addition from some
manufacturer?
Good point, Pedro. I think your right, it smalls like a
vendor extension. FWIW, elsewhere on the same site 0xF9 is
also marked as unused.
-gabriel
4:59 p.m.
Gabriel M. Beddingfield wrote:
On Sat, 20 Feb 2010, Pedro Lopez-Cabanillas wrote:
Probably it was established ex 1989 or 1990?
On midi.org they also say
"Active Sensing. Use of this message is optional. When initially sent,
the receiver will expect to receive another Active Sensing message each
300ms (max), or it will be assume that the connection has been
terminated. At termination, the receiver will turn off all voices and
return to normal (non- active sensing) operation."
But e.g for this I do have the information, that there isn't the need to
send active sensing each 300ms. I guess there are unofficial agreements.
I found a side on German. Hehe, for active sensing it differs because of
my claim, I was a little bit more interpreting, but anyway it also
differs to midi.org. Because of the topic, MIDI tick on that side is
included and not undefined, resp. it isn't free for any other usage.
http://www.sequencer.de/synth/index.php/MIDI_Format#0xf9_-_MIDI_Tick
I never had a device understanding MIDI tick, somebody on that list has
written that he knows a Roland, perhaps Roland is the vendor
establishing it.
Hm, search engines aren't a help, there is just information about MIDI
tick, e.g.
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec/tick.htm,
or if e.g. searching for Roland devices, they are talking about "tick"
for the sequencer resolution, but not because of this.
I never heard of MIDI tick before and I'm nearly sure that there is no
usual MIDI device from the 80ies were it's implemented.
So if you like to figure out the origin of MIDI tick, you should start
with research ex 1990 or at the end of the 80ies.
> this "tick" signal (0xf9) must be
(is it?) some leftover from ancient
> midi times, if ever used effectively. i fail to recognize its use but
> being just, uh,... _undesirable_ noise:)
>
[snip]
0xf9 is Undefined (Reserved), according to:
http://www.midi.org/techspecs/midimessages.php
[snip]
It is an useful site, because the official MIDI
specification is not published
online my midi.org, but it is not an official source. I would like to know
the origin of this "tick" 0xf9 message. Is it an addition from some
manufacturer?
Good point, Pedro. I think your right, it smalls like a
vendor extension. FWIW, elsewhere on the same site 0xF9 is
also marked as unused.
-gabriel
19 Feb
19 Feb
11:17 p.m.
Hi wolke!
On Sat, 20 Feb 2010, m.wolkstein(a)gmx.de wrote:
for more information's read here.
http://en.wikipedia.org/wiki/MIDI_beat_clock
my question, exist something like this for alas. i am interested to send midi beat clock
signals from hydrogen to external hardware synthesisers/arpeggiators. and i am explicit
not interested to sync them to any timecode. because the external machines have to run
independent and in a randomly order. they only have to sync there beats.
I wrote a program to do this. It slaves to the JACK
transport and sends out MIDI clock pulses accordingly. You
can check it out here:
http://www.teuton.org/~gabriel/jack_midi_clock/
I've used this to record with Ardour and a Korg MS2000R.
The MS2000R is able to sync arpeggiators and LFO's to MIDI
clock pulses. It ignores start/stop/continue messages.
However, jack_midi_clock still implements those. It does
/not/ implement MIDI Tick (but it could...).
and about ticks.
i fond out that linux audio apps all have other or there own definitions about the
quantity of ticks per beat.
make it sense to find out an accordance about ticks per beat. or is this irrelevant for
any syncing. especially i mean here syncing via jack-transport.
As PD said, the MIDI spec requires That MIDI Clock (0xF8)
pulses be sent out at a rate of 24 clocks per quarter note.
Meanwhile, a MIDI Tick (0xF9) is sent out at a rate of 1
tick per 10 ms. The difference is whether you are syncing
time or tempo. Sounds like you want tempo (MIDI Clock
0xF8).
There's a pretty good MIDI reference here:
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec.htm
http://www.blitter.com/~russtopia/MIDI/~jglatt/
FWIW, using MIDI clock you can effectively sync tempo.
Synchronizing down-beats is more difficult... since there is
never a signal that says "this clock pulse marks a beat."
Hope this helps!
-gabriel
21 Feb
21 Feb
9:29 p.m.
On February 19, 2010 10:17:12 pm Gabriel M. Beddingfield wrote:
As PD said, the MIDI spec requires That MIDI Clock
(0xF8)
pulses be sent out at a rate of 24 clocks per quarter note.
Meanwhile, a MIDI Tick (0xF9) is sent out at a rate of 1
tick per 10 ms. The difference is whether you are syncing
time or tempo. Sounds like you want tempo (MIDI Clock
0xF8).
There's a pretty good MIDI reference here:
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec.htm
http://www.blitter.com/~russtopia/MIDI/~jglatt/
FWIW, using MIDI clock you can effectively sync tempo.
Synchronizing down-beats is more difficult... since there is
never a signal that says "this clock pulse marks a beat."
Hope this helps!
-gabriel
Good stuff. Thanks. Had no idea that 100Hz tick was for time-based sync.
Meaning we could use it for audio...
Interesting, MTC full frames are 12Hz (@ 24fps) and quarter frames @ 96Hz.
(Correct my rusty reviewing).
But Paul said that it can be 'quite bursty', I assume he meant the
quarter frames - and I think I also read one should not trust the full frame
to occur precisely 'where it should be'. After all, it is a sysex...
So I Wonder if 'tick' is a more stable, straight forward, and faster option
for basic uses vs MTC@24fps
Still curious, someone said he had this 'tick', which app sends it?
Imagine. Midi clock, active sense, tick and/or MTC all on the same line...
22 Feb
22 Feb
3:33 p.m.
Paul Davis wrote:
On Sun, Feb 21, 2010 at 8:19 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
And
Midi clock + song position pointer is useful
or
MTC without Midi clock and without song position pointer is useful.
It's still unclear if there are enough devices using MIDI tick, I don't
know any.
I don't think you'll use all kinds of sync at the same time and in
general it's a good idea to use several MIDI IOs, e.g. to use SysEx on
real-time.
Anyway, using pitch bend also causes a lot of traffic and there will be
no trouble because of this. You shouldn't fear too much traffic, MIDI
isn't that slow.
Imagine. Midi clock, active sense, tick and/or
MTC all on the same line...
the MMA specs recommend a separate MIDI cable for MTC.
3:36 p.m.
Tim E. Real wrote:
On February 19, 2010 10:17:12 pm Gabriel M.
Beddingfield wrote:
There must be a misunderstanding. IIRC Paul said that MIDI clock can
become an issue.
I was using SMPTE for a long time and it's absolutely usable for every
sync situation. I guess that MTC is equivalent to SMPTE.
As PD said, the MIDI spec requires That MIDI
Clock (0xF8)
pulses be sent out at a rate of 24 clocks per quarter note.
Meanwhile, a MIDI Tick (0xF9) is sent out at a rate of 1
tick per 10 ms. The difference is whether you are syncing
time or tempo. Sounds like you want tempo (MIDI Clock
0xF8).
There's a pretty good MIDI reference here:
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec.htm
http://www.blitter.com/~russtopia/MIDI/~jglatt/
FWIW, using MIDI clock you can effectively sync tempo.
Synchronizing down-beats is more difficult... since there is
never a signal that says "this clock pulse marks a beat."
Hope this helps!
-gabriel
Good stuff. Thanks. Had no idea that 100Hz tick was for time-based sync.
Meaning we could use it for audio...
Interesting, MTC full frames are 12Hz (@ 24fps) and quarter frames @ 96Hz.
(Correct my rusty reviewing).
But Paul said that it can be 'quite bursty', I assume he meant the
quarter frames - and I think I also read one should not trust the full frame
to occur precisely 'where it should be'. After all, it is a sysex...
So I Wonder if 'tick' is a more stable, straight forward, and faster option
for basic uses vs MTC@24fps
Still curious, someone said he had this 'tick', which app sends it?
Imagine. Midi clock, active sense, tick and/or MTC all on the same line...
5154
days inactive
5179
days old
linux-audio-dev@lists.linuxaudio.org
34 comments
9 participants
participants (9)
-
Arnout Engelen -
Gabriel M. Beddingfield -
Jörn Nettingsmeier -
m.wolkstein＠gmx.de -
Paul Davis -
Pedro Lopez-Cabanillas -
Ralf Mardorf -
Rui Nuno Capela -
Tim E. Real