Issue with Cubase... Is it because of Bome's?

marc11657

2014-07-08 17:12:49

Not sure if this is because of Bome's, Cubase or because of the particular outgoing Midi Message I have chosen. I'm setting up midi control of Cubase 5 and I've noticed that when I use a button on the midi device to control any of the transport buttons there seems to be a delay before it carries out the function. This is the setup I have and the moment that the delay occurs:

1. I press the play button on the Yamaha AW4416
2. Midi message is triggered (red LED indicator lights up) on Midi IN of E-mu 0406 USB
3. Midi message is recieved by Bome's Midi Translator
4. Bome's Midi Translator converts the Sysex Signal to B0 39 7F/Controller 57, 127. I'm doing this as Cubase 5 doesn't appear to accept incoming Sysex Midi Signals.
5. Bome's Midi Translator sends the converted signal via LoopBe Internal Midi Driver
6. Cubase 5 detects the incoming signal from LoopBe Internal Midi Driver
7. Cubase 5 converts the midi signal to a function (Transport Play)
8. ***DELAY**** The play button on Cubase 5 transport bar illuminates (although the stop button is still on) for about 3-4 seconds before the session actually plays.

Here's some things I've tried or noticed whilst trying to work out where in the chain the problem stems from:
  • When I press play using the mouse or the keyboard the session begins to play immediately.
  • In Bome's Midi Translator you are able to translate the incoming midi to a key stroke. I set the outgoing to the 'spacebar' and the track played immediately when I hit the play button the the midi controller. However I don't want to use keystrokes to control Cubase as this may cause unwanted effects.
  • I used the same play button on the controller and assigned it to 'mute' on audio channel 1. The mute switched on and off immediately and without delay.
  • I used another button to of the control surface and programmed it to trigger the play button in Cubase's transport. The delay still occurred
Anyone else experienced something similar and knows of a solution to try?

Thanks

DvlsAdvct

2014-07-08 21:21:38

Hi marc11657

I'm sorry to hear about the delays you're experiencing. We're going to have to try some troubleshooting issues to see if there are any conflicts or issues with Cubase.

You may be experiencing MIDI timing and latency issues. Out of curiosity, are you experiencing similar issues with other MIDI commands that aren't transport?

I found this thread which gives the location of a MIDI timestamp setting which may help. Apparently Cubase looks for non-standard drivers which their controllers use, and you need to convince it to stop compensating.

I would also recommend using the MT Virtual Drivers instead of LoopBE, since MIDI Translator is optimized to work with the included virtual drivers.

Instead of sending a CC message try sending a Note message. Switch the B0 to 9F, and relearn the command in Cubase, and see what happens.

Also, do you have any quantize or sync settings active? I know that it sounds weird because the keyboard is working, but I'm just taking some stabs in the dark to see if we can figure something out.

marc11657

2014-07-08 22:27:26

Hey,

Thanks for the reply!
are you experiencing similar issues with other MIDI commands that aren't transport?
The midi signal appears to get 'into' cubase and cubase responds to the action immediately (by illuminating the on screen play button), however it just doesn't seem to begin the actual playing of the session until a few seconds later. I've just tried it with the track solo button (using both a mute button and the play button from the control surface) and a similar thing happens. The solo button illuminates straight away, however it takes a few more seconds until all the other tracks light up muted.

This solo button isn't even going through MT!! It's going straight through the E-Mu into cubase. I should re-iterate that the faders and pans are 100% realtime without delay though.
I would also recommend using the MT Virtual Drivers instead of LoopBE, since MIDI Translator is optimized to work with the included virtual drivers.
I attempted this first and, although Cubase detected the MT Virtual Driver it couldn't detect any signal from MT. I attempted the LoopBE driver and that appears to get the signal through. I noticed that the MT Virtual Driver Was recognized by Cubase as a 'Direct Music' device, whereas the E-Mu audio interface (which the midi devices are connected too) and the newly installed LoopBE driver are recognized as 'Windows Midi' devices. Maybe that has something to do with MT Virtual Driver not sending a recognizable signal to cubase?
If you have persistent timing problems (shifted notes etc.) with native or emulated DirectMusic ports please check the option "Use System Timestamp" provided in the DirectMusic section of the Device Setup dialogue. This option uses another timing reference in your system when enabled.
The option "Use System Time Stamp" is also available for Windows MIDI ports since Cubase SE 3, SL & SX 3.1 and Nuendo 3.1.
Since Cubase/Nuendo 4 the option can be found in "Device Setup..."-> MIDI -> MIDI Port setup.
I followed the link in your post and copied the instructions that they advised. I followed them by click on the 'Use System Timestamp' for both 'DirectMusic' and 'Windows Midi' devices. There was no change.
Instead of sending a CC message try sending a Note message. Switch the B0 to 9F, and relearn the command in Cubase, and see what happens.
I tried changing the midi signal to 9F and there was still a delay.
Also, do you have any quantize or sync settings active? I know that it sounds weird because the keyboard is working, but I'm just taking some stabs in the dark to see if we can figure something out.
The same issues occur on a complete blank project. There's not auto quantizing switched on within cubase.


ARRRGGGGGHHHHHH!

The puzzle continues.

marc11657

2014-07-09 00:00:43

Just a quick update...

I just tried using a simple Midi Keyboard key to trigger the play function within Cubase. I noticed two things:

1. If I just tapped the key the play button in Cubase would flash on and off (at the speed of me pressing the key) but wouldn't cause Cubase to actually carry out the play function. If I held the key down for the 3-4 seconds then Cubase would carry out the Play function and begin playback.
2. In Cubase there is an option to set the specific trigger with a 'flag'. Those flags are 'Push Button', 'Toggle' & 'Not Automated'. If I select 'Push Button' or 'Toggle' options then the length that I press the key for doesn't have any effect on the playback function as it will effectively hold down the key for the 3-4 seconds it takes to begin playback.

Now I'm starting to think the problem lies in Cubase... However I can't figure out how to speed up that process, nor can I figure out why a midi trigger would cause Cubase to respond slower than a mouse or keyboard.

marc11657

2014-07-09 13:43:06

Aha! I managed to scour the internet for a few more hours and found the solution in a small comment at the bottom of some un-related article!

For future reference you need to select the 'not automated' flag within the Cubase Genereic Remote window. Yay!

DvlsAdvct

2014-07-10 15:32:15

Hi again

Just as a note, your project may not be set up properly to send across the Virtual MIDI Ports. My research showed that Cubase uses those Direct Music devices for more accurate signals, as opposed to the Windows MIDI devices. It shouldn't be hard to set up the correct MIDI devices, as long as you have your project set up to support it.

What you should do is activate the Virtual MIDI Ports and then change your Default Ports to the Virtual MIDI Ports within MT, and then be sure to assign those ports correctly in Cubase. You want to use two separate ports, one for input and one for output (so don't use MT 1 In and Out, use MT 1 In and MT 2 Out).

Does that all make sense? Granted, if it's working then there shouldn't be a problem.