10 Aug
2014
10 Aug
'14
9:43 a.m.
On August 10, 2014 03:19:05 AM Tim E. Real wrote:
On August 9, 2014 07:28:35 PM Brent Busby wrote:
> I'm having some difficulty getting Ardour 3 and Muse to consistently
> tempo lock to eachother. By consistently, I don't mean that they'll
> lose sync once I've got it working. Rather, it seems to be a tricky
> business getting it to happen at all.
>
> It seems to somewhat depend on the order they're started in,
Addendum:
Be aware if you start Ardour after MusE you must open MusE's Midi Settings
and manually add Adour as a new Jack or ALSA midi device.
(Actually there will be several Adour devices, including one for CLOCK.)
Otherwise, if you start MusE after Ardour, MusE will automatically
create all of its Ardour midi devices.
Tim.
but also
I've noticed that if I change Muse's sync settings, the tempo selection
can become grayed out -- appropriate when it's a slave, but it never
becomes active again when it is set as a master again.
You need to open the MusE Transport Panel and turn 'Master'
back on, or open the Graphical Master Track Editor and click 'Enable'.
It's because when you turn external sync on, either in the Midi Sync
Dialog or with the Transport Panel 'Sync' button, 'Master' turns off -
that is the the Master track is disabled - and it does NOT turn back
on by itself once external sync is turned off again.
The reasons for 'Master' not automatically turning back on are
obscure - I recall I tried to do it but ran into conceptual problems.
However, first simple thoughts upon reexamining it now are that it seems
we ought be able to store the last 'Master' setting and revert whenever
external sync is turned off again.
Or... maybe that's what I thought at the time but found there was
a problem with that. I think there are some comments in the code
somewhere explaining why - I'll probably remember tomorrow after
rambling on here.
(Master Track is just a fancy term for tempo / time signature graph.)
Does anyone have any recommendations for this?
I'd prefer Ardour as the
master, since it's the one handling actual sample data (with measure
lines in its timeline for real audio waves) and not just sequencer
playback, but at this point I'd almost take anything that would
consistently work. It seems that even if I setup Ardour as Jack
timebase master and edit its tempo ruler to 140bpm, it will show measure
lines on its timeline that are appropriate for 140bpm, but Jack programs
like Muse and Hydrogen will still playback at their default 120bpm, as
though they're receiving the transport control messages but not the
tempo sync. If I have one of them be the master, they disagree about
what 140bpm is, which means they're still not really synced. It's very
frustrating...
Sorry about that.
Currently the only way to sync MusE with other apps is with Midi Clock.
(Don't confuse Sync Master with Jack Transport Master: Jack Transport info
is shared so it's always 'synced' in each app.)
You must enable MusE's External Midi Clock, either the Transport Panel's
'Sync' button or the Midi Sync Dialog's 'Slave to External Sync'
checkbox.
Then you have to tell MusE where that Midi Clock sync comes from (Ardour)
in the Midi Sync Dialog and make sure you also turn on accepting of
realtime commands (that's start, stop, positional etc) in the 'rr' column.
You may also need to tell Ardour to turn on the sending of Midi Clock and
realtime commands.
And... one more thing:
You'll have to duplicate any tempo map from Ardour to MusE.
Or MusE can record any external tempos and replace its current tempo map.
I spoke of this years ago:
If MusE had a way of knowing when the other app's tempo map changes,
it could automatically change its tempo map and time line.
Even with Jack Transport this was not possible, only a 'linear' tempo
stream.
But with the new Jack Metadata API, maybe it's now possible.
There is some experimental unfinished MusE code to let Jack Transport's
BarBeatTick info drive our midi engine instead of our own tempomap-based
frame-to-miditick converter with external clock support.
An idea that seemed straightforward and logical to me.
I wrote it a few years ago but got discouraged when I found inconsistent
or non- full Jack Transport support in other apps.
I believe it is crucial that all the apps (MusE included) use the complete
full feature set of the Jack Transport API for the best accuracy.
There was also IIRC some kind of issue with the Jack Transport API where
I think I found it was not always possible to have accurate time<>BBT info.
However I saw recently someone brought up an issue there and Paul
committed some code for some of that time functionality.
Must take another look sometime.
Enough for now, hope that helps so far.
Tim.