29 May
2009
29 May
'09
3:50 p.m.
Hi
Long story short: I'm writing a osc2midi_clock script in chuck for
controlling sooperlooper from incomming osc messages. I have no
experience with midi clock so I had to play around with it. The
following seems to work (T for time messges (0xf8), S for start (0xfa),
x23 means "repeat 23 times"):
S Tx23 S Tx23 S etc.
It even works to the point that I can throw in clients at any time,
since the start messages resets the clock every quarter note. The two
clients I checked with are sooperlooper and renoise.
*However* the specifications I looked at are:
http://www.harmony-central.com/MIDI/Doc/table4.html
http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec/seq.htm
They both suggests that it should actually be
S Tx24 S Tx24 S etc, with little or no time between S and the following T.
However here the clients (again sooperlooper and renoise) doesn't show
the test tempo 112 but somewhere between 116 and 117.
Anyone has any idea what the right way?
Also; I've been discussing this with Jesse Chappell (author of
sooperlooper) and he says that he looked at his code and thinks there's
a bug (which makes it work correctly with my wrong midi clock, since
that's actually written targetting sooperlooper). Now it would be very
interresting to look at other clients and masters of midi clock, however
not having worked with midi clock before, what would be the first
clients to cross check with?
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
29 May
29 May
4:31 p.m.
On Fri, May 29, 2009 12:50 pm, Atte André Jensen wrote:
Hi
Long story short: I'm writing a osc2midi_clock script in chuck for
controlling sooperlooper from incomming osc messages. I have no
experience with midi clock so I had to play around with it. The
following seems to work (T for time messges (0xf8), S for start (0xfa),
x23 means "repeat 23 times"):
S Tx23 S Tx23 S etc.
It even works to the point that I can throw in clients at any time,
since the start messages resets the clock every quarter note. The two
clients I checked with are sooperlooper and renoise.
I think all the extra 'S' messages aren't necc. Start and Stop are
supposed to be transport controls, not synchronization messages. Also,
Start is not a substitute for a clock pulse. The start message means
"start on the next clock pulse (T)."
So, I think the MIDI creators intended this:
S Stop
T T T T T T T T .....
It presumes that none of the T's will be dropped and that everyone is
working off the same score. But, for your purposes, you might try the S
Tx24 like this:
S S S
T T T T .... T T T T .... T T T T
That is, your T's happen at the right time, and the synchronization
attempt with 'S' would precede the synchronization T pulse.
I have a hardware synth that's constantly sending out the T, but never
sends S.
HTH,
Gabriel
--
G a b r i e l M B e d d i n g f i e l d
5:33 p.m.
Gabriel M. Beddingfield wrote:
So, I think the MIDI creators intended this:
S Stop
T T T T T T T T .....
I think so too...
It presumes that none of the T's will be dropped
and that everyone is
working off the same score. But, for your purposes, you might try the S
Tx24 like this:
S S S
T T T T .... T T T T .... T T T T
That is, your T's happen at the right time, and the synchronization
attempt with 'S' would precede the synchronization T pulse.
As mentioned the two clients I test against misbehaves with this,
running at 116-117 bpm instead of 112.
I have a hardware synth that's constantly sending
out the T, but never
sends S.
Same with seq24 and ardour (although ardour seems to sending "midi time
code".
Note the following is not to bash ardour, just a simple observation. As
stated I know nothing about midi clock I'm just fooling around!
I tried syncing renoise with ardour and that didn't work out that well
(ardour master to compare with when my script was master). They seem to
stay in sync, but they have the downbeat different places. After
stop/start the downbeats are messed up in a new way.
Maybe it's all just a shitty old protocol that is finally being replaced
by stuff like jack transport (that works very reliable, actually
precisely between renoise and ardour).
Maybe I should stop thinking so much and just hack away something that
works for exactly my purpose (I only need to sync with sooperlooper),
however wrong (according to the standard) it is.
Still, I'd be interrested in any input, though...
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
30 May
30 May
11:03 a.m.
On Fri, May 29, 2009 at 3:33 PM, Atte André Jensen
<atte.jensen(a)gmail.com> wrote:
I tried syncing renoise with ardour and that
didn't work out that well
(ardour master to compare with when my script was master). They seem to
stay in sync, but they have the downbeat different places. After
stop/start the downbeats are messed up in a new way.
Maybe it's all just a shitty old protocol that is finally being replaced
by stuff like jack transport (that works very reliable, actually
precisely between renoise and ardour).
Maybe I should stop thinking so much and just hack away something that
works for exactly my purpose (I only need to sync with sooperlooper),
however wrong (according to the standard) it is.
Still, I'd be interrested in any input, though...
Don't all 3 of those apps support jack transport? I could swear I
used set sooperlooper to sync to jack, which would cause it to trigger
the loop exactly on the downbeat (which still didn't help my terrible
playing).
Maybe I'm not clear on what you're actually trying to do though...
2:57 p.m.
Paul Coccoli wrote:
Maybe I'm not clear on what you're actually
trying to do though...
Two laptops, one running chuck (no sync available), the other running
sooperlooper. The chuck one is the time master. So I send osc messages
from chuck on the first laptop to a simple chuck script on the
sooperlooper laptop. This scripts generates midi clock from the osc
messages it receives and sends it to sooperlooper for a synchronization
of the two applications.
Was that clear?
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
11:03 a.m.
On Fri, May 29, 2009 2:33 pm, Atte André Jensen wrote:
I did some playing with sooperlooper, and I think it's calculating the
tempo correctly based on the clock pulses that you feed it. So, if you
get a different tempo... then you're T's aren't spaced right.
I would also try it _without_ the S.
When playing with it, I surprisingly had a hard time getting my midi clock
pulses to send out with the right timing.
S
S S
T T T T .... T T T T .... T T T T
As mentioned the two clients I test against misbehaves with this,
running at 116-117 bpm instead of 112. Maybe I should stop thinking so much and just hack
away something that
works for exactly my purpose (I only need to sync with sooperlooper),
however wrong (according to the standard) it is.
Still, I'd be interrested in any input, though...
Doesn't sooperlooper sync to the JACK transport? (It does on my machine.)
If it were me, I would try that route rather than midi clock. :-)
--
G a b r i e l M B e d d i n g f i e l d
3 p.m.
Gabriel M. Beddingfield wrote:
I would also try it _without_ the S.
Then the tempo works just fine, however the two apps have different
downbeats.
Doesn't sooperlooper sync to the JACK transport?
(It does on my machine.)
If it were me, I would try that route rather than midi clock. :-)
As just outlines in another post, the problem is a bit more complex, as
is involves chuck which doesn't sync to anything. Also chuck and
sooperlooper are running on two different laptops...
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
5:46 p.m.
Atte André Jensen wrote:
Does sooperlooper respond to Song Position Pointer (0xF2) and/or MIDI Continue
(0xFB)? You may be able to sync time using these instead of Song Start (0xFA).
Song Position Pointer sends a 14-bit song position, followed by a MIDI
Continue which means ("start playing at that spot on the next clock tick"). The
14-bit song position is in "MIDI beats" since the beginning of the song. 6 MIDI
Clocks == 1 MIDI beat.
Also, I noticed that sooperlooper is determining tempo by some manner of rolling
average calculation. (Maybe it doesn't, but that's the way it *acts*.) If so,
that makes it even harder to get sooperlooper to sync to a downbeat.
I would also
try it _without_ the S.
Then the tempo works just fine, however the two apps have different
downbeats. As just outlines in another post, the problem is a bit
more complex, as
is involves chuck which doesn't sync to anything. Also chuck and
sooperlooper are running on two different laptops...
Right now, the laptop 2 has a chuck script that listens for OSC messages and
feeds sooperlooper a MIDI clock. Instead, you could write a simple C program
that listens for OSC messages and is the JACK transport master. Writing a
transport master is not very difficult.
Looks like Esben Stein did exactly this recently:
http://www.nabble.com/JACK-Transport-td23135202.html
Also, perhaps netjack already has this ability.
HTH,
Gabriel
9:27 p.m.
Gabriel M. Beddingfield wrote:
Right now, the laptop 2 has a chuck script that
listens for OSC messages
and feeds sooperlooper a MIDI clock. Instead, you could write a simple
C program that listens for OSC messages and is the JACK transport
master. Writing a transport master is not very difficult.
Could be a possibility. I've been using jack transport locally and
that's rock steady and without problems. Basically what I need is sync
of tempo + the beginning of each bar. Start/stop and bar number is
unnecessary for this exact purpose.
Looks like Esben Stein did exactly this recently:
http://www.nabble.com/JACK-Transport-td23135202.html
From reading this, it seems to me he wrote "something" in
supercollider. If it's reasonably stand-alone that shouldn't be a
problem though.
Also, perhaps netjack already has this ability.
I'll have to look into that also.
Basically it seems that I have more options that I thought. I start with
what I have and check other possibilities if I get in trouble.
Thanks for the ideas!
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
31 May
31 May
2:58 a.m.
On Sun, May 31, 2009 at 01:27:02AM +0200, Atte André Jensen wrote:
Gabriel M. Beddingfield wrote:
netjack syncs the transport of the slave to the transport of the master.
however the problem of chuck not syncing to anything cant be solved by
this.
bad chuck.
there seems to be a small bug currently, which prevents the transport
from starting the first times. just press it a bit more often.
however it makes me a bit sad, that people still try to solve the
orgiginal intended use-case of netjack with kludges.
can you people please explain, why you never try netjack ?
its installed with any recent jack and its a matter of:
jack_netsource -h slave_name
jackd -R -d net
what is so complicated about this ?
Right now, the laptop 2 has a chuck script that
listens for OSC messages
and feeds sooperlooper a MIDI clock. Instead, you could write a simple
C program that listens for OSC messages and is the JACK transport
master. Writing a transport master is not very difficult.
Could be a possibility. I've been using jack transport locally and
that's rock steady and without problems. Basically what I need is sync
of tempo + the beginning of each bar. Start/stop and bar number is
unnecessary for this exact purpose.
Looks like Esben Stein did exactly this
recently:
http://www.nabble.com/JACK-Transport-td23135202.html
From reading this, it seems to me he wrote "something" in
supercollider. If it's reasonably stand-alone that shouldn't be a
problem though.
Also, perhaps netjack already has this ability.
I'll have to look into that also.
Basically it seems that I have more options that I thought. I start with
what I have and check other possibilities if I get in trouble.
Thanks for the ideas!
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
4:11 a.m.
Here's another vote for Netjack, and i respectfully suggest users try
it out, not just through the interlink, but in a LAN as well.
Works a treat, and personally, i can see it being a valuable tool for
users with more than 1 audio box in their composer's armoury.
Alex.
On Sun, May 31, 2009 at 7:50 AM, <torbenh(a)gmx.de> wrote:
On Sun, May 31, 2009 at 01:27:02AM +0200, Atte André
Jensen wrote:
--
www.openoctave.org
Gabriel M. Beddingfield wrote:
netjack syncs the transport of the slave to the transport of the master.
however the problem of chuck not syncing to anything cant be solved by
this.
bad chuck.
there seems to be a small bug currently, which prevents the transport
from starting the first times. just press it a bit more often.
however it makes me a bit sad, that people still try to solve the
orgiginal intended use-case of netjack with kludges.
can you people please explain, why you never try netjack ?
its installed with any recent jack and its a matter of:
jack_netsource -h slave_name
jackd -R -d net
what is so complicated about this ?
Right now, the laptop 2 has a chuck script that
listens for OSC messages
and feeds sooperlooper a MIDI clock. Instead, you could write a simple
C program that listens for OSC messages and is the JACK transport
master. Writing a transport master is not very difficult.
Could be a possibility. I've been using jack transport locally and
that's rock steady and without problems. Basically what I need is sync
of tempo + the beginning of each bar. Start/stop and bar number is
unnecessary for this exact purpose.
Looks like Esben Stein did exactly this
recently:
http://www.nabble.com/JACK-Transport-td23135202.html
From reading this, it seems to me he wrote "something" in
supercollider. If it's reasonably stand-alone that shouldn't be a
problem though.
Also, perhaps netjack already has this ability.
I'll have to look into that also.
Basically it seems that I have more options that I thought. I start with
what I have and check other possibilities if I get in trouble.
Thanks for the ideas!
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
9:59 a.m.
torbenh(a)gmx.de wrote:
can you people please explain, why you never try
netjack ?
its installed with any recent jack and its a matter of:
Apparently much more recent (0.109.2) than my distro provides.... that's why.
And it took forever for *that* to be considered "stable."
-gabriel
30 May
30 May
11:09 p.m.
On Sat, May 30, 2009 at 3:46 PM, Gabriel M. Beddingfield
<gabriel(a)teuton.org> wrote:
Does sooperlooper respond to Song Position Pointer
(0xF2) and/or MIDI Continue
(0xFB)? You may be able to sync time using these instead of Song Start (0xFA).
Song Position Pointer sends a 14-bit song position, followed by a MIDI
Continue which means ("start playing at that spot on the next clock tick").
The
14-bit song position is in "MIDI beats" since the beginning of the song. 6
MIDI
Clocks == 1 MIDI beat.
SL does not respond to SPP, but it probably should.
Also, I noticed that sooperlooper is determining tempo
by some manner of rolling
average calculation. (Maybe it doesn't, but that's the way it *acts*.) If so,
that makes it even harder to get sooperlooper to sync to a downbeat.
It does indeed determine the displayed tempo by a rolling average, but
for sync purposes it responds immediately upon receipt of the relevant
clock ticks.
jlc
10 Jun
10 Jun
2:39 p.m.
On Fri, 29 May 2009, Atte André Jensen wrote:
Maybe it's all just a shitty old protocol that is
finally being replaced
by stuff like jack transport (that works very reliable, actually
precisely between renoise and ardour).
If you're speaking of MIDI, I have to agree about the actual protocol,
but we still can't do without it. I have a Roland Jupiter-8, an
Oberheim OB-8, an Ensoniq ESQ-1, and a Multimoog connected to MIDI via a
CV/gate convertor. There is currently no replacing the sound of these
older synthesizers with any softsynth I've ever heard, plus there is
just something about old classic synths.
For the sake of instruments like these, Linux needs good MIDI support!
(It would be nice for more current hardware to go with something that
works over gigabit ethernet and uses IP...much less problems I'd
imagine...)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
3:57 p.m.
On Wed, Jun 10, 2009 at 12:39 PM, Brent Busby<brent(a)keycorner.org> wrote:
On Fri, 29 May 2009, Atte André Jensen wrote:
I have no idea what you imagine or find Linux to be lacking in terms
of "MIDI support" that would affect any of these devices, unless you
mean actual applications.
Maybe it's all just a shitty old protocol
that is finally being replaced
by stuff like jack transport (that works very reliable, actually
precisely between renoise and ardour).
If you're speaking of MIDI, I have to agree about the actual protocol, but
we still can't do without it. I have a Roland Jupiter-8, an Oberheim OB-8,
an Ensoniq ESQ-1, and a Multimoog connected to MIDI via a CV/gate convertor.
There is currently no replacing the sound of these older synthesizers with
any softsynth I've ever heard, plus there is just something about old
classic synths.
For the sake of instruments like these, Linux needs good MIDI support! (It
would be nice for more current hardware to go with something that works over
gigabit ethernet and uses IP...much less problems I'd imagine...)
6:31 p.m.
On Wed, 10 Jun 2009, Paul Davis wrote:
On Wed, Jun 10, 2009 at 12:39 PM, Brent
Busby<brent(a)keycorner.org> wrote:
No, actually it just sounded like Atte was trying to assess whether
debugging problems with MIDI i/o in the apps was worth doing anymore,
now that we have Jack connections within the software. I just wanted
developers to remember there are people still out there that care a lot
about outboard gear.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
On Fri, 29 May 2009, Atte André Jensen wrote:
I have no idea what you imagine or find Linux to be lacking in terms
of "MIDI support" that would affect any of these devices, unless you
mean actual applications. Maybe it's all just a shitty old protocol
that is finally being replaced
by stuff like jack transport (that works very reliable, actually
precisely between renoise and ardour).
If you're speaking of MIDI, I have to agree about the actual protocol, but
we still can't do without it. I have a Roland Jupiter-8, an Oberheim OB-8,
an Ensoniq ESQ-1, and a Multimoog connected to MIDI via a CV/gate convertor.
There is currently no replacing the sound of these older synthesizers with
any softsynth I've ever heard, plus there is just something about old
classic synths.
For the sake of instruments like these, Linux needs good MIDI support! (It
would be nice for more current hardware to go with something that works over
gigabit ethernet and uses IP...much less problems I'd imagine...)
11 Jun
11 Jun
5:27 a.m.
Brent Busby wrote:
No, actually it just sounded like Atte was trying to
assess whether
debugging problems with MIDI i/o in the apps was worth doing anymore,
now that we have Jack connections within the software.
In a way I was. Of course we need midi support (and we have). But the
"not worth" in this case really just reffers to my specefic application
which is syncing chuck on one laptop with sooperlooper on another.
While midi being important and all, I still feel (and I really mean
*feel*, I, as mentioned, don't have much to back this up) that there
seems to be some "hacks" or confusion within the midi implementations.
At least I guess it's never gonna be as good sync-wise as jack
transport, where it's software to software and the central piece (jack)
has it's source code open for all client developers to look at.
I think I mentioned this before, but I tried syncing ardour and renoise
through jack transport, and they sync perfect to the point you feel it's
the same program, except that you have two windows open!
Basically I'm not trying to discard the midi standard or anything just
getting my feet wet with midi time code, that's all :-)
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
7:25 a.m.
On Thu, 11 Jun 2009 09:27:30 +0200, Atte Andre Jensen
<atte.jensen(a)gmail.com> wrote:
Brent Busby wrote:
Hi,
I've been trying to decipher this thread, and I still don't understand its
purpose. Is there an actual problem to be solved here or is this just some
subtle freestyle ranting ?
Cheers,
Marc-Olivier Barre
XMPP ID : marco(a)marcochapeau.org
www.MarcOChapeau.org
No, actually it just sounded like Atte was trying
to assess whether
debugging problems with MIDI i/o in the apps was worth doing anymore,
now that we have Jack connections within the software.
In a way I was. Of course we need midi support (and we have). But the
"not worth" in this case really just reffers to my specefic application
which is syncing chuck on one laptop with sooperlooper on another.
While midi being important and all, I still feel (and I really mean
*feel*, I, as mentioned, don't have much to back this up) that there
seems to be some "hacks" or confusion within the midi implementations.
At least I guess it's never gonna be as good sync-wise as jack
transport, where it's software to software and the central piece (jack)
has it's source code open for all client developers to look at.
I think I mentioned this before, but I tried syncing ardour and renoise
through jack transport, and they sync perfect to the point you feel it's
the same program, except that you have two windows open!
Basically I'm not trying to discard the midi standard or anything just
getting my feet wet with midi time code, that's all :-)
8:09 a.m.
Marc-Olivier Barre wrote:
I've been trying to decipher this thread, and I
still don't understand its
purpose. Is there an actual problem to be solved here or is this just some
subtle freestyle ranting ?
I'm sorry to have caused confusion.
I was asking how to implement midi clock, since there seemed to be some
subtle differences between the specs and the things worked in warious
programs, at least that how it seemed when I played with it.
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
10:06 a.m.
On Thu, Jun 11, 2009 at 6:09 AM, Atte Andre Jensen<atte.jensen(a)gmail.com> wrote:
Marc-Olivier Barre wrote:
This is true in hardware too. Not to quite the same extent as with
linux software, but its still not too hard to find subtle things wrong
when using MIDI Clock to sync devices. The protocol spec is written in
wierd english, not particularly clear about intent when it comes to a
few details, and as a result, people interpret things differently.
I've been trying to decipher this thread, and
I still don't understand its
purpose. Is there an actual problem to be solved here or is this just some
subtle freestyle ranting ?
I'm sorry to have caused confusion.
I was asking how to implement midi clock, since there seemed to be some
subtle differences between the specs and the things worked in warious
programs, at least that how it seemed when I played with it.
13 Jun
13 Jun
10:13 a.m.
On Thu, Jun 11, 2009 at 8:06 AM, Paul Davis<paul(a)linuxaudiosystems.com> wrote:
Just to reiterate on the original topic of the thread, the current
SooperLooper implementation of MIDI clock does *not* follow the spec
with regard to the start message. I'm guessing at least a few of the
other apps the OP tried make the same mistake. I will correct it
eventually.
jlc
I was asking
how to implement midi clock, since there seemed to be some
subtle differences between the specs and the things worked in warious
programs, at least that how it seemed when I played with it.
This is true in hardware too. Not to quite the same extent as with
linux software, but its still not too hard to find subtle things wrong
when using MIDI Clock to sync devices. The protocol spec is written in
wierd english, not particularly clear about intent when it comes to a
few details, and as a result, people interpret things differently.
5644
days inactive
5659
days old
linux-audio-user@lists.linuxaudio.org
20 comments
9 participants
participants (9)
-
alex stone -
Atte André Jensen -
Brent Busby -
Gabriel M. Beddingfield -
Jesse Chappell -
Marc-Olivier Barre -
Paul Coccoli -
Paul Davis -
torbenh＠gmx.de