Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Troubleshooting - 2 MRCCs, midi clock, ?
#1
And I apologize for the negativity of this post. As I mentioned to a friend, i wouldn't hate the MRCC so much, if i didn't love it so much. I have come to rely on it. Most of the time it is just second nature now. But then when there is an issue, there really aren't handy tools to troubleshoot it. I know that I, and others, have asked for, in various contexts - some kind of way to run a computer application and look at connections - in this particular case, i would want to get some clue as to what is failing and why.

Of course, when troubleshooting, one has to consider what was working 'yesterday' and what one has changed since then.

In this case, being reticent to spend more than the couple of hours i've already spent tonight, I have reached some tentative conclusions that i realize may be a misinterpretation or oversimplification of the symptoms.

I have 2 mrccs. They generally work great together. But what is happening tonight is that (forgive me if i forget the name of the mode) - the mode where you can see the outputs of the other mrcc, and then connect and disconnect them, becomes totally unresponsive. This (which i guess makes sense) seems to happen simultaneously on both of them Tonight, i am having to reboot the computer and also the mrccs (might be doing more than necessary here, but this is gentler than throwing the mrccs out the window. And i'm not endangering lives)

this was not happening yesterday. What did i change? The first of the changes doesn't seem to be the issue - i plugged in another usb device. But unplugging it had no affect on the issue at all.

the other was that I connected a clock device (S.N.D Acme 4) via a din connection. Everything seemed to work great, and still did when I sent clocks to a din connected sequencer on the other mrcc. Beautiful. But things started going astray (in retrospect) when I sent the clocks to a sequencer connected on the usb port of the other mrcc. Maybe just coincidence, but i have repeated that things crash when i send it clock, but then when i do not, no problem. I suppose that the solution is obvious (unless of course this is a mistaken diagnosis). The usb device, which until just now has worked great on the mrcc, is the Hapax sequencer.

I suppose that the general question is - have there been any issues with sending midi clock to a usb device on another mrcc?

Does this diagnosis make sense? I know that there are issues with how much power usb devices can take on a given mrcc, but in this case the thing has worked just great until now. And there is only one other usb device hooked up to that mrcc.

but yeah - the symptoms - the sync stops working, the interconnectivity mode stops working (neither mrcc seems to see the other) and the damn things then don't even fully reboot.

thanks.
Reply
#2
Hey Nelson, I'm sorry to hear that mate, it seems like you're looking at the situation with the right things in mind, (what changed etc.). As for that mode, let's call it Remote Routing Mode for now. When this (Remote Routing is unresponsive) is happening is everything else on the MRCCs still working? Does pressing the Y guy button cause the remote routings to show up yellow on the LEDs still, so it looks like you should be able to make changes?

We have seen failures with one unit when sending to a or from USB host port device that isn't fully compatible with the MRCC, I have had the Digitakt cause my MRCC to freeze for instance, and when that happens in a scenario with 2 MRCCs I could imagine it requiring a reboot to get things back up and running between them. In my case, the Digitakt didn't work via USB at all initially, but their newest FW update seems to have changed that, and now it works...if I don't send clock or whatever the triggering issue was. In the past I think we were seeing a similar thing with the OXI we were testing, and were able to send the Dev a message as to what error we had found to be causing the issue in their USB implementation and I think they were able to get it solved in a firmware update (It may be that the issue was partially addressed, I don't have one so it's not something I ever experienced personally, the situation was related to me anecdotally). The DIN ports are almost 100% guaranteed not to be problematic, so that will help us narrow down the issue hopefully, but what are the devices connected to USB that you were sending to?

I am always available to set up a video call if you would like to have an extra set of eyes on the issue, feel free to send me an email at Support@conductivelabs.com with your availability and timezone and I can send you an invite at a time that works for us both.

Jesse
Reply
#3
(01-06-2023, 08:18 AM)Jesse Johannesen Wrote: Hey Nelson, I'm sorry to hear that mate, it seems like you're looking at the situation with the right things in mind, (what changed etc.). As for that mode, let's call it Remote Routing Mode for now. When this (Remote Routing is unresponsive) is happening is everything else on the MRCCs still working? Does pressing the Y guy button cause the remote routings to show up yellow on the LEDs still, so it looks like you should be able to make changes?

We have seen failures with one unit when sending to a or from USB host port device that isn't fully compatible with the MRCC, I have had the Digitakt cause my MRCC to freeze for instance, and when that happens in a scenario with 2 MRCCs I could imagine it requiring a reboot to get things back up and running between them. In my case, the Digitakt didn't work via USB at all initially, but their newest FW update seems to have changed that, and now it works...if I don't send clock or whatever the triggering issue was. In the past I think we were seeing a similar thing with the OXI we were testing, and were able to send the Dev a message as to what error we had found to be causing the issue in their USB implementation and I think they were able to get it solved in a firmware update (It may be that the issue was partially addressed, I don't have one so it's not something I ever experienced personally, the situation was related to me anecdotally). The DIN ports are almost 100% guaranteed not to be problematic, so that will help us narrow down the issue hopefully, but what are the devices connected to USB that you were sending to?

I am always available to set up a video call if you would like to have an extra set of eyes on the issue, feel free to send me an email at Support@conductivelabs.com with your availability and timezone and I can send you an invite at a time that works for us both.

Jesse
I appreciate the response. I should reiterate that I don't know for sure whether the components that i mentioned were all that were involved with the issue. I know someone who tried something similar with the hapax and didn't replicate this. I do know that since reconnecting the hapax with a din connection, things have been ok, and i already had pretty much resolved that simply a midi clock between the 2 mrccs wasn't the issue. As far as the 'y guy' - the connections seemed to dissove....at first stuff didn't seem to be working (wish i had a better memory), and then each mrcc wouldn't see the other when i tried to establish the Y connection, and ultimately the mrccs were frozen. BUT, i am disinclined to spend more time and stress on this. ultimately, when i am done with work, i want to make music, and i think that my biggest point is that what i think is needed is a better way to troubleshoot mrccs especially in complex set ups. Whatever can be done with some kind of computer application that would look at the active connections, etc. It is just difficult and time consuming to troubleshoot. For me, at least. While i much prefer the mrcc midi hook up, when using a midi interface, it is easier to see all of the active connections (because, well, they are set up in Live, for instance). I understand that it's built into the concept, but i am still not convinced that a computer application is impossible.
Reply


Forum Jump:


Users browsing this thread:
1 Guest(s)