+- 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 - Jesse Johannesen - 03-13-2025
(03-05-2025, 04:09 AM)ekkomouse Wrote: https://www.dropbox.com/scl/fi/3ydgvnjohn3qugqs3nzbp/mrcc-beta-unassigned-clock.MOV?rlkey=34wxt3du9wvb161j6c0s223zb&st=iybzicu8&dl=0
Here I was experiencing the clock issue on USB-C, so I factory reset the second mrcc, I only had one routing to a mioxl by usb D this time, that input was not routed anywhere else, but I was receiving double clock on remote 12. Filtering inputs from D did not remove clock, filtering output on D did work, but again it was not assigned anywhere. So it seems like there’s something routed before it reaches the USB filters.
This one is a fairly complicated issue and I am having trouble following the exact steps to recreate it from the video, so I am hoping that you might be available for a zoom call to take a closer look. If you could reach out to me at Support@conductivelabs.com with a few time slots you'll be available (I am busy Wed Sat and Sun 8am to 6pm Pacific Time, but can make time pretty much any other days) I can set us up a call for us.
(03-13-2025, 04:37 AM)ekkomouse Wrote: There’s a definite bug when using two MRCC units and routing from one to another on usb, there are phantom routings that come back unintentionally, I think I’ve posted a couple videos already. Can you confirm that you’ve got this and understand?
https://www.dropbox.com/scl/fi/rj0y5923dwipv4rpnwbuz/phantom-usb-connection-on-dual-mrcc.mov?rlkey=p7h4qqnbvdvytqq7ftga5e49o&st=staswncq&dl=0
Got it. I am looking at some of this stuff today to try and reproduce it.
Quote:(03-01-2025, 02:24 PM)ekkomouse Wrote:OK so for this one, the video doesn't show the MRCC doing anything funky. I recreated the issue by sending MRCC internal clock on PC port 1 of unit 1 to the USB host C port of unit 2 Factory restting unit 2, I still see Red Clock Arrows on the display. I think this is the expected behavior, as I get the same results from sending via DIN as well.
Separately I have an issue where I have a routing where clock is going from MRCC one to two, MRCC 2 Is sending clock back to a remote routing on 12 unintentionally when it’s not assigned , The only way I can stop it is to filter on the outport page.
https://www.dropbox.com/scl/fi/nv8podofy...ksdrs&dl=0
Not to say the issue you're reporting doesn't exist, but what is shown in the video doesn't illustrate an issue as far as I can tell.
If you were to factory reset the MRCC that is the clock source and it still showed red arrows on the destination then we would be looking at an issue, but here you are factory resetting the destination unless I am misunderstanding?
(03-05-2025, 04:09 AM)ekkomouse Wrote: https://www.dropbox.com/scl/fi/3ydgvnjohn3qugqs3nzbp/mrcc-beta-unassigned-clock.MOV?rlkey=34wxt3du9wvb161j6c0s223zb&st=iybzicu8&dl=0
Here I was experiencing the clock issue on USB-C, so I factory reset the second mrcc, I only had one routing to a mioxl by usb D this time, that input was not routed anywhere else, but I was receiving double clock on remote 12. Filtering inputs from D did not remove clock, filtering output on D did work, but again it was not assigned anywhere. So it seems like there’s something routed before it reaches the USB filters.
This one is a fairly complicated issue and I am having trouble following the exact steps to recreate it from the video, so I am hoping that you might be available for a zoom call to take a closer look. If you could reach out to me at Support@conductivelabs.com with a few time slots you'll be available (I am busy Wed Sat and Sun 8am to 6pm Pacific Time, but can make time pretty much any other days) I can set us up a call for us.
(03-13-2025, 04:37 AM)ekkomouse Wrote: There’s a definite bug when using two MRCC units and routing from one to another on usb, there are phantom routings that come back unintentionally, I think I’ve posted a couple videos already. Can you confirm that you’ve got this and understand?
https://www.dropbox.com/scl/fi/rj0y5923dwipv4rpnwbuz/phantom-usb-connection-on-dual-mrcc.mov?rlkey=p7h4qqnbvdvytqq7ftga5e49o&st=staswncq&dl=0
Got it. I am looking at some of this stuff today to try and reproduce it.
RE: MRCC Firmware Beta 1.1.089 - Jesse Johannesen - 03-13-2025
Quote:(03-01-2025, 02:24 PM)ekkomouse Wrote:OK so for this one, the video doesn't show the MRCC doing anything funky. I recreated the issue by sending MRCC internal clock on PC port 1 of unit 1 to the USB host C port of unit 2 Factory restting unit 2, I still see Red Clock Arrows on the display. I think this is the expected behavior, as I get the same results from sending via DIN as well.
Separately I have an issue where I have a routing where clock is going from MRCC one to two, MRCC 2 Is sending clock back to a remote routing on 12 unintentionally when it’s not assigned , The only way I can stop it is to filter on the outport page.
https://www.dropbox.com/scl/fi/nv8podofy...ksdrs&dl=0
Not to say the issue you're reporting doesn't exist, but what is shown in the video doesn't illustrate an issue as far as I can tell.
If you were to factory reset the MRCC that is the clock source and it still showed red arrows on the destination then we would be looking at an issue, but here you are factory resetting the destination unless I am misunderstanding?
(03-13-2025, 02:54 AM)RadekPilich Wrote: My SL has two outputs, they are simply wired into DIN INPUT 1 & INPUT 2 and then straightforwardly routed into 1 to 4 outputs each, both DIN & USB.
Oxi is routed in the same manner, but has 3 OUTs, that go through expander DINs that is connected to USB1. This is a workaround, because the direct OXI-MRCC USB connection can currently handle only 2 rather then 3 outs.
The outputs of the SL / OXI are "synth groups" - out 1 = monos, out 2 = polys, out 3 for add-hoc routing into drum machine / grooveboxes.
Outs from MRCC are similar, but sub-groups in nature - i.e. OUT1 monos on the left side, OUT 2 monos at the right side, same with 3 and 4 for polys, 5 is digitakt, etc.
Got it. A couple things we can do to pin down the issue:
1 we can try and capture the output of the SL3 in MIDI Ox to see what data is being sent when that hold button is pressed
2 we can try to replicated the issue with simplified setup by loading a factory preset and attempting to send only those notes to a single destination and see if it is reproducable.
for the OXI can we try it without the Xpander and see if the problem persists with a direct connection?
RE: MRCC Firmware Beta 1.1.089 - RadekPilich - 03-13-2025
OK, will try to reproduce with factory default.
Both SL & OXI can output the same thing on all outs, so I can connect them to computer (either via USB or via other MIDI interface) and capture the same thing that goes to MRCC.
btw. can't we provide you with our present? wouldn't that be helpful for your analysis? do you have some logging / service viewer to see what's happening? I don't see anything unusual when looking at the MRCC monitor before it freezes.
RE: MRCC Firmware Beta 1.1.089 - Jesse Johannesen - 03-13-2025
It's possible to remove the internal SD card and collect the save data to send it to me, but it's way too much work, it's invasive, requires a hex wrench, and probably wouldn't help. The purpose of simplifying is mostly to remove the possibility of user error. The more complex the setup the harder it is to be sure that some overlooked error is influencing the scenario in an unexpected way. By taking away all the other variables we can eliminate a lot of the possibility for those errors.
In this case playing three notes into a DIN input should never be an issue, we can send 40notes from a NDLR pad into an input without any problems, so something else must be happening when we press the hold button.
(03-13-2025, 08:18 AM)ekkomouse Wrote:(03-12-2025, 11:07 PM)Jesse Johannesen Wrote: Can you tell me how the MIDI is routed to the MRCC from the SL3? Is this a USB issue or a DIN MIDI issue?
(03-09-2025, 04:22 PM)RadekPilich Wrote: My MRCC keeps freezing. Less then before during normal operation, but still sometimes I found it frozen for unknown reason.
Besides that, today I froze it many times when sending MIDI LFO's from Oxi One through it.
Seems that not only MIDI loops freeze it, but also MIDI flood of a lot of messages.
Additionally, I've found out that with really fast LFOs on OXI, the MIDI que gets so big that it's not processed in real time anymore and and there is a delay to notes and everything.
I have to do a bit more investigation thought, whether the issue is already in Oxi, in MRCC xpander, or MRCC itself.
Thanks for the report.
It is definitely possible to flood the MIDI buffers with events. I think we've seen it with poly aftertouch in some fringe cases with a ton of other data being sent. I've asked the team if we have data on those buffer limits.
I think it was also mentioned with the expanded number of routings possible, that at some point it would become probable that you may run into some limitations to the amount of DATA being sent.
It would also always be helpful to know when reporting issues how things are connected and if we're discussing DIN or USB MIDI connections.
(03-12-2025, 04:55 AM)ekkomouse Wrote: Im curious if you could give some information on what happens when we plug in to an input or output that has both TRS and DIN, using two cables and plugging both types in as if it were a merge. I experienced some issues doing this so I stopped using both inputs simultaneously on the input of MRCC USB expander. But I have been doing it on the MRCC itself.
Inputs and outputs are both linked, and as a result, if 2 connected inputs receive data at the same time it becomes garbage, (it might even be a problem to have them both connected but not sending data) but two outputs can be used at once without any issues.
OK I understand the merging aspect isn’t there, I was getting some kind of additional voltage that was causing an MPC not to be able to boot correctly, does this sound correct? MPC was hooked by DIN and push three was hooked to the TRS, on USB expander input A.
I can't imagine what might be happening that would prevent the MPC from booting, but anything's possible.
RE: MRCC Firmware Beta 1.1.089 - RadekPilich - 03-13-2025
(03-12-2025, 03:13 PM)RadekPilich Wrote: @Darryl Here is one 100% repeatable way to freeze MRCC.
I did further testing after the recording and I can freeze it messing only with 3 notes. And the more notes I add the faster I can freeze it
Alright, I have gone through the troubleshooting.
THE PROBLEM IS THE EXPANDER!
Everything else holds fine, but once I route via USB out to the ecpander, the expander crashes with banging the latched keys.
The LED on the expander goes dim blue, no flashing anymore once frozen.
-------
DAMNIT, IT'S A CABLE PROBLEM!
I use one short USB reductions for flat cabling on the MRCC front panel. So the expander is connected through two cables.
Once I connect it directly, I cannot crash it.
RE: MRCC Firmware Beta 1.1.089 - RadekPilich - 03-22-2025
(02-25-2025, 12:24 PM)Jesse Johannesen Wrote: I have tested and confirmed the issue exists here as well, so it's probably something we can sort out in the next release. It seems to only be affected by DIN to DIN routings, PC to DIN seems OK
Thank you for doing such a great job testing this!
Jesse, I just stumbled upon this Faderfox sysex issue once again. Turns out it is affecting DIN to USB routings as well.
As previously, there is a workaround - the mapping to the most right port is the one that breaks, therefore the desired target device must be on ports A/B/C and there must be additional routing done the D that "consumes" the problem.
Any updates on a release of a fix for this?
RE: MRCC Firmware Beta 1.1.089 - Jesse Johannesen - 04-28-2025
Thank you for reporting that I'll pass the info along. I don't have any word yet on an update but I'll ask.
RE: MRCC Firmware Beta 1.1.089 - User - 05-12-2025
I'm using version 075 from 08-23-2023 - is already secure to start using version 85? I'm using it dawless, will anything significant may stop working in my setup?
RE: MRCC Firmware Beta 1.1.089 - Jesse Johannesen - 05-16-2025
(05-12-2025, 06:37 AM)User Wrote: I'm using version 075 from 08-23-2023 - is already secure to start using version 85? I'm using it dawless, will anything significant may stop working in my setup?
I'm pretty sure there are one or two minor bugs present in the latest build, but I think they may also be present in 075. I don't think anything will impact stability that isn't already, so you should be good to try it out. Either way, you can always revert to a previous build if you run into anything you don't like.
RE: MRCC Firmware Beta 1.1.089 - RadekPilich - 09-05-2025
Not sure if it is a beta thing or if it has always been like that - the expanded views on activity monitor don't work for me. For example when I open the detailed view for USB ports, it shows a frozen state from the moment I have opened that view, but it doesn't update. Is this a known issue / bug / limitation?