ORIGINAL: Nick P

From what I gather, it's the way MIDI is processed up and down the pipe by the OS which needs reworking. MIDI events probably sit in the queue like every other process waiting to get worked over by the CPU. I think that's where the problem lies.

Pretty much. If you ditch all the technical details. Standalone boxes (e.g. Akai 'MPC' boxes) show that MIDI DIN 1.0 can deliver pretty good timing, when handled right. (Not perfect timing, but good enough for most purposes).

And, MIDI is a serial interface - one note at a time - even when you play chords and uch. That's always been an issue.

"Serial" doesn't have much to do with it. USB and Firewire are both serial protocols; they just move bits a heck of a lot faster. MIDI DIN is a slow protocol by current standards - only about 3K bytes/second (31.25K bits/second, moving 10-bit words including start & stop bits, yada yada). However, because MIDI DIN is dedicated to MIDI and nothing else, those few bits can be placed "right in the pocket", which works well unless there's too much data (pitchbend is notorious) going over the wire at any point in time. Then, MIDI lags occur. (Of course, it only 'works well' if nothing else in the chain screws things up - like an OS or driver that doesn't maintain the timing accuracy of the bits coming 'off the wire').

There needs to be a MIDI 2, but I don't think there would be enough interest now.

Oh, there's definitely interest. The standards folks are still working on "HD MIDI" (Google it) -- these things just take time to percolate. If HD MIDI doesn't happen, something else will come along eventually. Don't give up! (Not that this helps any musician struggling with a DAW today, unfortunately....)

- Jim

ORIGINAL: Nick P

From what I gather, it's the way MIDI is processed up and down the pipe by the OS which needs reworking. MIDI events probably sit in the queue like every other process waiting to get worked over by the CPU. I think that's where the problem lies. And, MIDI is a serial interface - one note at a time - even when you play chords and such. That's always been an issue. There needs to be a MIDI 2, but I don't think there would be enough interest now.

I don't agree with some of that. The thread has just been speaking about a Disklavier. A friend and I were talking about one last week. Go to your local piano store and test one out if you want to hear how good midi can be. Nearly any piano store will have a C-3. (I'm holding out for a C-7). Pick the most complex performance available and critically listen. You will be stunned. Also demo a Yamaha Tyros 2 or 3. I have an original Tyros. The sequencer is fabulous. But editing is a chore. You can have hundreds of events happening concurrently. The result is perfect reproduction of any performance. Midi is not the problem. We need a music specific OS AND people that can extract the best possible performance from midi interfaces and software.

Danny

ORIGINAL: pianodano

I don't agree with some of that. The thread has just been speaking about a Disklavier.

Duly noted. And as mentioned a few posts back, the Disklavier apparently has a more robust, "enhanced" MIDI implementation, specific to Yamaha's products, that achieves greater resolution and precision than the MIDI spec that other interfaces and instruments use. But as this thread originally started as a discussion about MIDI timing stability in general, and more specifically the issues involved in accurate MIDI recording and playback on a standard-OS computer system, it's interesting to compare the Zenph / Disklavier situation with that of the typical studio. I think what we're all clamoring for here is widespread public access, within the DAW platforms that we're already accustomed to using, to the kind of resolution and accuracy that Zenph is apparently achieving through proprietary means. Because, in theory, the professional-level producer / musician / DAW consumer should have access to a level of quality from MIDI at least equal to that of audio. But as we've all seen, audio is more exciting, gets more attention, and has more obvious consequences when it gets something wrong - for years, anybody who complained about MIDI timing has been dismissed as being either paranoid, delusional, or too picky.

ORIGINAL: RTGraham

ORIGINAL: pianodano

I don't agree with some of that. The thread has just been speaking about a Disklavier.

Duly noted. And as mentioned a few posts back, the Disklavier apparently has a more robust, "enhanced" MIDI implementation, specific to Yamaha's products, that achieves greater resolution and precision than the MIDI spec that other interfaces and instruments use. But as this thread originally started as a discussion about MIDI timing stability in general, and more specifically the issues involved in accurate MIDI recording and playback on a standard-OS computer system, it's interesting to compare the Zenph / Disklavier situation with that of the typical studio. I think what we're all clamoring for here is widespread public access, within the DAW platforms that we're already accustomed to using, to the kind of resolution and accuracy that Zenph is apparently achieving through proprietary means. Because, in theory, the professional-level producer / musician / DAW consumer should have access to a level of quality from MIDI at least equal to that of audio. But as we've all seen, audio is more exciting, gets more attention, and has more obvious consequences when it gets something wrong - for years, anybody who complained about MIDI timing has been dismissed as being either paranoid, delusional, or too picky.

I don't know anything about a more robust midi implementation on the Disklavier. But I do know that the Tyros (their flagship) arranger sequencer uses typical 1920 ppqn and is capable of recording 16 midi tracks at once. I also know that the first time I plugged it (Tyros) into my Roland MC-500, old reliable choked on that data stream. Close examination showed dozens and dozens of sysex data streams and controllers I didn't even know existed. To this day I don't know what many of the obscure controllers do. But anyhow, the Roland choking on todays amount of data is why I opted to go with a DAW 5 years ago. I agree Sonar does good job with audio alone. In my mind the problem today still, is keeping midi in sync with the audio and that hasn't changed since I started using Sonar. And yes as you pointed out, I was called a nut case back then too when I pointed it out. But I can sure hear it and it seens lots of others can now too.

Danny

MIDI came out in 1982. That means it was probably being worked on as early as the late 1970s. You can't expect that it would still be able to compete with the latest transfer speeds and methods. That's why I wish they would do a MIDI 2. It's been talked about for years, but never acted on. Basically, all of these high-tech digital workstations are still shuttling MIDI in, out, and thru (pun intended) their innards using a technology that's not been updated in over 25 years!

Jitter is not something that can be eliminated, but it can be reduced to an imperceptible level. Higher resolution is not necessarily the answer. You may find that you can hear more jitter with 960 ppqn than with 96 ppqn. Depending on how the drivers and buffers work, higher resolutions might preoccupy the timers with buffer management so as to distract them from obtaining accurate results. Some higher resolution detection processes have to run their entire routine for every ppqn. If they cannot do that efficiently or experience any interruptions they can be delayed significantly. Use a MIDI ppqn that is only as high as you really need and you might find you get playback that feels more like your initial performance. Depending on what programs you use and what MIDI interfaces, you may need to find the sweet spot.

What is interesting is that when you measure playback jitter in windows you can see it is about the same generally across applications. What varies is the pattern it takes. It is good to think of jitter as tempo changes. You could create the same effect by doing a tempo map in Sonar. So when a midi event plays say 1ms earlier than it should based on tempo, the tempo has increased slightly. It also means that every sequencer overcompensates in order to keep the tempo correct. So if a note plays 1ms early then at some point a note or notes have to play late by 2ms in order to push the tempo back to the expected value. Every sequencer does this I think in order to keep lengths at what they should be. I think syncing to something would be impossible for example if jitter was not compensated for in this way. But when you look at clocks in the sequencer you may think things are better than they are because you just see a 1 tick difference up or down when in fact the turnaround is 2 ticks. You only realize this when you measure the midi data train itself and see what the actual timing of each midi event is. In Sonar the pattern can be very regular: 2 events at 120bpm, next note delayed about 2ms, next note played ahead about 2ms, and the pattern repeats. At a different tempo you get a different pattern. Other sequencers vary the pattern a bit but the 2 up/2 down seems pretty consistent whether it occurs in succession or is spread out a bit over time. I haven't measured a windows sequencer yet that differs from this and I've measured a bunch. OSX isn't any better. In fact in some ways it is worse (under load things get loose). You want tight timing? An Amiga or Atari is it. An Amiga is slightly better but both are light years ahead of windows or osx. You're talking variations that average about .2ms and never more than .5ms.

Jon

Hi Jon,

What kinds of MIDI interfaces are you testing?
USB 1.0 protocols uses a 1 millisecond 'frame rate', so under best-case circumstances, events will be quantized to a 1-millisecond window. USB 2.x supports micro-frames (0.125 millisecond rate), so in theory quantizing effects could be smaller.

If you're testing MIDI I/O on a Mac, using a non-timestamping USB MIDI interface, I would expect the lower jitter bound to be around 1 millisecond, more or less. That doesn't mean you'll get such tight timing in practice - that's just the best you could expect if the rest of the software was working with very close tolerances..

Of course, under Windows, many apps probably still use the 'Windows multimedia timer' (MMT) - which has a nominal accuracy of 1-millisecond, but is not very precise (ticks can be delayed for lots of reasons, and then 'delayed' ticks can be sent in a clump - speaking imprecisely here). An app that uses the MMT for timing and USB MIDI for MIDI I/O will generally exhibit worse jitter than an app that uses the MMT and a PCI-based card for MIDI I/O. (Reason: jitter effects are cumulative).

- Jim

ORIGINAL: Nick P

MIDI came out in 1982. That means it was probably being worked on as early as the late 1970s. You can't expect that it would still be able to compete with the latest transfer speeds and methods. That's why I wish they would do a MIDI 2. It's been talked about for years, but never acted on. Basically, all of these high-tech digital workstations are still shuttling MIDI in, out, and thru (pun intended) their innards using a technology that's not been updated in over 25 years!

well at least midi is one of the only standards in audio that work ****ing 99,99% of the time you use it - actually we should be more than happy that we still have it almost everywhere - my old analog midified synths kick those plugs ass - in latency AND sound AND ease of editing...btw i never had any midi jitterproblems - eventually its all those friggin usb midiinterfaces that ruin the performance...


edit: ... transfer of Note On/Off command takes from 0,64 to 0,96 ms via MIDI and from 0,64 to 2,464 ms via DCB....

>> transfer of Note On/Off command takes from 0,64 to 0,96 ms via MIDI and from 0,64 to 2,464 ms via DCB....

DCB ?

- Jim