MRCC Firmware Release 1.1.095

[Darryl]

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

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.

If possible, it would be helpful if you can capture the output of your controller so we can try sending all of the MIDI data to test it. Not just the SysEx, but the whole list of commands. I'm wondering if there's a problem caused by switching presets, which can take a little time to load. Is there any delay between the Program Change and SysEx output?

[RadekPilich]

If possible, it would be helpful if you can capture the output of your controller so we can try sending all of the MIDI data to test it. Not just the SysEx, but the whole list of commands. I'm wondering if there's a problem caused by switching presets, which can take a little time to load. Is there any delay between the Program Change and SysEx output?

I've added the setup group switch SysEx to the original post.

I'm not sure what Program Change are you talking about, I'm not doing any program changes in this case.

The SysEx coming out of Faderfox is not user intended - it's just some Faderfox stuff that probably communicates to the editor / software to let it know, that setup group has been changed on the device. But it has nothing to do with the use case of MIDI controlling a synth.

-----

UPDATE: I've had a troubleshooting idea and consequently found a workaround. It seems that only last routing breaks. So I have added additional dummy routing to the currently unused OUT 12, which means that the broken OUT 11 works again 

[Jesse Johannesen]

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!

[ekkomouse]

I have updated to the firmware, I found an issue when using old presets, do you want me to describe it or are we supposed to let the old presets go?

---

Also would you be able to list all In Ports and Out Ports on the in port/out port filter page, its really necessary when you get up in devices as usually I filter by input port rather than specific routing, currently they are not all represented so some filtering is missing at all times.

[RadekPilich]

I thought ALL the I/O ports are on the I/O filter page. What is  missing there? I use that a bit and it works fine for me.

[ekkomouse]

on the in port filter page, by default you get one to 6, A, B, C 1-4 and D1-2, missing is D3-4, P1-12. 

on the outport filter page you get 1-12, A-D, P1-4, Missing P5 to 12. 

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

[Jesse Johannesen]

@ekkomouse
The port filter page allows you to select an input port per line, with the first column allowing you to select an input port. For convenience, each line defaults to a port listed in numerical order, however this was primarily to make it simpler to understand than leaving the port selection blank and forcing you to adjust it manually. You can simply go to the first port line that is not in use, and in the port column, use the encoder to select the port you wish to add a filter on, then if you need another you can go to the next line and do so again.

As for older presets, I think we expected them to still work going back several FW versions. If you want to you can send me an email with the details and we can take a look at that. I don't know what might be possible as far as fixing the issue yet, but I'm happy to take a look.

As for the clock issue in the video that is interesting, I should be able to repro that here and see if we can get it fixed next time we're looking at the code.
A

[ekkomouse]

@ekkomouse
The port filter page allows you to select an input port per line, with the first column allowing you to select an input port. For convenience, each line defaults to a port listed in numerical order, however this was primarily to make it simpler to understand than leaving the port selection blank and forcing you to adjust it manually. You can simply go to the first port line that is not in use, and in the port column, use the encoder to select the port you wish to add a filter on, then if you need another you can go to the next line and do so again. 

As for older presets, I think we expected them to still work going back several FW versions. If you want to you can send me an email with the details and we can take a look at that. I don't know what might be possible as far as fixing the issue yet, but I'm happy to take a look.

As for the clock issue in the video that is interesting, I should be able to repro that here and see if we can get it fixed next time we're looking at the code.
A

Yeah I’m familiar with being able to change which port is getting filtered, which brings up the issue when you are filtering one and then want to filter a different one on try he same preset, Since they’re not all represented, it’s an extra workflow which just seems like they should all be represented. Also, it would cut down on potential loops, as you Could definitively filter each input and output. 

my report on the preset is not really about saving the preset. It’s more about the issue of midi clock passing through when a routing hasn’t been created

[Raphie]

I prefer midi clock pass through as global default, I prefer to select clock behaviour on the end point, not the router

[Jesse Johannesen]

@ekkomouse
The port filter page allows you to select an input port per line, with the first column allowing you to select an input port. For convenience, each line defaults to a port listed in numerical order, however this was primarily to make it simpler to understand than leaving the port selection blank and forcing you to adjust it manually. You can simply go to the first port line that is not in use, and in the port column, use the encoder to select the port you wish to add a filter on, then if you need another you can go to the next line and do so again. 

As for older presets, I think we expected them to still work going back several FW versions. If you want to you can send me an email with the details and we can take a look at that. I don't know what might be possible as far as fixing the issue yet, but I'm happy to take a look.

As for the clock issue in the video that is interesting, I should be able to repro that here and see if we can get it fixed next time we're looking at the code. 

Yeah I’m familiar with being able to change which port is getting filtered, which brings up the issue when you are filtering one and then want to filter a different one on try he same preset, Since they’re not all represented, it’s an extra workflow which just seems like they should all be represented. Also, it would cut down on potential loops, as you Could definitively filter each input and output. 

my report on the preset is not really about saving the preset. It’s more about the issue of midi clock passing through when a routing hasn’t been created

Thanks, I agree, it is a little funky. 1 to 1 would be better. 

As for the clock issue, understood. I will try and repro this week and see what happens.