After syncing my DuoX to incoming MIDI from my Duo, the DuoX is stuck at “NaN BPM”, regardless of what sync mode I set, or how many reboots I perform.
How to reproduce
Set Duo sync mode to Internal
Put the MIDI Clock plugin on the pedalboard and connect its output to the Duo MIDI output. (I used “Clock and Start/Stop” mode in the plugin)
Connect a MIDI DIN cable from the Duo MIDI out to the DuoX MIDI in.
Set the DuoX sync mode to “MIDI”
Run the transport on the Duo and change the tempo while it’s running.
The DuoX transport starts, and its BPM follows the tempo changes coming from the Duo for a short time, then the BPM display shows “NaN BPM”.
At this point, I haven’t found any way to get the DuoX out of “NaN BPM” – it still starts/stops transport (both internally, and from MIDI sync), but it will not take a proper tempo from either sync method, even after numerous reboots and recalls of the Default pedalboard.
If I attempt to put in a tempo using the text input box (even in Internal sync mode), the tempo display is constantly refreshing to “NaN BPM” – as soon as I start to input any text, it’s overwriten with “NaN BPM”.
Expected/suggested solution
BPM and transport should reliably following incoming MIDI clock/transport, and should certainly not get permanently stuck in the “NaN BPM” dysfunctional state.
Additional information
Duo release: 1.8.0.923-RC5
Duo controller: 94E4A28
DuoX release: 1.8.0.924-RC5
DuoX controller: 94E4A28
Also provide some information about your system if possible.
Operating system: Manjaro Linux
System version: 5.2.10-rt5-MANJARO #1 SMP PREEMPT RT Tue Aug 27 12:55:52 UTC 2019 x86_64 GNU/Linux
Later Note: I’m also occasionally getting a “Bug! Couldn’t set new sync mode” notice on the DuoX, when I try to switch between Internal and MIDI. This happened even before I got stuck in “NaN BPM”, but is not consistent; a lot of the time, it switches sync modes just fine.
Also: CPU load pegged at 100% right after the DuoX got stuck in “NaN BPM”. Since re-booting, the CPU load looks normal, even though BPM is still stuck.
the DuoX BPM indicator often goes to NaN (with a corresponding jump to 100% in CPU usage) after only a change in transport state on the Duo (not a change in tempo).
i’ve discovered that changing tempo in the settings menu on the DuoX itself does get it out of the NaN state.
today, it seems like rebooting usually clears the NaN state, although not always.
N.B.!! here’s something really interesting that i just found!:
the tempo on the DuoX follows with more stability, the lower the incoming tempo from the Duo is. it looks completely stable at 60 or lower. around 75-160, it’s wandering a bit in the 100ths of a BPM. around 170, it’s wandering in the 10ths of a BPM. around 195, it starts wandering between 194 and 196. at 200, it’s bouncing around between 160 and 370, with occasional 1000’s or 10’s of thousands, and a very infrequent NaN. when i go to 210, it just fails to track at all, and eventually goes to NaN.
unfortunately, the whole thing seems a bit unpredictable and touchy…
i’d really like to be able to sync BPM on these two boxes – ability to lock to incoming sync was one of the big attractive features of the DuoX for me – is there something in my procedure that should be done differently?
This is quite interesting… (perhaps I should not say this, but as an issue, well it is, technically)
The instability of higher BPMs is expected, as making up BPM for MIDI sync means counting the time difference between each “pulse”. The faster the pulses, the less precise they are.
In any case, that is still a bug and should be fixed.
With 1.8 we made some changes to improve the timing (mostly when using USB MIDI), did you try that? (What version are you using on the duox?)
I do not think it is an issue on the MIDI clock output, since I was able to make an external synth sync with the Duo quite nicely.
It is not something you are doing wrong, the MOD Duo and Duo X needs to support this better.
Sadly there is still no way to connect 2 MOD units at the same time, otherwise we could use Link which provides much more robust timing information.
