31 May
2010
31 May
'10
9:54 p.m.
Hi everyone!
I recently downloaded the latest Klick version and notcied someting odd.
When I start klick like this:
klick -T 4/4 120
I can use jack_transport to start/stop/relocate and my MIDI sequencer can be
synced to jack_transport control.
If on the other hand I start klick in interactive mode:
klick -T -i 4/4 120
I can't use jack_transport control to do anything. Klick can start/stop and
this is certainly send. But jack_midi_clock doesn't get a clock-signal, somy
sequencer can't be synced. Any idea, why that might be?
Kindly yours
JUlien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
2 Jun
2 Jun
12:11 a.m.
On Monday 31 May 2010 21:55:24 Julien Claassen wrote:
I recently downloaded the latest Klick version and
notcied
someting odd. When I start klick like this:
klick -T 4/4 120
I can use jack_transport to start/stop/relocate and my MIDI
sequencer can be synced to jack_transport control.
If on the other hand I start klick in interactive mode:
klick -T -i 4/4 120
I can't use jack_transport control to do anything. Klick can
start/stop and this is certainly send. But jack_midi_clock doesn't
get a clock-signal, somy sequencer can't be synced. Any idea, why
that might be?
You're right, klick does not act as a JACK transport timebase master
when run in interactive mode...
The job of the timebase master is basically to translate the position
from audio frames into bars and beats (BBT). When klick is run with a
fixed tempo or tempo map, that's quite easy to do. But in interactive
mode, you can change the tempo at any time.
So the question is, if you change the tempo in the middle of a song, at
which point does that change take effect?
If you change the tempo, but keep both the current frame and BBT, you
allow frame and BBT to effectively go out of sync (going back to the
first bar, you'd not end up at frame 0 anymore).
On the other hand, if you recalculate the position based on the
beginning of the timeline, either the frame or the BBT position has to
change. And either way, some clients (probably those syncing to BBT)
will be forced to jump to a different position.
This topic has actually come up a couple of times before, and I'm
somewhat surprised by how often klick is used not as a metronome but as
a JACK transport master. I'm not sure how to handle this use case in
interactive mode, but I'm open to suggestions.
Dominic
12:18 a.m.
Hello dominic!
Why not create an interactive timebase-Master mode. Where you can start/stop
and relocate. But changing of tempo and time signature is only allowed, while
the metronome is stopped? Perhaps you might also offer a command like 'l',
which then would prompt the user for a tempo-map file. This way you have it
all, all that' spossible: interactivity, changing settings, but no hassle with
complicated use-cases.
Just a thought...
Warm regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
8 Jun
8 Jun
1:14 a.m.
Hi Julien,
On Wednesday 02 June 2010 00:18:37 Julien Claassen wrote:
Why not create an interactive timebase-Master mode.
Where you can
start/stop and relocate. But changing of tempo and time signature
is only allowed, while the metronome is stopped?
I'll see what I can do. It wouldn't really be a problem to change the
tempo while playing, you just can't always expect all clients to remain
in sync.
I agree that start/stop/relocate would also be nice to have, at least as
long as everything still fits on one line as it does now :)
Perhaps you might
also offer a command like 'l', which then would prompt the user for
a tempo-map file. This way you have it all, all that' spossible:
interactivity, changing settings, but no hassle with complicated
use-cases.
I'm not sure about that. What would be the advantage over just
terminating klick and using the shell to start a new instance with a
tempo map?
Cheers,
Dominic
9:24 a.m.
Hello Dominic!
Well the reason I suggested loading a tempomap from within klick, was just
convenience. It would help me in my setup a bit. I use screen to automatically
start klick. If I finish klick, the virtual terminal it ran on is gone as
well. This can be prevented with writing a script around klick.
Unless there isn't much to de- or reinitialise the code for loading should
be fairly simple though and not many lines should do it, assuming you've
written some pieces of reuseable code, which I assume you did.
But that's just speculating away. Might be nice to have, but I certainly
could live without it. :-)
Have a sunny day
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
9 Jun
9 Jun
1:04 a.m.
On Tuesday 08 June 2010 09:25:07 Julien Claassen wrote:
Well the reason I suggested loading a tempomap from
within klick,
was just convenience. It would help me in my setup a bit. I use
screen to automatically start klick. If I finish klick, the virtual
terminal it ran on is gone as well. This can be prevented with
writing a script around klick.
Couldn't you just start a new shell in screen (C-a c) and run klick from
there? That way the virtual terminal shouldn't go away when you close
klick. Or maybe leave the interactive klick running in one (virtual)
terminal and start the one with a tempo map in another?
Oh, and doing all this in the shell also gives you nice features like a
command history and autocompletion, which would be serious overkill if
added to klick :)
Dominic
2:01 a.m.
On Tue, Jun 8, 2010 at 7:03 PM, Dominic Sacré <dominic.sacre(a)gmx.de> wrote:
On Tuesday 08 June 2010 09:25:07 Julien Claassen
wrote:
man nohup
perhaps.
Well the reason I suggested loading a tempomap
from within klick,
was just convenience. It would help me in my setup a bit. I use
screen to automatically start klick. If I finish klick, the virtual
terminal it ran on is gone as well. This can be prevented with
writing a script around klick.
Couldn't you just start a new shell in screen (C-a c) and run klick from
there?
10 a.m.
Hello!
Paul as far as I can see, nohup isn't of any help in this case.
Dominic, When I start it in a shell, I can't start the screen from a script.
I use a shell script to create the screen session and file the virtual
terminals of the screen. There's jackd, the midi_bridges, jack_midi_clock and
klick. But as I said, the tempomap from the interactive mode was just a
sideline. Never mind me ranting in the corner. :-) The important thing would
be the Master capability in some kind of interactive mode.
Kind regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
2 Jun
2 Jun
1:25 a.m.
Hi Dominic,
On Wed, 2 Jun 2010, Dominic Sacré wrote:
You're right, klick does not act as a JACK
transport timebase master
when run in interactive mode...
First, klick is really sweet. My favorite feature is -t/-T.
With respect to real-time temop changing, I've given this subject a
lot of thought and code while working on InConcert.[1] Here's my
thoughts...
So the question is, if you change the tempo in the
middle of a song, at
which point does that change take effect?
Simple answer: immediately.
Complex answer: Read on.
If you change the tempo, but keep both the current
frame and BBT, you
allow frame and BBT to effectively go out of sync (going back to the
first bar, you'd not end up at frame 0 anymore).
On the other hand, if you recalculate the position based on the
beginning of the timeline, either the frame or the BBT position has to
change. And either way, some clients (probably those syncing to BBT)
will be forced to jump to a different position.
Yes, in fact when I first announced the concept of InConcert, I think
the title was something like "Abusing the transport for live tempo
sync." You can't do everything, so you have to choose one, and just
be clear about which one you are choosing.
ATM, the primary use-case is with sequencers. Most of the
audio-frame-based trackers (ardour, audacity, qtractor) are
disregarding BBT info for audio, anyway. The only way those guys
could support this sort of real-time flexibility is if they allow
on-the-fly time stretch and stuff like that... and I don't know of any
that do.
Furthermore, the issues you mention all have to do with /seeking/.
This only make sense in a "live" situation if the host sequencer has
special support for it anyway. For a simple implementation, you can
mostly ignore seeking.
Here's a few different ways to approach it:
1. Floating Reference/Epoch: This is the first case you
mentioned. When the tempo changes, you recalculate
your BBT/frame reference point. Frame 0 is no longer
1:1.0... so you will (as a special case) reset the
timeline whenever someone relocates to 0.
2. Recorded Timeline / Epoch Stack: You keep track of
all the tempo changes... and always base your current
calculations off the most recent change. If someone
seeks backward... you "time travel" to the BBT, frame,
and (optionally) tempo that occurred at that time.
This is similar to the way that Ableton will record a
live session.
3. Frame-based timeline: There is a fixed "master"
timeline that is friendly with the frame-based trackers.
If you ever do a live-tempo change, you deviate from
this map. However, if you ever seek, you return to
this map. (I can't imagine this to be very useful,
but maybe something along these lines could play along
with programs like ardour.)
I recommend #1 since it's simple to implement, is the most flexible
WRT time-signature changes, and simple for users to understand.
Hope this helps,
Gabriel
[1] http://www.teuton.org/~gabriel/InConcert/
8 Jun
8 Jun
1:14 a.m.
On Wednesday 02 June 2010 01:25:28 Gabriel M. Beddingfield wrote:
With respect to real-time temop changing, I've
given this subject a
lot of thought and code while working on InConcert.[1] Here's my
thoughts...
Thanks Gabriel... I was actually leaning towards one of the other
options, so that's definitely food for thought :)
But everything you wrote makes perfect sense, and I'm starting to think
that the "floating reference" approach is indeed the one that makes most
sense for klick to implement.
As soon as both audio-frame-based clients and BBT-based clients are
present and syncing to JACK transport, there's simply no way for the
timebase master to keep both in sync. And I doubt that users would
expect clients like Ardour to do on-the-fly timestretching when the
transport changes tempo - although it would be great if it could...
So the question is, if you change the tempo in
the middle of a
song, at which point does that change take effect?
Simple answer: immediately. Furthermore, the issues you mention all have to do
with /seeking/.
This only make sense in a "live" situation if the host sequencer has
special support for it anyway. For a simple implementation, you can
mostly ignore seeking.
Here's a few different ways to approach it:
1. Floating Reference/Epoch: This is the first case you
mentioned. When the tempo changes, you recalculate
your BBT/frame reference point. Frame 0 is no longer
1:1.0... so you will (as a special case) reset the
timeline whenever someone relocates to 0.
Is relocating to zero really different enough from seeking to other
positions to make it a special case? At the very least, the timeline
would also need to be reset when seeking would otherwise result in a
negative frame or bar number.
The only case I can think of where it would be advantageous to avoid
resetting the timeline is when seeking relative to the current position
(whatever that means in terms of the UI used), but I'm not sure if
that's really a convincing argument.
Cheers,
Dominic
5286
days inactive
5295
days old
linux-audio-user@lists.linuxaudio.org
9 comments
4 participants
participants (4)
-
Dominic Sacré -
Gabriel M. Beddingfield -
Julien Claassen -
Paul Davis