Tempo issues using MCON in Mappings?

[kriskeyman]

Hello,

I’m running into an issue where MCON commands in Mappings are unexpectedly modifying the tempo for the project.

Clock In is set to MOD.CLOCK (issue also occurs when set to Internal)
Clock Out is set to DIN-SYNC24.
Clock/Reset Outputs of Nerdseq are going to Pam’s New Workout.
MULTI-IO is connected to MIDI interface via TRS-A sending clock to Bitwig.

I only have two rows populated in Mappings:
MCC HC1 #32 > MCON TC10 #91 (modifies Machinedrum delay send from Sweet16 slider)
I2C SCCV #0 > MCON TC10 #10 (modifies Machinedrum track level from F8R via I2C)

When I move slider #32 on Sweet16, there is a BPM change of ~3 bpm noticed on PNW & Bitwig.
When I move slider #0 on F8R, there is a BPM change of ~1 bpm noticed on PNW & Bitwig.
In both cases, the tempo fluctuates while the slider is being moved, then returns to correct tempo once slider stops moving.

All is working fine except for the unexpected tempo changes when moving sliders that shouldn’t be linked to tempo at all. I have also tried changing Machinedrum base channel to 13 (and modifying mapping to TC13) and the issue persists.

Any guidance for where to begin troubleshooting would be appreciated.

Is there a way to modify mappings so the above does not modify tempo, or is something incorrect in setup, or is this a bug?

[kriskeyman]

I figured out the issue!

This only occurs when a single MIDI slider (in my case on Sweet Sixteen #32), is set as source controlling multiple MIDI CC changes (in my case, delay send for 2 tracks on Machinedrum). Looked like this…

MCC HC1 #32 > MCON TC10 #91
MCC HC1 #32 > MCON TC10 #115
This causes serious tempo fluctuations in setup when slider is moved!

I2C SCCV #7 (F8R) > MCON TC10 #91
I2C SCCV #7 > MCON TC10 #115
Tempo good when slider is moved.

MCC HC1 #32 > MCON TC10 #91
MCC HC1 #33 > MCON TC10 #115
Tempo good when slider is moved.

So not sure if this is a bug somewhere or just a limitation in MIDI spec since I2C seems to be okay.

[XORadmin]

I can imagine that it indeed generates too much data to all together push out via midi.
If I just think about the fact that the input is being already received back to back via midi and you double the data for the output which could cause the output data to be buffered = midi data limits.

Maybe I need to add a limitation for the midi data that the mappings could generate. Just keep in mind that every row gets executed every millisecond. So each millisecond a CC data could be added which is faster already than each midi cc data needs to be send out. Imagine now multiple rows being executed within that millisecond….traffic jam :-)

However, that doesn’t explain everything you describe. Maybe you can also send me your project so I can take a look.