"UI to Midi" and external midi control at the same time.

    Hi,

    I am setting up a large Kemper rig, but I have some questions relating to the behaviour of the "UI to Midi" function which the manual doesn't seem to cover.

    My setup:

    Basically, my intention is to have 2 profilers (power rack) running simultaneously, as a main and spare. I will have a switcher on the outputs to flick to the spare in emergencies.

    (There will actually be two of these rigs, so 4 profilers running in total on the stage, but we can focus on one pair for now.)

    A lot of the patch and rig control will be done from a computer running Ableton live onstage, sending out program and control changes at precise moments.

    The kempers will have their midi channel set to a specific channel. For arguments sake the rig in question will be channel 1. (I cannot leave it on Omni, because of the other system running on the same stage). I don't think this is relevant, but I wanted to mention it, incase it affects any suggested work arounds.

    The player will be running a Kemper remote foot switch. and doing occasional manual switches.

    I will connect the remote to the main profiler, but I want to use "UI to MIDI" so anything the player presses on the remote, mirrors to the spare Profiler

    So my core question is:

    If the Kemper is set to "UI to Midi" AND then it receives midi commands via the "midi in" port.

    Are the midi commands it receives the Midi In, passed to the Midi Out, due to the "UI to Midi" setting?

    OR: is midi only sent to the midi out when a physical button is pressed on either the Kemper profiler or remote?

    Technically I could make the system work either way. But it alters the set up, so I need to know. The latter option would be the preferable one, but I'm guessing I dont get a choice!

    Any help much appreciated. I have tried searching the forum but no luck!

    Thanks

    "UI to MIDI" doesn't merge incoming MIDI comands with "self-generated" MIDI comands.

    If you just intend to pass-thru MIDI, you could use the MIDI THRU for that purpose (only Head and Rack models) and don't activate "UI to MIDI" and don't define external devices occupying the MIDI THRU as another MIDI OUT on page "Perform Mode: MIDI" in System Settings.

    Thanks for this.

    No ideally I don't want to pass thru midi.

    If the midi from Ableton exclusively goes through (/thru) the main profiler, and the main one drops out/crashes/loses power, then the spare would also lose its midi, which is bad.

    So my intention would be to use a merge box, receiving the feed from Ableton, and the "out" from the main profiler (containing the "UI to MIDI" signal). Once those signals are merged, then I send them both to the midi in on the spare profiler.

    As you can see, if I did this, but the main profiler was passing on the midi it received from Ableton, then the Ableton control midi would be duplicated, and received by the spare twice. Which would be bad.

    But if you're saying that the "UI to Midi" only sends out the physical button presses, then thats great.

    But I don't understand why you want to merge!? With "UI to MIDI" the slave will follow the master through Performances and Slots. Effect Module switching, pedal controllers, all these will be transferred and mirrored at the slave. Merging will cause confusion as redundent comands will arrive at the slave.

    Let's take an example: Ableton sends MIDI CC# 7 (Volume Pedal) to the master. The same data is forwarded to the slave and merged into the "UI to MIDI" stream sent from the master, which also includes MIDI CC# 7. Result might be,t hat slave performs accelerated moves of it's volume pedal compared to the master.

    Simply check "UI to MIDI" out with two units.

    Ah, well yes, that was exactly my question. when you said:

    Quote from Burkhard

    "UI to MIDI" doesn't merge incoming MIDI comands with "self-generated" MIDI com

    I thought that you meant, an incoming midi command (as you say: CC#7, from Ableton to master), would NOT be forwarded to the output, even with "UI to Midi" checked.

    the command from Ableton would not be a self generated command, and would not be sent to the midi out.

    However, if I have misunderstood, then my apologies.

    so are you saying, that the CC#7 from Ableton to Master, WOULD re-appear at the Midi out under the UI to Midi protocol?

    Thats the key piece of info here.

    If it DOES appear, then no I would not use a merge box, as that would, as you say, create duplicate signals.

    In this case, I would simply send Ableton to the master, and have the slave controlled purely by the master. Although this is less ideal, as it is a fundamentally less reliable system; If the master goes down, the slave is pretty much useless anyway, thus slightly defeating the point of having a spare in the first place!

    If this is the case, I will need to think carefully, what the lesser of two evils is.

    FWIW, the info coming from Ableton, is mainly likely to be rig and FX on/off changes. I am very unlikely to send anything progressive like volume changes and other such CC# values. But even so, duplicate messages is clearly bad!

    At risk of repeating myself, I'm just going to try and explain in a different way, to make sure its clear what I mean. Just in case.

    So.

    Under normal operation: ("UI to Midi", NOT enabled)

    If I send CC#7 commands from Ableton to Master Kemper:

    volume is changed on the profiler

    That same midi Signal is sent out of the "Midi THRU" port, which could control another profiler.

    Nothing appears on the Midi Out Port.

    If I manually change the volume on the profiler, the volume will change, but no midi signal appears on either the "Midi Thru" or "Midi Out" ports.


    When "UI to Midi" IS Enabled:

    If I manually change the volume on the profiler, then CC#7 data is sent out the "Midi Out" port, but not the "Midi Thru".

    If I send CC#7 Commands from Ableton, the volume changes on the profiler, and the same midi signal is sent out of the "Midi Thru" port.

    But crucially - does it now also appear at the "midi out" port?

    Hope this helps.

    The purpose of "UI to MIDI" is to send internal processing like Performance/Slot navigation, Effect Module ons and offs, pedal controller moves and others via MIDI to another device e.g. a second PROFILER regardless how these are triggered (front panel, analog pedal and switches, MIDI, Remote).

    So, logically the comands arriving from Ableton are not forwarded, but these are processed by the master PROFILER and this processing generates another stream of MIDI comands sent from the master PROFILER to a second device. The format of the MIDI comands sent by the master PROFILER could differ from what Ableton is sending. If Ableton would send comands, the PROFILER cannot process like for example MIDI Notes, these will not be forwarded to the second device. And if you - while Ablteton sends comands to tha master PROFILER - intervene at the front panel of the master PROFILER for example loading another Performance, the slave PROFILER will reflect that Performance load although it has not been initiated by Ableton.

    Ok thank you.

    So basically, the answer is not a total yes or no.

    The Master Profiler will forward a version of the midi received from Ableton, but not a carbon copy.

    I think tbh, this is dangerous for me either way. If I send this signal to the slave, merged with the Ableton midi, that could create dangerous duplicates of signal. But if I only send the output from the Master, and that loses power or crashes, then the slave is receiving no midi at all.

    Or I send the Ableton midi direct to both Profilers, and do not use UI to Midi, meaning the spare is up to date with Ableton, but not update with manual changes.

    I'll have to think carefully about which is the better scenario.

    Very much appreciate your help with this.

    I'm trying to explain, that the word "forwarding" is logically inappropriate. UI to MIDI doesn't forward anything from Ableton.

    1. The master PROFILER receives and processes MIDI comands in your case received from Ableton.

    2. With UI to MIDI enabled, the master PROFILER sends parts of its own internal processing via MIDI regardless how this internal processing has been triggered.

    1 and 2 are completely decoupled MIDI-wise.

    My impression is, you are making this much more complicated than what it is. Connect two PROFILERs via MIDI cable. Enable "UI to MIDI" at the master PROFILER. If you now change Slots or Performances on the master's front panel or dial the pedal controllers on page Pedal Links in System Settings, the slave PROFILER will follow. So you see, the MIDI communication between master and slave PROFILER is completely decoupled from any MIDI the master receives. If you trigger the same transaction sending MIDI into the master, the communication between master and slave is still the same. There is no need for any other "MIDI forwarding". Simply check it out.

    Hi,

    Thanks, I do believe I understand, its just that what happens is not what I would prefer to be the case!

    you are right, forwarding is a bad terminology. The midi comes in from Ableton, which triggers a change in a given value/rig/etc on the profiler, which in turn, generates a midi signal to reflect what it is doing, which is sent from the Midi Out right?

    So yes, I connect Ableton to the Master, and I connect the slave to the master, and I will have 2 fully duplicated profilers.

    This achieves, pretty much, what I want it to, but it is fraught with risk.

    The whole point of having the second profiler, is more of a spare than a slave. With this "slave" set up, there is no direct midi connection from Ableton to the Spare/Slave. This means if my main profiler drops out / crashes/ loses power, the spare is not actually that useful because nothing is controlling it, making it arguably not that useful!

    This is why I was trying to find a way, (even if complicated) to maintain both sync between two profilers AND a link from Ableton to both of them. However it doesn't look to be possible.

    I'm not trying to sound ungrateful. I appreciate your help, just explaining what I'm trying to achieve!

    If you prefer, you can split MIDI and send both PROFILERs the same comands from Ableton via two seperate cables. This way both PROFILER s will perform the same transactions and be completely independent in case one "disappears". Then you don't need "UI to MIDI" at all. Mixing both approaches is not meaningful.

    Yeh, thats what I'm leaning towards doing. The downside to that, is that the player will have a remote footswitch for occasional manual changes. but without UI to Midi, those changes will not be reflected in the spare. Thats why I wanted the best of both worlds but I can't have it!

    Theres actually two players onstage, and I'm thinking I may set one of them up one way, and the other player the other way. as its best of each of them based on "majority" use!

    Thanks again.

    Ok one more question, sort of related, but sort of not:

    If a profiler has UI to midi enabled, when it boots up, does it spit out any midi reflecting its current state? or will it only send midi based on "changes"?

    thanks

    UI to MIDI just sends transactional changes. Both PROFILER units should start with the same OS version, and the same data: perform a backup on the master and restore on the slave. UI to MIDI does not include "Store". If you change a Performance on the master and store it, it will not be stored on the slave without pressing Store there as well. The scope of UI to MIDI is transactions during a live performance.

    Quote from Burkhard

    If you prefer, you can split MIDI and send both PROFILERs the same comands from Ableton via two seperate cables. This way both PROFILER s will perform the same transactions and be completely independent in case one "disappears". Then you don't need "UI to MIDI" at all. Mixing both approaches is not meaningful.

    He needs both because in a performance situation he will be sending MIDI streams/instructions from Ableton *AND* "the player" will likely be manipulating the Kemper Master.

    UI to MIDI would be taking care of "the player" changes, a MIDI merge or a dedicated splitter can take care of the Ableton instructions.

    Ideally "the player" and the engineer can agree beforehand as to who would be manipulating what in order to help control data flow "conflicts", which in theory should be simply serialized by the MIDI system but in practice since the early 80's the implementation loves crashing your shyt face first.

    Edited 2 times, last by m127 (November 5, 2021 at 8:39 PM).