On the routing config page; tab to the input port, turn encoder lights cycle to the input port selected - that works. However, if I tab to the output port I cannot cycle through ports with the encoder.

On another note; the encoder has the same issue as the NDLR had; Sometimes a notch turn does nothing and you have to dial another notch in to get what you wanted. This isn't as big a deal as it was on the NDLR but it's still a little annoying and surprising to see the same issue on another product.

  MRCC_v1.1.068_12-07-2022.zip (Size: 284.41 KB / Downloads: 89)
MRCC_v1.1.068
This beta has not had extensive testing, but we would appreciate any feedback specific to the below changes if you are willing to give it a try! Please keep discussion of the beta release in the MRCC Open Beta Forum. Thank you!

Features:

1. Added current Preset Name on Load/Save screen
   
2. Added screen idle timeout to prevent OLED burn-in. The "Screen Off" time can be set on Settings page 2. The screen will sleep when MRCC is "idle" (no MIDI notes). However, the idle timeout reset ignores Clock, ActiveSensing or TimeCodeQuarterFrame MIDI messages and will timeout despite those messages being present. Tap the green button or any other button to turn the screen back on.
   
3. In Channel Map modifier: added a new Chan Source = "-" (none) in lines 2-4. This enables a bunch of Channel mapping possibilities.
   
4. Removed the SHIFT+ required in SAVE / LOAD 'ing presets (no safety on the preset overwrite!!!). 
   

1. Major overhaul of System Exclusive (SysEx) message handling. MRCC should be able to handle any length data to all possible out ports including MRCC to MRCC & MRCC to Remote 7. Please note: It is possible to overrun the MRCC's internal buffers when sending large SysEx files from very fast USB to very slow 5 pin DIN outputs. The sending software should throttle the speed it sends SysEx. Also note, if sending large SysEx files, be sure to temporarily turn off any other MIDI data sources. Once the internal buffers are full, MRCC will block MIDI data on merged inputs, but better chance of success if its not having to handle clock and other messages while the large transfer is happening.
   
2. The last selectable preset name was 128 (F25) - should have been 127 (F24)
   
3. Fix some Preset save issues. If you experienced an issue where after saving a patch, it changed back to Red from Green, this should fix it.
   
4. Activity Screen always shows the correct Preset Label
   
5. When routing remotely and holding the "Y" 5-Pin #1 is not showing MIDI activity
   
6. Fixed some User Label Save/Delete/Assign issues. 
   

  MRCC_v1.1.052_04-04-2022.hex.zip (Size: 250.84 KB / Downloads: 56)

• Modifier Ch Map "Exclusive mode" blocks clock (and likely all 1 byte msgs)
  
• Fixed some "if" logic issues for System Common & System Real Time messages so as not to be blocked
  

• 5-Pin MIDI now able to send SongPosition, TimeCodeQuarterFrame, SongSelect, & TuneRequest
  
• [i]SysEx now passes thru the Host ports![/i]
  

I've got so many interesting USB video game controllers that I feel like would be good midi controllers, but most ways to do so are software based and somewhat complicated to set up. I'm wondering if the MRCC could possibly help out as a compact hardware based solution.

Ok, I'll kick this off...

When I connect the host port to my Macbook I can't see anywhere in the Midi config of Ableton to select the MRCC as the "control surface" in order to route my midi messages from Ableton to the MRCC.

I can't find anything specific in the user manual, the device shows up in the Audio Midi Setup tool on my Mac, but not in Ableton for some reason.

Edit: Ok, now I go back to Ableton AFTER opening Audio Midi Setup -> Midi Studio view, Ableton shows all the ports available /shrug

Some hardware sequencers (for example Roland MC-707) cannot record sustain pedal midi data and some synths (for example Behringer VC340) cannot respond to sustain pedal midi data.  However, some styles of music feel unnatural or are impossible to perform on a keyboard without using a sustain pedal.

I think it should be possible for MRCC to have a modifier to convert incoming sustain pedal data (cc64) into something these other devices can cope with by simply delaying the note off messages of any notes being sustained by the sustain pedal until the sustain pedal is released, at which point MRCC would allow the note off messages currently in the buffer to be sent to the output.  Technically this would require the most recent value of the sustain pedal cc64 to be kept in memory so MRCC always knows whether the pedal is currently engaged.  Whenever a note off message is received at the input, the MRCC would check this memory to see whether the sustain pedal is currently engaged, and if so then it would delay the sending of that note off message and store the note off message in memory until the sustain pedal is released, at which point any queued note off messages would get sent to the output and removed from the memory.

I think this simple logic would cope with notes that began being held down either before or after the sustain pedal was engaged.

The only thing I'm not sure of is what the behaviour should be if while the sustain pedal is still engaged, after a note off message has been delayed, another new note on message arrives for the same note (which already has a note off message queued in the buffer).  Perhaps the modifier screen could have an option setting to let the user decide the behaviour in that scenario.  One option would be to allow retriggering of pedal sustained notes (by immediately issuing the queued note off message to the output just before the new note on message is allowed through).  That would be suitable behaviour for something like a piano sound where you want to hear the attack of the later note. The other option would be to discard the new note on message and also discard the earlier note off from the memory buffer without letting either message go to the output (another note off message may get added to the buffer again later if the next note off message occurs before the sustain pedal is released), so the output behaves as though the original key press had continued uninterrupted into the later key press.  I imagine that would mimic the behaviour of some synths that do not retrigger notes that are already being sustained by the sustain pedal.


This feature would be useful not just for playing keyboards with sustain pedals into other synths or sequencers, but also when loading midi files involving sustain pedal data into a DAW and sending it to synths that cannot cope with the sustain pedal messages.

Hello conductive labs team
I've received the mrcc and i'm really happy with it. Thanks for this great device!

I would like to suggest an update for the pc usb port: from 12 to 16 virtual midi ports if possible.
Why ? Because there are 12 midi din out ports AND 4 USB ports. Total: 16.
Unhappilly if I assign the 12 virtual midi ports (pc usb) to the midi din out, i can't anymore use the 4 usb ports ... 

Thanks
Yo

Hi all,

My MRCC is currently on order. I'm buying cables while I wait for delivery, but I'm a bit confused by MIDI TRS.

I have a 1010 Bluebox mixer which has 3.5mm MIDI TRS in and out ports, and I plan to connect them to the MRCC.

Since MRCC has separate ports for both MIDI TRS types (A and B), can I just buy a normal 3.5mm male to 3.5mm male stereo audio cable to connect them?

Presumably, if I plug it into the TRS B in and out ports on the MRCC, it should just work given that the Bluebox supports type B for in/out, right? No special cable required (eg. crossover or whatever)?

Many thanks,
Ben

Hi all,

A NDLR user here, and soon (I hope) an MRCC user too. I ordered an MRCC last week via Backerkit. The CL website says that all new orders will be shipped in June 2021, but my card doesn't appear to have been charged yet, which suggests shipping might not be imminent.

Does anyone know what the situation is for latecomers like me? Are there plenty of MRCC units waiting to be dispatched this month, or is it possible they'll sell out and I might need to wait weeks/months for the next manufacturing batch to arrive?

Many thanks,
Ben

Hi Conductive Labs,

I was assuming that the MRCC would allow me filtering SysEx, because it is mentioned on page 49 ("MIDI Message Filtering Details").
But this seems not to be the case at all, nether on Port nor on Route level.

Is there a future option like this in the works? It would really help to clear out these on certain connections, especially when it gets crowded and clock (timing) is involved.

Best, Joris

On manual (page 29) it says: "Exclusive is a Yes/No toggle. Yes = only pass the mapped channels"

It seams (if Exclusive is set to yes), it excludes non-mapped channels, but it will also excludes non-channel traffic like clock. 

Is that intentional, or a bug? (I'd consider it a bug, as it took me some time to find out why my device was not playing along in time, and only found this strange behaviour to be the cause).

Hope this can be fixed soon.