Lag in drum editor view only - Edit: Steps to reproduce

[edit]

My post towards the end now has steps to reproduce that show this problem to be cumulative over time.

[/edit]

Hey, guys.

I’m running the latest patch of 7.0x on 32 bit Windows 7, and yesterday I noticed an oddness that I haven’t seen before. I use a CMC Transport control and often page through a measure at a time. I was getting inconsistent playback of a midi track, and then I noticed that when I was paging from measure to measure (with the project not playing) it was almost a full second between hitting the transport and it moving to the next measure. Further observation showed that during playback, the the current position line was not travelling smoothly, pausing then jumping to the next position.

If I open the same track in the keyboard or list editors, it performs fine. This only happens in the drum editor. I tried setting the track to no assigned midi instrument, but that didn’t make a difference. Also did all the normal stuff, restarted cubase, rebooted the computer, etc.

Any thoughts on why I’d get something interfering with performance that only occurs in the drum editor, and not the other two?

Hi ChrisDuncan,

please check these two posts and let me know if the issue you are having is similar to the ones described there, and also if removing the video components from the Cubase application folder helped you as well:

Regards

Hey, Luis.

Neither of those describe my symptoms but when I get back tonight I’ll try moving the video components to test. Will report back on my results.

Thanks, man.

Luis,

I searched my entire hard drive for videoengine.* and found these files under c:\program files\steinberg\cubase 7

videodecode.exe
videoengine.dll
videooutput.exe
videopreload.exe

I removed them from the folder, started Cubase and noticed no difference. A lag that’s too severe to work with in the drum editor, if I come out of the drum editor and playback, everything runs very precisely.

Any other suggestions? This editor is critical to my workflow, so if you can pull a rabbit out of your hat it would be most appreciated. By me, anyway. Can’t speak for the rabbit.

Chris,

  1. Try installing the 7.5.x Trial version alongside your 7.0.x - it shouldn’t interfere with that at all. See if it has better/different behaviour.
  2. Check through any recent ‘Windows Updates’ that may have installed in the background, that might have upset things (long shot…!)

Sorry, all I could think of - its an odd one chris…

Good luck,
Bob

Hey, Bob.

Thanks for the ideas. I keep Windows update turned off for just this reason. :slight_smile:

Luis,

I’ve figured out what your devs need to track this down. The bug is related to the position in the timeline of the midi event. The lag appears to be cumulative, increasing the further in time you go.

My projects are long, used for live performance sets, and thus are over an hour. Here’s how to create the problem from scratch.

  1. New blank project, audio settings don’t seem to matter
  2. In project settings set the length to an hour and 30 minutes, i.e. 1:30:00:00
  3. Create a midi track. Assign to no input or output to eliminate that possibliity
  4. Create a midi event at the very beginning
  5. Go to around the 1:29:00:00 mark and create a midi event there
  6. Add no notes to either event
  7. Set a keyboard shortcut to move one measure at a time (I use the CMC TP control for this)
  8. Open the first event in the drum editor.
  9. Step through several measures and note the absence of lag
  10. Repeat this process on the second event at the end of the timeline.
  11. Notice a lag of almost 1 second betweeen hitting the command and the time position moving.

I’ve set the events at the opposite extreme to illustrate the behavior, but you can insert events along the way and notice a gradual increase in lag time until, towards the end, it becomes very conspicuous.

In addition to navigating by measure, this lag affects playback as well, causing delays in transmission and the associated problems that come with it.

I don’t have any intention of upgrading to 7.5, will probably wait for 8.0 and see what the feature set is there. Consequently, if the devs would consider looking into a fix for this bug in the next 7.0x maintenance release, I’d be most grateful.

Let me know if they need anything else to reproduce the problem. It’s very consisstent for me.

Thanks!

Just a shot in the dark, but do you have any of the MIDI chase options set in preferences?

Good thought, I checked that first as I’d seen some MTC issues in other threads but the settings have no effect on the behavior.

The fact that I can reproduce this in a clean, blank project with no midi data entered seems to indicate that it’s a bug.

Nice repro.

However, it does not reproduce here.

From reading your posts it’s clear you’re on a Windows machine, but it would be useful if your system info was in your sig.

Hey, Steve.

Updated sig with specs. I notice yours says 7.5. Do you have a 7.07 install that you’re able to test with?

I did check in 7.0.7, and could not repro.

Thanks for taking the time to try to repro, much appreciated.

This is occurring on my live rig, which is a laptop and thus not a typical desktop grade video card. I’ve seen a lot of problems reported on the drum editor related to video (and I tried removing those files). I’m wondeirng now if it might related to the video driver itself.

I’ve been focusing on the live environment. I’ll test in the other two locations and see if I get the same behavior there.

As an aside (since there are known issues relating to this), why should a midi drum editor give a rat’s rear end about video in the first place?

Hi Chris,

that is a very good question, and the answer is… we don’t know. We can not reproduce it, and frankly, it doesn’t make any sense, which is why we haven’t been able to address it yet. That is why I asked you to give that a try, because if we found more cases with the same symptoms, we could look for some similarities and maybe find the root of the issue.

I haven’t tried to reproduce what you’ve posted yet, but will give it a go and report back.

All the best

I develop software for a living. Believe me, I’m intimately familiar with the phrase, “I don’t know.” :slight_smile:

Will update here after I’ve had a chance to test in the two desktop environments.

Thanks for the help, man.

Hey, Luis.

I have new information that will hopefully help your devs reproduce and fix this.

In the live rig, I use a laptop, but I plug a monitor into the extra vga port and view from that rather than the laptop screen. In studio A, I have a 42" screen but it’s coming vga out of an old school kvm that doesn’t support hdmi.

On both of these boxes, if I go to Device setup / Video / Video Player, I see nothing but an error message in red text:
Please update your graphics card driver or switch to a more effective graphics

On both of these boxes, I can reproduce the problem as described. Additionally, I have a couple of keyboard shortcuts mapped to horizontal zoom in / out. If I lean on that key, it zips along for a second and then the screen update becomes jerky. It appears to update about once every 500ms or so. The lag time feels exactly like the delay when I press the next / previous bar keys on my TP.

I use the studio B box for video editing and consequently have a moderately high end video card. When I bring up video settings on that box, I don’t get the error, I get the normal video player settings. And I can’t reproduce the bug on this box.

From this, it seems clear that this is another problem related to the video card since the two boxes with unhappy video player messages have the bug, the one that’s content with its card doesn’t.

If you’ll permit me to be presumptious for moment, I have the following thoughts from a developers perspective (I grew up on C, then C++, etc. and have been doing it for 25 years). My question about why a midi drum editor would care about video came to mind as I was looking at the zoom in / out bug described above. Especially when you’re zooming in, that’s a very, very busy screen in terms of all the lines that have to be drawn, etc. Much more so than with the piano roll or list editor. I think this may be the key to the drum editor interacting with the video system.

Back in ancient times (DOS 3.1 if I recall correctly), writing graphics to a character mode screen required a few different techniques depending on your needs, including bios calls, interrupts and writing straight to video memory. Each performed better /worse than the others, so you chose accordingly.

I mention this bit of massively obsolete programming practice for no other reason than to illustrate that when faced with the need to do higher performance screen updates, even modern devs will steer away from the typical Windows APIs for drawing (or it’s Mac equivalent) and instead will look for ways to write to a lower level of the video subsystem in order to get the desired update speed.

For a grid as dense and busy as the zoomed out drum editor, the draw to / line to routines probably looked fairly slow and drippy (I’d also image you’re using some kind of cross platform library to cope with Windows / Mac, and its drawing routines will be the lowest common denominator rather than high speed). I’m willing to bet that if your guys check the coding infrastructure that’s used to draw and update the drum screen, at the lowest level they’ll find that it’s not using the same stuff as the piano roll & list editor, and very likely is accessing lower level video APIs that make assumptions about the quality of the card / driver.

I’m guessing that when an acceptable level of driver isn’t found, as in my 2 out of 3 boxes, it drops down to some default graphics routines and things go badly. For all those people who have had other video related problems with this screen, it might be worth your while to see if they have the video error message. I’m willing to bet that they do.

Anyway, quite presumptious since I know nothing about your code (and programmers do tend to get annoyed at such arrogance), but this is the closest thing to a smoking gun I can give you. At the very least, I think if your guys test on boxes with sub par video cards, they can reproduce this in a debugger and fix it (if you can’t reproduce it in a debugger, you’re usually screwed). If they can’t get hold of a box without a good video card they can try a) using their laptop but plugging in an external vga monitor as I do or b) try logging into the box via Windows Remote Desktop, which also downscales the graphics. Can’t confirm that RD will reproduce the bug, but I know the laptop monitor thing is likely.

If I can be of any further help on this, let me know and I’m happy to do what I can.

Thanks!

Hi Chris,

thanks for all the extra information. I’m passing it along to our developers. I’ll let you know, as soon as I hear something back from them.

Regards

Appreciate the help, man. Tell the guys if they can track this one down and kill it, the next espresso is on me. :slight_smile: