Hardware midi issues

Hi guys,
 
I believe I may have posted about this before...but I'm trying it again in case someone new may see it. Here's my issue. I have a MOTU Midi Express XT for my midi gear. It has some clockworks software that comes with it so you can manually hook it up however you want. I don't know if this is where my issue is or if it is a setting in Sonar that I need to tweak. My audio is perfect...my softsynths with midi are perfect, all my midi hardware records and plays back using the correct ins and outs. Ok, so we're good there.
 
The problem I'm getting is, I keep getting stuck notes on the hardware gear and sometimes it skips notes. This stuff never happens in the same spots....it's always at random. I have tried everything I could with Sonar's midi options. I tried raising the buffers that were set to 64 to 128...no change. I tried the playback buffers that were set to 256 to 500, 800, 1000 and 2000. No change, but 2000 is best for me while using my drum VSTi's. They never drop any notes. I have all my midi gear set up right and all set to the right control numbers internally on the midi stuff as well as all the clocks set for external, local to off. I even tried local on...no change. 
 
I have the Clockworks midi control panel set up so channel 1 goes to 1, 2 goes to 2, 3 goes to 3 etc. I have the latest Win 7 64 drivers for the MOTU piece as well. None of the midi hardware is losing time or anything. I just get excessive note hangs and a few skipped parts here and there.
 
Now this isn't super important to me because most times, I will record on my S-80 piano and use Alicia's Keys or something...and not the S-80 sounds....or an old M-1 that I have....or an Akai module, Roland V Drums brain...it all works fine except for the note hangs and missing parts. But if I want to use any of those old classic sounds, they definitely aren't going to print well like that. LOL! I don't know what to try at this point. I've done trigger and freewheel (which is what I always have mine set to) I've tried full chase lock, all the different midi settings with sysex, cable meta...all that stuff. I've tried as many different configurations of those options as I can. Nothing has made a difference.
 
Now here's the weird thing. I didn't have this issue with Sonar 8.5 when I used it on my other box running Win XP. Maybe that is coincidental, but there's definitely something strange going on and I'm not quite sure what to try next. Do any of you have any ideas for me on where you would start to troubleshoot something like this? I've even done a one by one process of elimination on the hardware gear and it matters not how many are hooked up at once. It still does this. But it never gives me these note hangs or missing notes with VSTi's. Thanks in advance for any tips or tricks. :)
 
-Danny

Danny

What clock source do you have selected in your Sonar projects options?

Try the alternatives especially audio if the midi i/f is on the audio i/f.

Are you transmitting MTC and at what rates?

Try the alternatives there also.

Maybe you have already but worth looking in those areas because they are per-project settings.

That's a tough one, Danny. I would have thought "bad MIDI cable", except that it's apparently affecting all the ports/devices. And just to be clear, this is affecting both playback of existing clips and live input echo? If it does happen with live input echo, does it ever happen when you're just rehearsing with the transport stopped?

The main thing I would want to know is whether SONAR shows MIDI output activity in the track meters when the hardware misses a Note On. This would help determine whether the problem is in SONAR's internal processing of MIDI or a hardware/driver issue of some sort. Maybe some kind of contention on the USB hub/port the XT is using? But you'd expect that to just causing timing errors, not lost data.

Does it ever fail to record MIDI input? If not, I would tend to suspect an internal processing problem with MIDI output.

Mike: Thanks, yes as stated in my initial post, both buffer options were altered...the one that defaults to 64 was changed to 128, and the playback buffer that defaults to 256 was changed to 800, 1000 and then 2000.

Jonbuoy: Thanks! I'm using audio as the clock source. I tried midi but that didn't change anything. No, I'm not running any MTC at all. Each project is, and has always been in past versions of Sonar, as well as my templates, set for audio with no MTC with it also disabled in Clockworks. I tried enabling all that just to rule it out...no change.

Robert: Thanks...yeah it was a tough one eventhough that hurricane was a CAT1....I don't think I could handle the stress of going through another one any time soon. We're ok though...thanks bro!

Brundlefly: Thanks....and I gotta thank you also for always coming to my aid when I have a problem. You're always one of the first to jump in and attempt to help me. I really appreciate that...and I'll have to buy you dinner or something some time. :)

I tried the cable thing, but it's definitely not there. All midi cables are new and seem to be working perfectly. I even tried shaking them during playback...all is well.

This is only affecting existing clips and clips that are played back after they are created. Recording them is not a problem. Nothing sticks, misses notes or drops out. As soon as a midi from another project, or one that is created fresh is sent to one of my hardware units, that's when the issue occurs. Strangely, sending the midi to MS Wavetable Synth or TTS-1....there are no artifacts at all. So something is happening in the hardware. No issues with rehearsals and the transport stopped.

As for the midi activity, when a note sticks or hangs, the midi activity for that tracks is still pulsing. It doesn't give me a solid meter like you think it would being stuck on a note. It keeps on moving like it is receiving still. Sometimes, as it's sticking, something will automatically un-stick it and it will save itself. Other times, that stuck note or stuck chord will hang until the end of the song to where I have to press the panic button and it stops it immediately.

I wish I knew where to even start with this. Like I say, it's not a huge deal, but if I ever want to use my old stuff, it's going to be a problem using.......oh wow....as I was typing this, I was experimenting on the other box....ok, this may help you to help me.

It seems the problem comes from stacked instrumentation all on one synth. If I use my M-1 piano only, it plays back perfectly. Same with my Roland stuff, my Akai and the Yamaha. If I grab an entire song and set it up to use one module, this is where it gets me. For example, I have a Kawai session trainer that I bought for guitar practice years ago. One of the cool things about it is its midi engine. Remember back in the day when we used Sonar, we could have it play basic midi just to preview something right through our Soundblasters or built in soundcards?

This thing kinda has a bit better quality than that and I have it set to play any midi that comes into my system for preview purposes. It's about as good as the TTS-1 only I don't need to manually load it...it just defaults for me. That said, I have NEVER had issues with this thing or any of my other midi pieces playing entire songs using just them. I guess now that I know singular instrument voices will work, I really don't have a problem at all. However, I was always able to play a full song within a module and should still be able to do so as they are midi devices with 16 channels and when I set them up, everything has its own channel. I wonder what is causing them not to play full songs all the way through? Some sort of over-load maybe? Thanks.

-Danny

Hi Danny,
Long shot here, but I understood you to say that this started after you switched to Win7? I only ask because I had a MOTU midi interface that was the source of weird behavior and dropouts after I switched OS's.

If you don't have anything better to do ;)  you might consider running the dpc latency checker and checking your system for cpu spikes, etc. That is how I narrowed it down to my midi interface. I would also verify that you have the latest MOTU drivers installed. MOTU's website told me that the driver for my midi interface was compatible with Win7, but I still question that. However, even you are using the latest drivers, I would uninstall the interface and reinstall the driver from square one. In my case, I never fully determined if it was a hardware or software issue.

Sorry to say, my solution was to sell my interface. I now use the midi interface on my Focusrite Pro40, and it has been flawless.

HTH,
Vernon

Hi brundle: Thanks...I'm wondering, and you (or someone else may know better than I) but could it be the way the MOTU/Clockworks is configured? Like I get options of Sequencer 30, Sequencer 25, Live Keyboard, Midi Machine and direct as my choices of presets.

From what I can gather from these options/presets, the changes are in the routing of ins, outs, MTC and pedal. So I took one of them and just killed the ins and outs they had. For example, in most of their presets, channel 1 will be send to outs 1-5 and so on. When I leave it that way, if I happen to play a midi sequences from one of my hardware units, it plays it on all my midi devices. So I killed the multi outs part of it so it now says input 1 to output 1, input 2 to output 2 etc. I have 5 midi devices running. I've always wondered if something in that configuration could be the culprit, but I've tried the stock ones as they are as well not noticing any difference at all. So I just reverted back to my old faithful which has worked for many years. If you come up with anything, let me know please. Again, it's not that huge of a deal now that I know single instruments will play...but I just don't understand why this worked before and why it doesn't now. Thanks!

quibb: Thanks very much! MOTU released a new driver recently with a new version of Clockworks for my piece. When I installed it last week (hoping this would possibly fix that problem) I uninstalled the old first then put the new on in. No problems there using the 64 bit driver. I thought of possibly installing the 32 bit driver just to try it since most times I'm using Sonar 32...however, my OS is win 7 64 so I've always went with the 64 bit drivers for my hardware stuff. Maybe that's the issue? Thanks for your help. :)

John: Hey man, where you been?! A few people were asking about you in a few threads about a month ago or so. I've seen you post a bit...but have been meaning to ask how you were as well as where you've been. I hope all is well bro...good to have you back. :)

Actually, I haven't checked any of the CC's you mentioned quite honestly because I've always had a hard time understanding that stuff as well as editing it. That's one part of midi that has always boggled my mind however I admit to both laziness and ignorance as far as how the aesthetics work in the area. I remember I had this weird project one time that I sent to Willy Jones. We had a drum track that was sent from a client that would not engage any drum modules unless we literally brought the drum module into the project while audio was playing. Once we stopped playback it would be dead again. Willy found something weird in the midi filters or something with CC's and fixed the project for me. It was a bit over my head though. What you say could very well be part of the issue. Is there any way you can instruct me on what to look for as well as how to fix it? If that's too much to ask, I understand. Just think of me as an absolute dope when it comes to this part of midi. LOL!

Since I have you here and I know you know a lot about the midi stuff, can you also instruct me on a few other things please? When in Sonar's midi options....there are options like echo this, send system exclusive, cable metadata etc etc....all that stuff, there really isn't anything in the help files that explains what any of it really means in laymans terms and I've always been curious as to how much of an impact it would have on me to enable or disable those options. Like...is there a way you could give me a rough idea on how that midi options thing should look as well as what should or shouldn't be checked...and could any of it be the cause of my problem? Again, if any of this is too much to ask....it's ok, you don't have to answer but I just figured I'd ask since I know you do quite a lot of midi work in your projects. Thanks in advance for any info you can give me on this. :)

Thank you all for the info and help so far, I really appreciate it. :)

-Danny

Hi brundle: Thanks...I'm wondering, and you (or someone else may know better than I) but could it be the way the MOTU/Clockworks is configured? Like I get options of Sequencer 30, Sequencer 25, Live Keyboard, Midi Machine and direct as my choices of presets.

It's been so long since I used the MOTU in anger, I don't remember precisely how I had everything set up. But since you usually want to control what gets echoed from where to where in SONAR, the MOTU should just be in a mode where all the Ins and Outs are independent, and nothing is automatically passed through without SONAR's say-so.


I did a quick test with some canned GM sequences driving my QS8 in GM mode via the 1820m's MIDI port, and it all played swimmingly. When I get a chance, I'll fire up the XT, and try it.

How many tracks were your canned midi's?

The one I worked with the most is a cover of Steely Dan's Bodhisatva. It's 18 tracks, most of which are going all the time except maybe some of the percussion. It's pretty busy, has a lot of parts playing in unison, and has a bunch of pitch bend on the guitars, so I thought it was a pretty reasonable test.


After listening to it a few times, I looped the MIDI Out to the In, re-recorded all the tracks to a new set and loaded the whole mess into the PRV to check them out. The timing is good (typical round-trip delay of 2-3ms with an occasional outlier at maybe 5ms), and there are no dropped events as far as I can tell. For fun, I routed those new tracks to an instance of TTS-1, and played them together with the original tracks driving the QS8. It all sounds pretty tight.


I'll try to run the same test with the XT tomorrow.

Can you be a bit more clear in what you mean by: "But since you usually want to control what gets echoed from where to where in SONAR, the MOTU should just be in a mode where all the Ins and Outs are independent, and nothing is automatically passed through without SONAR's say-so."

Basically what I'm getting at here is that you would typically have controllers connected to INs, rack synths connected to OUTs, and keyboard synths connected to both. But rather than "hard-wiring" any particular controller/keyboard to any particular synth by connecting inputs directly to outputs in the the Clockworks map, you'd want to leave them all independent, and connect controllers to synths by setting the desired inputs and outputs in a MIDI track in SONAR, and enabling input echo (or using Always Echo Current MIDI Track in Preferences) to get live MIDI from any keyboard to any synth as needed.


Hope that makes sense.

I think of the routing capability of that MOTU as useful for standalone performing, not so much for DAW work. Normally, one would configure the DAW to take input from the MIDI devices and send it to the appropriate destinations, whether VST or back out to hardware.

You said: "I have 5 devices. Each one in the MOTU is set from in 1 to out 1, in 2 to out 2, in 3 to out 3, in 4 to out 4, in 5 to out 5 in the digital patch console." I think you mean that you have the MOTU set to echo every input device back to itself. This is a little unconventional I think when using a DAW.

It would be more conventional to use the DAW for all the routing. We set local control off on all the devices so that the DAW decides where incoming MIDI gets echoed, if at all. Your configuration would be almost like leaving local control on, meaning every device plays its own input, if I'm reading you right.

This by itself shouldn't cause the note hangs, but if you happen to have any devices that are configured to echo notes back into the MOTU (e.g. an out configured as a thru), you could get loops. Or if any device sends input (e.g. you playing or a built-in sequencer) while Sonar is sending output, there could be conflicts. Or if you connect a thru rather than an output. Another example: there are some MIDI synths that send a short sysex right after a patch change. Your config would cause that sysex to go back to the synth, which could kill some notes. 

The lesser MOTU (MIDI Express 128) does NO routing, and therefore cannot cause conflicts with DAW routing. As a sanity test, is there a patch or easy setting that turns off all routing?

Bill B.

Okay. I got the XT going, and it's pretty straightforward. The "Sequencer 30 fps" button on the front panelputs the XT in the mode I'm talking about, and you can see that on the Routing tab in ClockWorks if you open it after making a change from the front panel (the Routing map doesn't seem to update in real time as you change presets from the front panel, though the seleciton on the Presets tab does).

I had a quick listen to the Bodhisatva sequence, and it sounds good. I'll do the re-record test in a bit. Based on previous experience, I expect it to be comparable ot the E-MU, though the XT's round-trip was always a hair longer, which I attribute to the USB vs. PCI interface connection.

Maybe it is the routing setup that's causing all your issues somehow. I recommend you try one of the "Sequencer" presets straight away, and see if things improve.

I did the re-record test with the MOTU XT. No dropped notes, but the MIDI transmission delay is worse than I expected. Average "lateness" of recorded MIDI is 9-10ms, and the outliers are up to 18ms late.

I archived the E-MU-recorded tracks so the project conditions were essentially the same for the XT test. I'm not sure why it came out so much worse. In the past it was just 1-2 ms slower than the E-MU IIRC.

If you apply the 1ms/message rule of thumb for serial MIDI transmission, 9-10 ms is not too surprising when the sequence is sending 10-12 simultaneous messages on some beats, but 18ms seems a little extreme.

PCI MIDI rules! 


EDIT: I re-checked the E-MU-recorded tracks in light of this, and found that the latest MIDI events were more like 10ms vs. the 5ms I originally reported. I think it's because I was looking at Note Offs before, and the note durations are more variable than the start times, so there were never that many events ending at the same time.

I usually just ignore MIDI delays. With a more normal volume of MIDI messages from a live, unquantized performance by a single human, there's very little in the way of added delay due to collision of simultaneous events (barring heavy controller usage, maybe), so you're really just dealing with the base transmission delay which should be under 2ms each way, and usually closer to 1ms. Keyboard scan times and synth response delays can add to that (newer ones are faster), but to some extent, you'll compensate for that with your playing (another reason to record live performances if you have the keyboard chops).

It's easy to get hung up on this stuff. I think if you can eliminate your dropouts, it'll all be good.

I'm not sure we've completely eliminated SONAR processing errors as the source. We really need to know for sure whether the MIDI track meters show output when you get a dropped note.

I just checked, and the driver I'm running is 4.0.4.2114 dated 7/12/10 - not that new. I'll have to check what's out there now. It's always possible the newer one has issues.

Hey, Danny. I'll check 'em out, but that first link is inaccessible for me. I think it requires a login.

Well, that was an adventure. 


The Hell's Kitchen file plays fine. At first the tuning was all knackered, but I sent a GS-Reset to my QS8, and that cleared it up. Bodhisatva must have left it in a weird state. 


Anyway, after verifying that all the crazy meter changes were actually in the meter map, I listened through a few times, and it all seems to be there.


I downloaded the new drivers for the XT, but haven't installed them yet. That's next.

And the moral of the story is... if it ain't broke, don't fix it.

I installed the new driver for the XT, and I noticed it had updated the the Clockworks icon, so I opened it up to have a look, and found the only devices available were the E-MU's ports. So I went into Device Manager, and, sure enough, there is no MOTU device listed under Sound, Video and Game Controllers.

After a reboot, I still had no driver, so I reinstalled it with Run As Administrator (which shouldn't be necessary, because I have UAC disabled), and chose the "Repair" option, but I still have no MOTU driver. 

I'll have to look into it tomorrow.