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, 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
