Older Firmware Releases

[ekkomouse]

As a followup, on MacOS 12.6.1 I keep getting multiple MRCC USB devices showing up in Audio/Midi Setup, which causes the MRCC port names to change within that Bome Network. Sometimes I am able to get it to return to the old deactivated midi device by turning off MRCC, deleting the new midi device in MacOS and turning on the MRCC, at that point it may communicate that its the old device. There may be something off with the initial handshake in MacOS.

So requesting user customized port names. And/or better defined port names within MacOS so 3rd party software/MacOS doesn't think they are all named the same and define its own name. And a way not to have multiple MRCC midi devices show up in settings so if the first two requests aren't possible, we dont have to keep troubleshooting 12 PC/DAW ports to find which one the assignments have changed to.

We've been selling MRCC for a couple of years now and have a lot of mac users that are not having a problem that we know of, though I remember this being reported once before. There must be something going on different here. Is this a macbook? If you disconnect it without turning off the MRCC, maybe its not automatically removing it from its USB device list? Have you used the MRCC feature to change the name of MRCC? If so, turn off MRCC, delete MRCC from the audio/MIDI settings, then change back to the original name of "MRCC", SETTINGS page 4. Would be curious to see if that has anything to do with this.

Also, beside the BOME software, other programs get the ports numbered correctly. We've contacted BOME and looking into it.

No I haven't changed the name of MRCC, most of my Mac software has no issue keeping the ports in order, but they do still mostly only display "MRCC" as the port without numbers (Komplete Kontrol, Maschine comes to mind), but they are in numerical order in a list so its a small amount of effort to count down the list to the port number. When I tried Bome Network, this issue arose, and Bome said it was due to a difference in how they read the Port names given by the MRCC, they said there were a couple ways to read port names, maybe each way can be updated to show actual port numbers, which would cover both any Bome network usage and my other software, ie Komplete Kontrol, Maschine which only displays "MRCC" for each port number. Really would prefer custom names to match my name assignments inside MRCC though. 

I am also chasing down a separate midi issue and noticed that in the beta when I display the Activity Screen Page for the PC assignments, if I select any PC port it displays that all ports are selecting that output. In the pics, I have assigned PC 5 to Din out 1,2,3,4 and PC12 to Din 2,4,6,8. But it looks to me like all PC ports are assigned to output to DIN 2,4,6,8 and PC Ports 1-5 are assigned to output to Din 1,2,3,4,5.  Am I reading the activity screen wrong? I thought each row from top to bottom represented PC 1-12 and each column from left to right represented Din 1-12, then USB A-D, Then PC Out 1-2 on the final column. 

If Im right, is this just a display bug or is it sending midi on all of those lit outputs in the activity screen? See pics: 
   
   
   

---

Also im noticing some midi clock jitter, coming from a midi sequencer through the MRCC by way of USB, out to Midi Din and Maschine software on Mac, I am getting .1 to .2 bpm of jitter, but when going direct from sequencer, It is less or not showing on some devices. Is this a normal amount? During this test I was only sending clock to 2 devices, still trouble shooting some hanging notes so narrowing down my issues.

[Jesse Johannesen]

Hey ekko-
As far as I can see there would be no way to edit the USB port names once the device has been connected, so if we were to devise a way to label the ports, then once connected any changes to presets could potentially cause the port names to no longer reflect the names you expect. While I can see the utility of the request, I could see it causing lots of confusion. Maybe you could request on the Apple end to see if they can find a way for you to be able to label those ports in their software?

With regards to the Activity screen, that sounds suspiciously like a bug, I am out of town this week so I can't try it on my unit but once I'm back at home I'll see if I can repro it and let you know. There shouldn't be a way to route all PC ports to a single port without going through and doing it for each routing, though, so seems like something is off. Possibly just a bug in the display data though, can you test it and see if any MIDI routes through from one of these unintended routings? That would answer that question.

---

I must admit I don't have any info on clock jitter, however I do know that the method employed for all of our devices is intended to be dead solid. If you are getting clock jitter it may be worth looking at what data is being sent. We recently had an issue reported where unexpected behavior was caused by massive blasts of Sysex data being spammed. If it's not that it may be down to some minor USB incompatibility. What device is this? If I can find one over here I can have Darryl take a look at it.

---

Now that I say that, I realize that I am discussing the internal clock, not external MIDI pass through, although to give you some idea about the the processing overhead on the device, we blasted the MRCC with data while testing processor downtime, expecting we may get up towards the maximum level of activity, and found that we don't even break the 10% mark. In other words everything happens so fast in the MRCC that even when it's processing enormous amounts of data it doesn't break a sweat, and spends 90% of its time twiddling it's thumbs waiting for more data. Even the Sysex issue mentioned above was probably not due to slowing down the processor, but likely due to hitting the hard limits of MIDIs inherent data rates, thus too much data could have an effect, just not due to limits internal to the MRCC.

I don't know if our testing utilized the Host ports or just the PC ports, but we did run a ton of round trip data logging from the computer through the MRCC and back out to the PC. The average round trip was about 1-3ms if memory serves, so that's maybe 1.5 ms from the PC to the output port in the worst case.
OK I found Darryl's message to me:
"The MRCC adds about 1ms latency. The range is something like 1ms to 3ms for a 3 bytes MIDI message in round trip testing. Windows adds latency and jitter and that can vary from system to system. The theoretical best case for a byte sent at 31,250 BPS (MIDI speed) is 1ms. "

I'm not sure if this info is totally relevant or not, but figure it's best to provide as much info as I have and see what helps.
Anyway, I will ask Darryl if he has any suggestions for things to look at as well, and will report back if he has something to add.

[Darryl]

Regarding the Activity matrix, Steve is looking into it as that data did not look right. Thanks for the screenshots.

[Darryl]

Regarding the Activity matrix, Steve is looking into it as that data did not look right. Thanks for the screenshots.

We're testing the fix now and will have an update shortly.

[ekkomouse]

Hey ekko-
As far as I can see there would be no way to edit the USB port names once the device has been connected, so if we were to devise a way to label the ports, then once connected any changes to presets could potentially cause the port names to no longer reflect the names you expect. While I can see the utility of the request, I could see it causing lots of confusion. Maybe you could request on the Apple end to see if they can find a way for you to be able to label those ports in their software?

I would think most people setup the MRCC and usually leave the same inputs and outputs connected, maybe changing when new equipment is added. Since we name them in the preset that name should carry to MacOS, for macOS to read the new names, All you have to do is delete the midi device in audio midi settings, while the MRCC /device is turned off and then turn it on again, port names get pulled in. That is how Apple allows transferring port names on devices that can be renamed. It’s not confusing on the MioXL or Disting which allow device renaming. 

 Possibly just a bug in the display data though, can you test it and see if any MIDI routes through from one of these unintended routings? That would answer that question.

Yes I’m intending to check it, it may take several days.

I must admit I don't have any info on clock jitter, however I do know that the method employed for all of our devices is intended to be dead solid. If you are getting clock jitter it may be worth looking at what data is being sent. We recently had an issue reported where unexpected behavior was caused by massive blasts of Sysex data being spammed. If it's not that it may be down to some minor USB incompatibility. What device is this? 

It’s a squarp hapax sending clock through a fore midi to usb converter into the MRCC usb ports, out to DIN midi to an Oxi one, NI maschine, ableton live, and other outs. It’s .1 to .2 bpm jitter, until I take Hapax from Din out to MRCC DIN IN to Din out to other devices . Usb seems to have more jitter. I just wonder if that’s typical or not. if my math is right .1-.2 bpm is more than 3ms. I was at 120-152 bpm.

[Jesse Johannesen]

I would think most people setup the MRCC and usually leave the same inputs and outputs connected, maybe changing when new equipment is added. Since we name them in the preset that name should carry to MacOS, for macOS to read the new names, All you have to do is delete the midi device in audio midi settings, while the MRCC /device is turned off and then turn it on again, port names get pulled in. That is how Apple allows transferring port names on devices that can be renamed. It’s not confusing on the MioXL or Disting which allow device renaming. 

Regardless, the process would be hack-y since it wouldn't be an immediate change, and would require you to power cycle or disconnect and reconnect from the computer, and would likely require users to delete the previous instance of the MRCC in the MIDI control center. It would represent too many potential missteps that could cause problems for the benefit. It just doesn't seem like a good idea to put people in that position, I'm sorry to say. 


I was able to reproduce the issue on my end with the Port Activity display, but it looks like Steve and Darryl beat me to it and it sounds like it's probably been fixed. I'll test it out shortly and we can most likely get it confirmed and posted without much delay. Thanks for the tip!

As for the jitter, I can discuss it with Darryl and see what he thinks.

[ekkomouse]

MacOS would read custom names for people who wanted it and for those who don’t, they can use factory port names. It’s a one time delete and restart to refresh midi settings, it’s pretty simple. Anyway if no custom names, can you number them so port numbers can be differentiated in software? See prior screenshots of Komplete kontrol, it’s same in Maschine software, midipipe and bome also, port numbers are missing.

Separately I have had two Transpose settings in mods and they are not saving with the preset, they are supposed to save right?

[ekkomouse]

Ok its definitely not saving/loading transpose settings for TP2 correctly. I have TP1 set down 12 semitones and TP2 setup up 12 semitones. Save preset in U3 and A3, neither retains the TP2 setting, only TP1 setting.

[Dark Waves]

To follow up on previous posts here, I'm still experiencing identity confusion in Windows 10 with my two MRCCs.  Currently, as of March 19, I'm on the latest FW on both, v1.1.071, and I have been keeping up with each beta over time.  For the most part, device recognition often persists for a few sessions, but not always (if I had to estimate, maybe 2 3rds of the time.  Sometimes rebooting the PC helps to return to the last set of port names, but not always, and just closing and relaunching the DAW,  Studio One, has no effect.  My usual practice is to have the MRCCs and all other peripherals booted and connected prior to starting the computer, as this tends to give the best chance for consistent results.

I hope these images will show up, they show how the units are differentiated at different times, and were all taken in the last couple of weeks, since updating the last time.  In case they aren't viewable, the names vary between MRCC / MRCC (2),  MRCC-A / MRCC-A (2), and MRCC-B / MRCC-B (2).  Previously there had also been other variations.  To clarify, all of these changes are functional if selected in the DAW, but this would be quite tedious as each device using a virtual port then must individually have an assignment made to match the current set of choices.

Edit for detail: The names MRCC-A and B are what I've entered on the units under "PC Name" on page 4/4 of settings, which is how they've been set for a long time.  What's picked up by the computer is never both of these together, just one of them, or without a suffice, with the (2) assigned instead to one.





https://www.dropbox.com/s/174ryob41znjb4....jpeg?dl=0
https://www.dropbox.com/s/q1nebucc3od429....jpeg?dl=0
https://www.dropbox.com/s/ncggr0idftlxjm....jpeg?dl=0

[Jesse Johannesen]

Ok its definitely not saving/loading transpose settings for TP2 correctly. I have TP1 set down 12 semitones and TP2 setup up 12 semitones. Save preset in U3 and A3, neither retains the TP2 setting, only TP1 setting.

I was able to reproduce the issue on my end. Looks like TP2 is the only one affected. I've asked Steve to take a look, until then avoid TP2 if you'll want to reload from a save. Thanks for the report.