03-23-2023, 09:19 AM
(This post was last modified: 03-23-2023, 10:03 AM by 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.
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.