MIDI connection issues

I’m trying to use a Roland FC-300 foot controller with the MOD Duo.

When connecting it directly via MIDI, it seems some foot pedal MIDI controller events are lost. E.g. if I move a pedal up and down quickly, the knob I assigned the pedal to will just jump to a few values, and be stuck at e.g. 20% or 80% without fully reaching 0% and 100%. I have to move the pedal very slowly in order to reach the full range.

If I connect the same device via a USB MIDI adapter, it works smoothly. No events seem to be lost.

Is there anything I need to do to reconfigure the MIDI connection, to prevent this issue?

Following up on this – I’ve now played several concerts and rehearsals with USB MIDI, with no issues. Seems using plain MIDI is just not possible for now with that device.

I too am having issues with an old ADA midi pedal (0-10/±). It is not learning.

Hi, I’m having the exact same issue with the FC-300 controller and Mod Duo.

I reckon it is also the same mentioned on fractalaudio forums (search google for : jumpy midi FC-300 fractalaudio to get to the thread) and they managed to fix this. Looks like there was something wrong with “MIDI running status” implementation.

Many thanks @crenz for having found a workaround :slight_smile:

1 Like

Hi,
I also own a FC-300 and stumbled across the same issue.

Expression pedal values are somehow jumpy /stuttering when the pedal is directly connected to the HW MIDI in of the Mod Duo.
Also button presses on the FC-300 can get lost.

I can verify that @crenz workaround via USB MIDI is working.
It also worked perfectly when I routed the FC-300 MIDI to my PC through MIDI OX programm (for debugging) and from PC to the Mod Duo.

I suppose that this two sorts of “conversion”

  • either remove the “MIDI running status” optimisation from the original data stream before delivered towards the Mod Duo.
  • or change the message microtiming in a way that the Mod Duo gets along with it.

Unfortunately I didn’t find a tool to provide a raw data log for the devs.

For me it seems to be a timing / timeout issue.
If the exp pedal is moved slowly the issue doesn’t appear.
The faster the pedal is moved the stronger the issue becomes.

Finally two references according to the findings of @fenixfunkfive:


I hope the great developers from moddevices can provide a fix as well. Would be really great!!

Have you been installing all the updates?
The running status (on the DIN MIDI port) was indeed an issue, but fixed since 1.8.4 I believe.

I’m running version V1.8.5 now.
If there’s a tool that can record the raw MIDI data I could make a dump for you. I guess that’ll help best.
But I didn’t find a “Wireshark” for MIDI yet :frowning:

Last time I tried to look for one, also did not find it.
There were a few, but they all normalized the MIDI messages, which is exactly not what we want (we need the raw bytes)

Do you have a mod internal command line solution or similar that I could try out via SSH in order to make a record?
Otherwise, I could just try to record the serial dataline with an adapter…

No, but I can give you a binary that can do it.
http://web1.moddevices.com/shared/tmp/ttymidi-debug-modduo.tar.gz

Extract and scp into the MOD, then run as follows:

systemctl stop jack2
mount / -o remount,rw
scp ttymidi.so /usr/lib/jack/
mod-jackd
1 Like

I’m still having the jumpy midi issue with the 1.8.5 update.

I recently bought a Motu MIDI patchbay and the interesting thing is it can toggle Running Status on/off for each of its MIDI outputs.
So I plugged it like this :
FC-300 > Motu “In 1”
Motu “Out 2” > Mod Duo
Then patched “In 1” to “Out 2” it internally and deactivated Running Status messages on “Out 2”.
As I expected I was then able to use the FC-300 expression pedals with no jumping.

Then I reactivated Running Status messages on “Out 2”, and it works well that way too (suprprisingly).
ttymidi-debug displays :

  • B1 01
  • 01 01 (running status)
    expectedly I get more running status lines as I move the pedal faster.

Then I plugged directly the FC-300 to the ModDuo
and here’s a more extended example of what ttymidi-debug displays :
b1 01 03
01 01 06
01 01 09
01 01 0d
01 01 0f
01 01 13
01 01 17
fe fe
01 Status byte check failed, first bad byte: 01
1b Status byte check failed, first bad byte: 1b
01 Status byte check failed, first bad byte: 01
1f Status byte check failed, first bad byte: 1f
01 Status byte check failed, first bad byte: 01
23 Status byte check failed, first bad byte: 23
01 Status byte check failed, first bad byte: 01
28 Status byte check failed, first bad byte: 28
01 Status byte check failed, first bad byte: 01
2c Status byte check failed, first bad byte: 2c
01 Status byte check failed, first bad byte: 01
31 Status byte check failed, first bad byte: 31
01 Status byte check failed, first bad byte: 01
36 Status byte check failed, first bad byte: 36
01 Status byte check failed, first bad byte: 01
3c Status byte check failed, first bad byte: 3c
01 Status byte check failed, first bad byte: 01
40 Status byte check failed, first bad byte: 40
01 Status byte check failed, first bad byte: 01
46 Status byte check failed, first bad byte: 46
01 Status byte check failed, first bad byte: 01
4a Status byte check failed, first bad byte: 4a
The errors always repeat until a new B1 01 message is received and the same pattern occurs : a few running status messages go through until the next Active Sensing arrives and puts the Mod “out of sync”.

I just figured out that the Motu patchbay mutes Active Sensing messages on all ins/outs by default, and I successfully reproduced the issue by allowing them through

yeah, I got the similar logs from @Dan_The_Man
you can find a fixed ttymidi binary here http://web1.moddevices.com/shared/tmp/ttymidi-0xfe-fix.tar.gz

from talking to other developers, I got the impression that active sensing could be sent in the middle of regular MIDI “voice messages”
so while that fix will do the job for now, there might be problems with other MIDI devices.

1 Like

many thanks @falkTX !
yes no worries I checked the manuals of the devices I own and every one of them seem to either ignore/filter out these messages by default