hello,

I would like to be able to toggle the individual parts via just key presses on the control channel. Eg C3 (pad), D3 (drone), E3 (motif1), F3 (motif2), G3 (all)

- The buttons on the unit are not as precise.
- Using the CC value is not practical for jamming unless you are using some dedicated hardware that you can program.

Thank you

Hey all,

... as a proud owner of a MRCC, which I received a couple of days ago, I tested some of my USB-Midi gear. Now my question.

Is there a kind of hand-shaking or switch-on procedure, which I should consider, when I plug in new gear in USB ports?

Background:
My Keystep worked instantly on the MRCC, but my Pyramid needed some attempts, before it was accepted. I cross-checked the Pyramid without changes with my MPC, connected it to one of the USB ports and it was plug'n play as expected.

I wouldn't call this an issue, but it makes me wonder:

• should I first power up the MRCC, then connect unpowered USB gear, and finally switch on the gear,
  
• or should I have MRCC with power off, connect all gear, and power on MRCC as the last,
  
• or doesn't such a procedure matter at all
  

I'm not sure if it's more hardware or computer, but iPad is computer anyway

I try connect older iPad mini to USB Host (usb-lighting) and also via USB hub to PC socket, but none of them see/hear midi connection. I just got MRCC and may not understand how to do that yet, but wondering if it can be connected like that? Or I should do that in other way?
Additional question - will devices connected via USB to MRCC be visible as USB devices from computer connected to PC port? Will MRCC work as USB hub?

Hello!

I had a chance to do some initial playing on the MRCC this week.  It is fantastic!  Super high quality all around.  The look, feel, funtionality, UI...  everything I have come to expect from you guys!

I love the options for screen and LED settings.  However, I have a small, but important bit of feedback from someone who has a medical condition that is highly affected by intense lighting.  The LEDs have brightness settings from 1-10 which is great!  However, even at 1, they are still way too bright.  I think the front, large lightpipes intesify there brightness as the smaller light pipes towards the rear (USB ports) are much less intense.  

I would suggest if possible to offer a lower setting where the brightest LEDS (selected ports) are the same brightness as in setting 1 as ports that are active in routing but not the selected ports (the dimmed ones - I hope that makes sense).  I would then make the non-select ports (dimmed ones) be 1/3 less bright or something so that they still show dimmer than the selected port.  Or maybe it is possible to add more levels - say another 10 and put make the current level 1 as the middle brightness and then the rest dimmer going down from there.

Right now, I have to cover them with masking tape for me to be able to use the device, which takes so much away from the beauty.   

I hope this is acheivable with firmware.

And seriously - I know I said this already - this instrument is just beautiful and way exceeded my expectations!

Michael...

Looking at the Blokas Midihub I am somewhat envious of the desktop editor and all the midi fx and tools they have. Obviously the MRCC has lots of advantages in terms of IO and the ability to program it without a desktop app, super quick routing etc. but man all those midi tools and chaining options look powerful. Midi delay for one would be really nice, but being able to chain randomization and note repeats / sample and hold etc. would be a great addition.

Obviously it's a huge tall order to ask for a desktop app to edit the config, but maybe something usable could be built into the existing UI.

Edit: Drool on this https://www.youtube.com/watch?v=ASruOUG2HIs

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.

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