Andy Strohkirch

Thank you all so much for your participation in this discussion! @MusicMan11712 (aka Dr. Steve) Steve, yes, that is correct. The CME UF-6 is only starting to send MIDI timing information after one of the transport buttons is pressed, or the tempo knob is moved. It then sends this information until pressing RESET or switching off. My previous observation with the original drivers on Windows XP and the keyboard connected via USB was, that the constant data flow of the MIDI timing information was heavy on the CPU (that was back in 2006 or so). For that reason I always preferred to connect via MIDI exclusively. Today I do not employ the drivers because of their age. @msmcleod Mark, I completely agree. Looking for ways to use realtime messages came initially due to the lack of having other MIDI information available, and because of the vision I had in mind for the use of the transport control buttons. In a perfect world I could just slave CbB to the master keyboard and control it from there. However, this comes with limitations. A synced slave will only follow it's master, meaning there is no way (and please correct me if I am wrong!) to expand on its functionality. Let me make this more concrete: Ideally I would want to start, stop, arm, rewind to the beginning, and forward or rewind skip to song sections (preferably via markers). But the master keyboard does not know anything about my song structures! In this scenario CbB could sense the note-length skip (button forward), and send the correct song position (maybe as SPP) back to the master keyboard, which then switches the position information it sends while remaining its clock function. Imagine the use of this, musicians/singers could repeat a section quickly to practice it, or during recording sessions specific parts could be repeated in one recording flow. Plus, the use during live sessions. If you have buttons sending SysEx information, you can achieve this with help of @azslow3 's great control surface, while keeping CbB as master. @Noel Borthwick Thanks very much for clarifying this! @Base 57 That's a really cool tip.

@azslow3 Thank you so much for your input! I did setup Cakewalk as slave today, this time as described in the post you linked. Unfortunately the problem remains, none of the real time events seem to reach the control surface. The SysEx event from the REC button remains working. The CME UF-6 is transmitting periodical song position pointers. The manual mentions that the keyboard is sending MTC (MIDI timimg clock), and supporting Active Sense.

@MusicMan11712 (aka Dr. Steve) Thank YOU very much for the inspiration! I finally figured out what the keyboard is actually sending. I completely misinterpreted the display of the MIDI monitor software and apologize that I've confused all here in this thread.... ? So... the CME UF 6 is sending out the following MIDI messages: Play 0xFA (MIDI system realtime message: MIDI start) Stop 0xFD (MIDI system realtime message: MIDI stop) Record (sends 2 messages!) F0 7F 00 06 06 F7 or F0 7F 00 06 07 F7 (MIDI SysEx Message, send in exchange every second press) 0xF2 0xpp 0xpp (MIDI song position pointer message, the 2 last words define the current song position, as the master keyboard counts it) Position 1 0xF2 0x00 0x00 (MIDI song position pointer message, the 2 last words define the absolute start position) Rewind 0xF2 0xpp 0xpp (MIDI song position pointer message, the 2 last words define the song position which decrements by 16 = one note length) Forward 0xF2 0xpp 0xpp (MIDI song position pointer message, the 2 last words define the song position which increments by 16 = one note length) And this brings me back to my initial question and problem. It seems this real time messages (SysEx comes through) are not reaching AZ controller. I can generate per example a song position pointer message within the control surface, but the one sent from the keyboard doesn't come through. I've tried to actually slave CbB to the keyboard, but that didn't make a difference for the control surface. I've went through the settings once more, and tried to echo SysEx, as well as to transmit MIDI start/... and MIDI SPP, with no luck. Any ideas?

A quick update. I tried both suggestions (Echo SysEx / Transmit MIDI Start....) yet no success. I believe the SysEx equivalents to the Real Time MMC commands may look different as i initially thought. If this is the case, then the commands may not be filtered by CbB after all.

Hi guys, sorry for the late response and thank you so much for helping! I'll give your both advice a try, and report back a little later. For the meanwhile here are some more details about my setup: The CME UF6 is connected via MIDI to an M-Audio Midisport 4x4 MIDI interface, which is connected via USB to a laptop running Windows 7 64bit. I intentionally did not install any drivers for the UF 6, as the available ones are pretty old and not written for the OS. The keyboard was made in 2006 i believe. I didn't quite get the tip with echoing the SysEx, as the control surface is directly looking at the MIDI out (no other gear involved), but I'll double check. The UF 6 transport buttons work in MMC (MIDI Machine Control) mode. I can control the DAW via MMC, but do not really want to make the DAW a slave as this brings multiple disadvantages for my setup. For once what MusicMan posted, pressing stop a second time stops the sequencer from listening which i find problematic during live performances. Also, I very much want to teach the forward and rewind buttons to think in markers instead of the fixed 16 measure pattern... After thinking about the problem over the day I fear that I am lacking knowledge about the MMC command structures. They seem to differ a little bit from device to device (how can it be?), and seem to be undocumented for the UF6 (though working for its purpose). The MIDI monitor software i use may not show the complete command as it is send, but I am not sure about that yet. Update to MMC commands I believe the SysEx behind the MMC commands as they are sent by the UF 6 is as follows. However, am still unsure about the device ID byte. It could be [7F] for all devices, or [01] for the channel, or is it specific? I wonder how to find this out... F0 7F [device id] 06 FA 00 00 (Play) F0 7F [device id] 06 FD 00 00 (Stop) The [06] describes that a command is sent. The [FA] / [FD] seem to be non-standard, but are confirmed through the MIDI monitor.

Hey all, this is Andy. Please allow for a hopefully simple question regarding automation of real time controls via the AZ Controller control surface. First of all, I was able to setup remote control for CC MIDI messages and SysEx messages (master fader) for a CME UF6 master keyboard. I am struggling with transport control, because the SysEx commands seem to be filtered out through CbB. Internally generated MIDI RT events work as expected. A MIDI monitor shows that the commands are sent by the keyboard and received through the interface. In general one can allow SysEx data to be recorded through the CbB preferences (Edit > Preferences > MIDI - Playback and Recording > Record / System Exclusive). This setting is important for the control surface (AZ Controller) to be able to listen to SysEx events. For some reason however this does not include real time SysEx events (such events that do not start with F0). What could be the reason that events like "Play" (FA 00 00*) and "Stop" (FC 00 00*) are not passed through to the AZ Controller control surface? Is there another setting in CbB that filters these events out? Your help would be much appreciated! Update after further research * MIDI Monitor may display the bytes of the MMC real time messages in a different order than these are sent, and may also omit an information (Device ID). The displayed command codes FA/FC seem to be non standard. Because of this it is now no longer clear to me if the sent messages are compatible to AZ Controller's MIDI RT entries. It is however confirmed that CbB understands the real time messages in MMC sync mode (set as slave device with the keyboard as master).