Hi, I've been testing BW to be a master clock for some hardware devices (DR660, Analog 4 through Midiman Midisport 2x2) and I am getting a very noticeable tempo drift making the feature almost unusable. I haven't had any issues with SEQ24 that sends clock through the Midisport as well..so I am wondering if anyone has any experience with this issue and a workaround.
thanks!

Hi - i improved a bit on my setup detailed above (by following some additional tips at - http://wiki.linuxaudio.org/wiki/intel_hda_realtime_howto ). I think the only thing i didn't bother with was the realtime kernel since i think regular ubuntu is already a realtime kernel.
Now I've got it at 64 frames and I get a lot of XOR alerts and what not but the midi is quite stable. I haven't tested the audio though :) - probably suffers but yeah I didn't test is rigorously.

Any updates on decoupling the MIDI clock from the audio buffer size? When might we expect to see that happen? Really constrains the available resources for DSP to have to have such a small buffer size to keep the clock in sync.

After some long testing I seem to have found a good setting for my setup. The external sequencer clock of the DR-660 is stable but it does slip - so this isn't perfect. The culprit is most likely Jack settings for the machine or the way BW uses it (Causes "ERROR: JackEngine Xrun: client Bitwig Studio was not finished, state = Triggered"/"Running" + "ERROR: JackAudioDriver: ProcessGraphAsyncMaster: Process error" - although these now happen sometimes without ever causing tempo slip. I also get "XRUN callback (#)" + "XRUN callback (# skipped)" messages that seem to trigger slip for sure) Going to post my finds in case it helps someone:

I've also installed linux-tools-3.16.0-34-generic and set cpupower frequency-set -g performance (also intalling and adjusting cpufrequtils to use this setting upon system boot (GOVERNOR = "performance")

I have a feeling the above adjustments to the system only marginally help, and the main settings that insure solidity are the Jack settings specific for your system. The XRUN errors seem to happen depending on what I am doing on the system - for example opening the Ubuntu System Settings will cause a "XRUN callback (#)" almost 100% of the time. I also read that WIFI can cause latency issues with audio.

I still believe that SEQ24 provides a better clock and my tests were done before any of the above system adjustments. I did run SEQ24 without and withJack and at that time I was also trying BW using the ALSA driver - which was running better than Jack with default settings, but still unstable compared to SEQ24.

I also tested MIDI Thru chaining earlier, with the clock going to DR-660 and via MIDI THRU to a Nord Micromodular that was running a sequence (with correct external midi clock patching setup). With the previous settings I was able to desync the chained devices - but I would have to test this again now.

I also ran into very funky issues like BW sending only a maximum clock of around 110 even when the setting was turned higher than that. I was able to cause total chaos by changing midi tempos very rapidly. I also had midi issues when running a Micromodular with both BW and the Nomad patch editor at the same time - but these were initial tests with either ALSA in BW or default Jack.