May 17, 2007

It's all in the time----ing...

by Chris Randall
 

I'm having an odd problem with my system, and I was wondering if perhaps one of my dear readers has had a similar problem, and what the solution might be. Here is the general layout of things:


1. When I have an empty project with no recordings playing back (and thus no disk access) my MIDI timing is rock-solid sampleframe accurate. This is MIDI either being played back from the sequencer or being passed through to an external device. (I'll grant that the latter is hard to test, and I'm more or less just going on feel.)


2. The more tracks I add to the project, the worse the timing gets, and by the time I'm up to my normal track count for an instrumental (which is 30 to 50 stereo tracks) the MIDI timing is so bad as to be essentially useless. Here is an example. What you're hearing is 32nd notes fired every 16th from the DAW to an MKS80, and recording the result. The only way I can get it that good is to open my buffer all the way; I normally run it at 64, but with it set that low, maybe 5 of those notes will trigger, and in the wrong spot, natch. That's at the AES16's highest buffer setting, 1024.


So that's what's happening. The rig is Cubase 4 on Vista Business, on an Athlon64 machine. The audio is streaming off a half-TB RAID 0 array, and the MIDI interface is a MOTU MIDI Express 128. I have tried all the usual methods of getting Cubase to comply; you can rest assured on that account. I've been using PCs for music for over a decade, and Cubase almost that long. I know how to run and tune this rig; this is why this particular issue is giving me some trouble, as it falls outside my experience.


In any event, it is obviously related to the disk streaming. The more audio that is getting played back from the DAW, the worse the timing. Anyone run in to this before? If so, what's the fix?

 
 
 

34 comments:

Page 4 of 4
 
 

 
May.19.2007 @ 3:47 PM
Adam Schabtach
"in my mind and in my car
we can't [system] restore we've gone too far
Vista came and broke your card
Put your blame on PCI.

Video killed the MIDI I/O
Video killed the MIDI I/O
Video killed the MIDI I/O
Video killed the MIDI I/O"

--Adam

 
 

 
May.19.2007 @ 10:25 PM
penzoil washington
I'm actually having nagging Mac software issues at the moment, so this isn't a sneer at PC headaches, but part of what you do get with a Mac is an OS that is obliged to support Apple-supplied video cards, etc., over quite a long period of time.
 
 

 
May.22.2007 @ 7:41 AM
valis
Well the Vista driver issues are largely Nvidia's problems. Other vendors are at least stable & performing somewaht decently. It's a well known issue in the 'pc' world. Kind of strange too because Nvidia typically has far more robust driver sets than ATI & co, especially where non-gaming features are concerned.
 
 

 
May.23.2007 @ 1:50 PM
itdoesntsuck
Hopefully someone will read this late addition.

One possible Kludge around CR's problem would be to remove the video card entirely from your music box and use remote desktop (or Dameware, etc.) to control the unit remotely. FYI the latest incarnation of remote desktop supports dual monitors. If you're using your computer to edit video this obviously won't work.

I've always thought that a good way to go would be to have one stripped down computer running a pure sequencer app for MIDI I/O sync'd to a computer doing all of the audio processing.

If anyone out there is thinking of writing such an app; please include a test suite that will measure average MIDI processing delay times for each outboard unit so that each unit's response can be 'normalized'. Also add to this a MIDI interface that doesn't add time delay to socket "8" relative to socket "1"

BTW, has anyone fooled with elektron's TurboMIDI unit? It's supposed to produce more accurate timing by increasing MIDI bandwith 8-10 times. I assume it only works w/ elektron's units.

 
 

 
Page 4 of 4
 
 

Comment:

 

Sorry, commenting is closed for this blog entry.