Pitch Wheel data doesn't return to zero

[Prime Mover]

This is a strange problem I've been having for about a year now. When recording and playing through the VIs directly, everything sounds fine, which means that my controller's wheel must be working properly and returning to zero. However, when I play a MIDI recording back and look at the MIDI automation, many times the written data doesn't return to zero, or even anywhere close. Sometimes it even looks damaged, with the screen drawing the line differently than the data points suggest. This did happen around the time I got my new controller.

I'm thinking that my new controller puts out a lot more fine grained MIDI than my old one, and that DP is struggling to write it and represent it. Any ideas on how to fix this?

[stubbsonic]

That's weird, because if it was your interface, it wouldn't just be recorded data-- it would happen even in monitoring/thru. Hmmm. This is a stumper. I suggests that DP is dropping data or something.

Go to another DAW program and try recording MIDI there. GB? Logic?

[MIDI Life Crisis]

Sounds like the controller may be defective.

[Prime Mover]

Sounds like the controller may be defective.

No, it's absolutely DPs fault here. In fact, DP ends up re-drawing the data incorrectly. It will appear to be at 0 one moment, and then when I start scrolling, the line will change as the screen redraws different sections. This doesn't happen in any other hosts, either. I play on this controller on MainStage daily, no problems. I've run it through MIDI Monitor, and the computer always shows the pitch data perfectly returning to zero every time. As I mentioned before, the one thing I noticed differently from my last controller (my QS8) was that this KeyLab88 send a whole lot finer data points than the QS ever did, which is actually really great because I could sort of hear the individual increments with the QS, whereas the KeyLab is very smooth. I just wonder if this is too much data for DP to handle or something.

[terrybritton]

On pages 579 through 583 of my manual is a discussion of continuous data, including pitch bend messages. There is a "Thin Continuous Data" menu item under "Region" that might help here, but I doubt it. Still, I suspect it has something to do with the way DP is taking in the data. The density of continuous data from a good quality controller is rather thick - that is, there is a lot of it.

Terry

[stubbsonic]

No, it's absolutely DPs fault here. In fact, DP ends up re-drawing the data incorrectly. It will appear to be at 0 one moment, and then when I start scrolling, the line will change as the screen redraws different sections....

Just to be clear, is the playback messed up, too? Or just the display? I was wondering if DP just wasn't configured correctly to display the higher density CC info. But if playback is messed up, this is a pretty serious problem!!

[Prime Mover]

Yeah, it's both the display and the playback. But the display is very weird. I wish I had a screenshot, but at first DP sometimes displays it as if it returns to zero, but if I scroll back and forth and that section gets redrawn, the line moves down. Furthermore, if I click in the center of the "bad" region that's below zero, it will jump back to zero! So, all in all, DP is performing very strangely. It's like it knows it's screwing up. I also notice this a little too with expression pedal data, so it's not just pitch.

I suspect the Arturia Keylab puts out pretty copious amounts of data, because it's designed specifically to be a precision slave controller. I had some other problems from MainStage when I first set it up, If I had the expression pedal (which is a visual control in MS) set to a number of different parameters, the GUI would slow down to a halt with controller redraws. I suspect Arturia might have overdone it a bit with the grain size of their data stream. Then again, this stuff should be peanuts, we're talking about data streams in the 1-2kbps range, these are from machines that are easily parsing 10-100Mbps of video data with ease!

PS: I'm using USB. Maybe I'll try traditional MIDI at some point, which can't send as much data. I suspect that would solve the problem, but be a little less convenient.

[terrybritton]

Just as a technical detail regarding MIDI baud rates:

"This is the serial port that will be used for both serial TX and RX. Your micro-controllers serial port must be set to 57600 bps 8N1. (Even though MIDI is transmitted at 31250 bps, the serial port is set at a faster baud rate to help minimize any lag time.)"

http://www.spikenzielabs.com/SpikenzieL ... _MIDI.html

(See beneath the graphic for more info...)

At least that is the scenario for the 5-pin MIDI jack - not sure how USB handles it - probably the same.

Terry

[terrybritton]

Just a thought from my last post - have you tried using other USB ports to see if there could be some congestion in a USB bus taking place?

Terry

[stubbsonic]

The idea of using MIDI din then that gets moved re-routed to USB does seem like a useful test to see if the "thinning" that might occur as a result of the lower data rate might help DP keep up.

I agree though that DP should be able to keep up with a thick stream.

Does the controller have any thinning settings?

[Prime Mover]

Does the controller have any thinning settings?

Unfortunately not, though I'd be surprised if it does, I've never heard of a controller having that, since the software should be able to handle it.

[Shooshie]

If you zoom in a notch or two does it still do it?

[cleamon]

Does the controller have any thinning settings?

Unfortunately not, though I'd be surprised if it does, I've never heard of a controller having that, since the software should be able to handle it.

Not sure if you've looked here or not, but I'd be interested to know if you looked in the events list for that data. If there is not a 0 at the end of the pitch bend, then for sure DP is not capturing it. If it is 0, then it's a playback/display issue.