Jump to content

CbB seems to filter SysEx data for realtime control - How to fix?


Andy Strohkirch

Recommended Posts

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).

Edited by Andy Strohkirch
Update to event descriptions after more research
Link to comment
Share on other sites

It will be good if you give more detailed info on how you connect CME UF6 to Sonar. Is it using it's USB port? or using MIDI port? Using MIDI port is more simple in general, however you may have driver problem (bug) using USB port. I'm not sure, but since CME UF is rather old (the last official driver I know comes from more than 10 years ago) there might be some problem with newer OS & DAW. It was designed to work in Win XP (2K) - Vista. YMMV.

And please also let us know about your PC, OS, etc. Thanks.

Link to comment
Share on other sites

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.

Edited by Andy Strohkirch
Added information about MMC SysEx Commands
Link to comment
Share on other sites

While you sort out your midi cabling and setup issues, I thought I'd offer some encouragement.  Thank you for turning me on to AZController, and thanks to @azslow3 for this wonderful ACT tool and the starter video on YouTube. I have been able to use it with my own setup .

 

 

 

Edited by MusicMan11712 (aka Dr. Steve)
details not related to this particular problem deleted
Link to comment
Share on other sites

@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?

Edited by Andy Strohkirch
Record button alternates SysEx message!
Link to comment
Share on other sites

In my tests Cakewalk in fact silently drops everything MIDI time code relates. You can try to set Cakewalk as "MIDI slave" (https://www.cakewalk.com/Documentation?product=SONAR X3&language=3&help=Synchronizing.05.html)  but this will not work in case your keyboard is not sending continues time code when played. If I remember my early tests, that also has other problem.

Check if you can ask buttons to send something else. Even MMC (SysEx based) will work. Just not MIDI system realtime.

Link to comment
Share on other sites

On 9/24/2019 at 5:41 PM, azslow3 said:

In my tests Cakewalk in fact silently drops everything MIDI time code relates.

 

Edited by MusicMan11712 (aka Dr. Steve)
details of how I passed midi BPM into Cakewalk and then out to other hardware deleted; different gear used than asked about
Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

19 hours ago, Andy Strohkirch said:

@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.

 

From what I read in a forum thread somewhere, your keyboard sends out the timing bytes once the transport buttons (I assume play and maybe record) are pressed.

Edited by MusicMan11712 (aka Dr. Steve)
details related to other gear deleted
Link to comment
Share on other sites

6 hours ago, msmcleod said:

The MIDI System Realtime messages/MTC are specifically meant for external synchronisation.

Cakewalk will generate MTC, and start/continue/stop messages, but they can't be overloaded for use in other ways.

Thanks for chiming in, Mark.  Apologies if it looked like I was trying to help Andy do something that MIDI and Cakewalk were never intended to do.

Steve

 

 

Edited by MusicMan11712 (aka Dr. Steve)
reference to being on the same page and question about "overloading" deleted
Link to comment
Share on other sites

The System Realtime messages are used by CbB specifically for MTC sync.
Incoming messages are used in order to respond to MIDI time code. We also send these messages when generating MTC.

However Cakewalk never forwards (thru's) incoming system realtime messages. There has never been a need to do so because these are typically intended for use in an MTC scenario.

Link to comment
Share on other sites

I'm not sure if this will help but here goes.

I have several hardware Midi devices connected through a Midisport 4x4. I use a freeware utility called MidiTrix  which allows any Midi input to be matrixed to any output including virtual ports such as LoopBe and rtpMidi. This allows me to control any of my devices from any other without regard to  DAW settings. 

Link to comment
Share on other sites

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.

Edited by Andy Strohkirch
Typo! :)
  • Thanks 1
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...