MRCC Firmware Release 1.1.095

[Darryl]

OK sounds good. I will test it when it’s posted. 

Today I was realizing I’m not able to name remote outputs when using a dual MRCC setup. So I have a few requests related to output naming. 

1. There needs to be a global naming configuration, I imagine most users don’t do a lot of swapping where it’s needed per preset, But maybe there’s a few users that do need that. So I suggest a global name pool for inputs/outputs, With a flag in settings per preset to override global names, which then imports the global name pool and allows the user to change per preset like currently.  This way when adding a device and assign to an output or name changing outputs/inputs, we don’t have to update each user preset individually, As well as the pool of names.  

2. In a dual MRCC set up they Should share their name assignments, So when assigning remotely, you see the name, Currently, it just says none.

1. Not sure I follow... Are you saying that rather than a per-patch port label, you want to save a global port label patch that loads all of your label assignments? 
You can kind of do this by labeling your ports and save it in a patch. Then before making a new patch, load the patch with label assignments first, make your routings then save it to a new patch. Of course you can make more than one of these if there are some common configurations, and add common routings, filters, etc. so you don't have to do it from scratch. With 127 patches available, even saving a patch just to relabel one port name is doable. Then just switch between the patches.

2. Good idea, we talked about it in the past and it's still on the backlog. However, it's quite a lot of work so we've been prioritizing more urgent things, but it's good to see a vote for implementing it.

[RadekPilich]

The problem ekkomouse is pointing at is this:
- you have pretty much stable physical config
- you use multiple presets
- you buy new gear -> you have to go to each preset and do the labeling for the new gear

Not ideal, but he's mostly right - how many people do change the physical setup to fit what is set in a present?

The settings would be better structured as 8 physical configs each with 16 routing configs.

---

Btw. I'm still experiencing quite a lot freezes and I have no idea how to debug / troubleshoot it, because most times I don't catch the exact moment when it happens.
I'm quite sure though, that it's better to turn on all the hardware first and MRCC last, because turning on additional boxes while the MRCC is already running is more likely to cause a freeze.

[ekkomouse]

OK sounds good. I will test it when it’s posted. 

Today I was realizing I’m not able to name remote outputs when using a dual MRCC setup. So I have a few requests related to output naming. 

1. There needs to be a global naming configuration, I imagine most users don’t do a lot of swapping where it’s needed per preset, But maybe there’s a few users that do need that. So I suggest a global name pool for inputs/outputs, With a flag in settings per preset to override global names, which then imports the global name pool and allows the user to change per preset like currently.  This way when adding a device and assign to an output or name changing outputs/inputs, we don’t have to update each user preset individually, As well as the pool of names.  

2. In a dual MRCC set up they Should share their name assignments, So when assigning remotely, you see the name, Currently, it just says none.

1. Not sure I follow... Are you saying that rather than a per-patch port label, you want to save a global port label patch that loads all of your label assignments? 
You can kind of do this by labeling your ports and save it in a patch. Then before making a new patch, load the patch with label assignments first, make your routings then save it to a new patch. Of course you can make more than one of these if there are some common configurations, and add common routings, filters, etc. so you don't have to do it from scratch. With 127 patches available, even saving a patch just to relabel one port name is doable. Then just switch between the patches.

2. Good idea, we talked about it in the past and it's still on the backlog. However, it's quite a lot of work so we've been prioritizing more urgent things, but it's good to see a vote for implementing it.

Yes mostly global naming as Radek mentioned, our presets have to be changed if we add a new device. I say mostly because I imagine some people probably use per preset for various setups so it can’t be fully global. Or a copy names from preset x function could work too. Also, more name slots or let us overwrite the factory ones as they are not used. I actually ran out of name space recently, I suspect if we name all inputs outputs, usb, pc names it may not allow enough. I managed to delete some of mine but I didn’t think there would be a limit

[Darryl]

Alright, thank you for the explanation, it makes sense to us now.

[Darryl]

Just posted, MRCC beta firmware update.
1.1.086 Release Notes Here

[Darryl]

[quote pid="7900" dateline="1738631418"]

1. Darryl
   

I just loaded the new firmware, right off the bat the mrcc names for A/B/C/D are not recognized by the computer, so I have downgraded as I can't test my dual mrcc setup with names that can't be recognized, it breaks all of my computer Bome network routings. Ableton projects with saved routings, and the names are not matching settings when viewed inside DAWs. Let me know if you get that sorted and I can try again.

There are some complexities when it comes to USB device naming. The operating system will cache the USB device names, so you can't just change the name setting and see the change. When the firmware is updated, it might see the MRCC as a new device and that's what messes up the naming. On Windows, there are a couple of ways to clear that cache, then get the OS to learn the new name after a reboot, so the name you select will be learned after a reboot. 

I thought I wrote up some instructions for that somewhere but can't find it at the moment. I'll take a look when I'm in the office next week, or write new instructions in an FAQ and post it here. Otherwise, there's nothing in the new firmware that should affect that USB device naming, but we did update the USB device firmware to the latest version, so it could be something unexpected is happening. We'll check it out.

ok, thanks for the reply, if you recall, we had this issue before and an update was made to address it. The prior issue was the device name would not match settings and when network or port routings were made, they would have to be redone every power up due to the device name not populating correctly in Mac os

We've been looking into the USB device naming some more. We didn't change anything that should have effected it's functionality, however, what we did before was a change to address a race condition. It's possible that the new libraries caused the condition to worsen. We took a deep dive into the USB device code and came up with a better solution for dynamically setting the USB device name which completely eliminates the race condition. We should be ready to post that here later this week.
[/quote]
The USB device naming is fixed in the latest beta. We’ve tested it pretty thoroughly, and will post it as a release after a few folks have tried it. See top of this thread for complete release notes and link.

[ekkomouse]

[quote pid="7900" dateline="1738631418"]

1. Darryl
   

I just loaded the new firmware, right off the bat the mrcc names for A/B/C/D are not recognized by the computer, so I have downgraded as I can't test my dual mrcc setup with names that can't be recognized, it breaks all of my computer Bome network routings. Ableton projects with saved routings, and the names are not matching settings when viewed inside DAWs. Let me know if you get that sorted and I can try again.

There are some complexities when it comes to USB device naming. The operating system will cache the USB device names, so you can't just change the name setting and see the change. When the firmware is updated, it might see the MRCC as a new device and that's what messes up the naming. On Windows, there are a couple of ways to clear that cache, then get the OS to learn the new name after a reboot, so the name you select will be learned after a reboot. 

I thought I wrote up some instructions for that somewhere but can't find it at the moment. I'll take a look when I'm in the office next week, or write new instructions in an FAQ and post it here. Otherwise, there's nothing in the new firmware that should affect that USB device naming, but we did update the USB device firmware to the latest version, so it could be something unexpected is happening. We'll check it out.

ok, thanks for the reply, if you recall, we had this issue before and an update was made to address it. The prior issue was the device name would not match settings and when network or port routings were made, they would have to be redone every power up due to the device name not populating correctly in Mac os

We've been looking into the USB device naming some more. We didn't change anything that should have effected it's functionality, however, what we did before was a change to address a race condition. It's possible that the new libraries caused the condition to worsen. We took a deep dive into the USB device code and came up with a better solution for dynamically setting the USB device name which completely eliminates the race condition. We should be ready to post that here later this week.

The USB device naming is fixed in the latest beta. We’ve tested it pretty thoroughly, and will post it as a release after a few folks have tried it. See top of this thread for complete release notes and link.
[/quote]
Thanks I was gonna try it during the beta. I saw the message yesterday

[RadekPilich]

i'm experiencing some wierd bug, where MRCC stops routing to OUT 11 when I switch group on Faderfox EC4.
I have 40 something routings.
Faderfox goes IN 6. Then routed to 3,4,5,6,11.
Initially it works. When I switch group, I can see on the monitor then it is only sending to 3,4,5,6, but the main routing screen still shows as if the messeges were going to 11 as well. I don't see any special message on the monitor when switching Faderfox group.

[Jesse Johannesen]

i'm experiencing some wierd bug, where MRCC stops routing to OUT 11 when I switch group on Faderfox EC4.
I have 40 something routings.
Faderfox goes IN 6. Then routed to 3,4,5,6,11.
Initially it works. When I switch group, I can see on the monitor then it is only sending to 3,4,5,6, but the main routing screen still shows as if the messeges were going to 11 as well. I don't see any special message on the monitor when switching Faderfox group.

That is weird. With the way you have it set up normally, can you go to the routing page for 6>11 and see if it shows MIDI data on that routing specifically rather than the main routing general overview page.  Can you try it with just port 11 and see if it changes. Also when you mention the monitor, are you meaning the MIDI monitor in the tools menu? If not can you try turning that on and taking a peek? 

What is the destination on port 11? how are you confirming that MIDI isn't being sent?

Is it possible that the MRCC is loading a different preset when you press that button? The MRCC ctrl channel takes PC messages and loads saved routings. It's default set to off, but it would be worth checking. Maybe set that to a port other than 6 and see if that solves the issue as a test. (it's probably set to "-" so you may just set it to port 2 or something temporarily to test).

[RadekPilich]

There is no other issue, I have verified other possible causes. 

I wasn't aware there is additional "monitor" on the routing screen! 

I can see the that switching group on Faderfox actually produces some output. 

Here is the message: 

0 > sX

   

After that, the matrix and routing monitors continue to act normally, but the monitor tool + the actual connected devices don't indicate any further messages occurring.

---

I will catch the SYSEX message on the computer and pay it here. 

TBD / Here it is - 3 consequent group switches on the Faderfox.

Code:

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT               
0000959F   3  --     F0  Buffer:    14 Bytes   System Exclusive     
SYSX: F0 00 00 00 4E 2C 1B 4E 28 16 4E 24 13 F7
0000B3D9   3  --     F0  Buffer:    14 Bytes   System Exclusive     
SYSX: F0 00 00 00 4E 2C 1B 4E 28 16 4E 24 12 F7
0000CFC1   3  --     F0  Buffer:    14 Bytes   System Exclusive     
SYSX: F0 00 00 00 4E 2C 1B 4E 28 16 4E 24 17 F7

Also I should note, that it was working alright in the previous beta, so it most likely has something to do with the sysex adjustments in the most recent beta.