+- Conductive Labs Support Forum (https://conductivelabs.com/forum)
+-- Forum: MRCC - MIDI Router Control Center (https://conductivelabs.com/forum/forumdisplay.php?fid=13)
+--- Forum: MRCC Open Beta Firmware (https://conductivelabs.com/forum/forumdisplay.php?fid=26)
+--- Thread: MRCC Firmware Release 1.1.095 (/showthread.php?tid=2107)
RE: MRCC Firmware Beta 1.1.089 - RadekPilich - 09-22-2025
Another update to the Faderfox sysex issue above.... turns out it affects routing to PC as well.
So all the outputs are affected - DIN, USB, PC.
RE: MRCC Firmware Beta 1.1.089 - ekkomouse - 10-01-2025
Just thought I would report im getting scenarios where notes sent from an osmose which contains lots of PB and aftertouch data seem to overwhelm the MRCC and requires a restart. I dont believe I have any extra clocks but there are clocks coming in on multiple inputs and routing. After restart it works again, and im not sure what triggers it yet so I'll try to report back if I can reproduce it.
RE: MRCC Firmware Beta 1.1.089 - Darryl - 10-03-2025
(10-01-2025, 06:57 PM)ekkomouse Wrote: Just thought I would report im getting scenarios where notes sent from an osmose which contains lots of PB and aftertouch data seem to overwhelm the MRCC and requires a restart. I dont believe I have any extra clocks but there are clocks coming in on multiple inputs and routing. After restart it works again, and im not sure what triggers it yet so I'll try to report back if I can reproduce it.
A while back we received a similar report from someone using the Linnstrument. It was flooding the MRCC with poly aftertouch. We spoke to Roger Linn about it and he said that by default, the device doesn't throttle MIDI data (much?), it's sending at a much higher than 31250bps MIDI rate. However, there's a setting to change the sampling speed to slow the data rate and that fixed the issue.
We would prefer if MRCC handled buffer overflows more gracefully, but maybe the osmose has a similar setting to limit the USB data rate?