Since the inception of MIDI, personal computers have become vastly more complex. Where once software MIDI Sequencers could communicate directly with the hardware for precise control of interrupts, IO and timing, their now exists multiple levels of abstraction between the application software, operating system and hardware.
Whilst this has overall made modern computers more robust, has it reduced the reliability and accuracy of computers for timing-sensitive applications like MIDI?
As a case in point, I use a MOTU MIDI Express XT for routing MIDI around my project studio. In standalone hardware mode, where MIDI data is transmitted and received via 5-pin DIN connector only, the round-trip latency to & from a hardware MIDI sequencer is a respectable 2ms with very low jitter. By comparison, disabling the hardware routing features of ine interface and routing MIDI in and out of Cubase running on a modern Mac over USB increases this figure to just over 9ms - a nearly five-fold increase. Combined with the latency of D/A converters and so forth, this has a significant effect on overall latency.
My experience with using MIDI over USB as an alternative has generally yielded an improvement in overall latency, but with an increase in associated jitter.
Manufacturer's and software developers have tried to introduce many clever techniques to combat jitter and latency, such as MIDI Time Stamping, but the implementation of such technologies is often opaque, incompatible between vendors and doesn't solve the issue with realtime MIDI communication.
So my question is: have we in fact gone backwards in terms of support for MIDI on modern computers? I am seeing a resurgence of interest in hardware sequencers (such as the Yamaha QY700) and even old computers (such as the Atari ST) for MIDI Sequencing, and I myself now sequence primarily on hardware due to ongoing issues with MIDI on both Mac and Windows.
Would be keen to hear people's thoughts.
Thanks,
Lee
Whilst this has overall made modern computers more robust, has it reduced the reliability and accuracy of computers for timing-sensitive applications like MIDI?
As a case in point, I use a MOTU MIDI Express XT for routing MIDI around my project studio. In standalone hardware mode, where MIDI data is transmitted and received via 5-pin DIN connector only, the round-trip latency to & from a hardware MIDI sequencer is a respectable 2ms with very low jitter. By comparison, disabling the hardware routing features of ine interface and routing MIDI in and out of Cubase running on a modern Mac over USB increases this figure to just over 9ms - a nearly five-fold increase. Combined with the latency of D/A converters and so forth, this has a significant effect on overall latency.
My experience with using MIDI over USB as an alternative has generally yielded an improvement in overall latency, but with an increase in associated jitter.
Manufacturer's and software developers have tried to introduce many clever techniques to combat jitter and latency, such as MIDI Time Stamping, but the implementation of such technologies is often opaque, incompatible between vendors and doesn't solve the issue with realtime MIDI communication.
So my question is: have we in fact gone backwards in terms of support for MIDI on modern computers? I am seeing a resurgence of interest in hardware sequencers (such as the Yamaha QY700) and even old computers (such as the Atari ST) for MIDI Sequencing, and I myself now sequence primarily on hardware due to ongoing issues with MIDI on both Mac and Windows.
Would be keen to hear people's thoughts.
Thanks,
Lee
The problem is nothing to do with modern computers. Just about any modern computer would be just wonderful, if there actually was one that you are free to use properly, where you could devote all the resources of the machine to your midi system.
But you cannot. The conspiracy will not allow this.
The conspiracy between the hardware manufacturers on one hand, and the OS developers on the other, who are happily playing leapfrog with each other to get at more of your money. You constantly need more powerful machines to cope with all the bells and whistles of the software (some of which might actually be useful), and more powerful versions of the OS to handle the wonders of the machine you've got.
Of course, many third parties happily play along - all the wonderful add-ons that can be installed only with the later versions of the OS. Or need a yet more powerful machine to work properly.
You need a 'special' version of the OS. I say 'special' with a note of sarcasm, in fact this should be the NORMAL version. This version does the important things, and NOTHING ELSE unless you explicitly set it up (or extend it) to do so. This would be an OS Light, or even an OS eXtra Light. OK, you might miss out on a host of bells and whistles, but you were quite happy before they were available, you can manage without them again?
This way, you might get an OS that was there to do YOUR bidding, and your bidding ONLY. No 'background tasks' that you have zero control over when they run, and what resources they take up.
Look at your 'Task Manager' and the list of active tasks. How many of them do you really need? How many do you not really know what they are or what they're doing?
I'm not sure that I've even experienced Latency or Jitter. Then, I do most of my midi playing about using a Pentium 75 running MSDOS 5. OK, no virtual synths on this box, but it takes care of my hardware synth modules happily enough.
At the end of the day, you've got a choice. Of sorts. Whose game do you play, the conspiracy's? Or your's?
Geoff
But you cannot. The conspiracy will not allow this.
The conspiracy between the hardware manufacturers on one hand, and the OS developers on the other, who are happily playing leapfrog with each other to get at more of your money. You constantly need more powerful machines to cope with all the bells and whistles of the software (some of which might actually be useful), and more powerful versions of the OS to handle the wonders of the machine you've got.
Of course, many third parties happily play along - all the wonderful add-ons that can be installed only with the later versions of the OS. Or need a yet more powerful machine to work properly.
You need a 'special' version of the OS. I say 'special' with a note of sarcasm, in fact this should be the NORMAL version. This version does the important things, and NOTHING ELSE unless you explicitly set it up (or extend it) to do so. This would be an OS Light, or even an OS eXtra Light. OK, you might miss out on a host of bells and whistles, but you were quite happy before they were available, you can manage without them again?
This way, you might get an OS that was there to do YOUR bidding, and your bidding ONLY. No 'background tasks' that you have zero control over when they run, and what resources they take up.
Look at your 'Task Manager' and the list of active tasks. How many of them do you really need? How many do you not really know what they are or what they're doing?
I'm not sure that I've even experienced Latency or Jitter. Then, I do most of my midi playing about using a Pentium 75 running MSDOS 5. OK, no virtual synths on this box, but it takes care of my hardware synth modules happily enough.
At the end of the day, you've got a choice. Of sorts. Whose game do you play, the conspiracy's? Or your's?
Geoff
Very much so looking forward to the replies here. MIDI latency has been a never ending struggle for me over the past several years. My understanding is that is essentially a problem with USB bandwidth when running a complex computer setup, much of that bandwidth having nothing to do with midi, but getting in the way and slowing things down. I'm currently looking at setting up an RTP-MIDI network at the studio in hopes for max connectivity and *fingers crossed* low low latency. I've also recently purchase the Expert Sleepers USAMO which converts midi into sample accurate audio than back to midi, ensuring sample accurate midi in the process. Very much looking forward to putting this into use, but I don't believe it's going to address the issue of MIDI latency while inputting from controllers and drum pads.
So much harder to be genuinely musical when your hits a registering late! Any expert thoughts or ideas on this dilemma would be very welcome.
So much harder to be genuinely musical when your hits a registering late! Any expert thoughts or ideas on this dilemma would be very welcome.
Are you suggesting that latency and jitter are an issue ONLY with USB connections. I had assumed that these problems could be suffered with normal midi (5 pin) connections too.
The problem with the USB link is not really to do with bandwidth, although I understand that some of the cheaper USB adaptors have more trouble, and this may be because they have inherently less bandwidth, and are therefore more prone to problems. The problem, I'd suspect, is that there is one type of USB link, and it's a type of serial link (just like the older 5 pin cable connections), and most serial links are designed to be interrupted, but to still continue. Because they CAN be interrupted, therefore, they WILL be interrupted whenever the OS wishes to do something which the OS, in it's infallible wisdom, considers to be more important/urgent. This is NOT ideal for your music app. I don't think the systems currently available allow you to set a flag for any serial links in use and tell the system that, OK, these connections CAN be interrupted, but HEY, THIS ONE CANNOT! Or, allow a scale of priorities whereby you can set your musical links as 1 (say), top priority, and other connections as something a lot less.
Another way of looking at it - there are different ways of connecting USB into a PC (or whatever), has anyone tested how these different connections affect these midi problems. Prob not because the different connections give any interent performance improvement, but because the connection gives one method a slight edge (or even a big edge) in getting priority on system resources.
Just thinking aloud!
Geoff
The problem with the USB link is not really to do with bandwidth, although I understand that some of the cheaper USB adaptors have more trouble, and this may be because they have inherently less bandwidth, and are therefore more prone to problems. The problem, I'd suspect, is that there is one type of USB link, and it's a type of serial link (just like the older 5 pin cable connections), and most serial links are designed to be interrupted, but to still continue. Because they CAN be interrupted, therefore, they WILL be interrupted whenever the OS wishes to do something which the OS, in it's infallible wisdom, considers to be more important/urgent. This is NOT ideal for your music app. I don't think the systems currently available allow you to set a flag for any serial links in use and tell the system that, OK, these connections CAN be interrupted, but HEY, THIS ONE CANNOT! Or, allow a scale of priorities whereby you can set your musical links as 1 (say), top priority, and other connections as something a lot less.
Another way of looking at it - there are different ways of connecting USB into a PC (or whatever), has anyone tested how these different connections affect these midi problems. Prob not because the different connections give any interent performance improvement, but because the connection gives one method a slight edge (or even a big edge) in getting priority on system resources.
Just thinking aloud!
Geoff
My understanding around some of the issues with latency and jitter is that it's more related to the software stack on modern computers than it is any inherent limitations of the MIDI serial or USB protocols. Case in point, my Korg Kronos has 5-pin DIN MIDI connectors thaqt are actually internally connected to the motherboard via USB, and the latency and jitter is incredibly low. However Korg have taken the time to write their own driver and kernel extensions to do this, coupled with the use of Linux Real Time extensions.
The benefit of serial is that it's simple - on older machines, a hardware interrupt could be triggered when MIDI data was received. Software could then trap that interrupt to immediately handle the incoming data. Similarly, hardware timer interrupts could be programmed to reliably send outgoing data regardless of what other tasks the computer is performing at the time. The downside of this approach was that computers couldn't really be used for reliable pre-emptive multitasking. Although modern computers still rely on interrupts, the operating system won't necessarily interrupt a given task to service the interrupt, and I believe this is part of what has lead to increased jitter and latency. The other complexity is that the modern software stack is much deeper. Applications can no longer interface directly with hardware - instead, a USB MIDI packet may first be decoded by the USB controller, passed to the operating system kernel (which will handle it when no other critical sections are running, not necessarily immediately after it's been received), passed through the vendor-specific driver, passed to Core MIDI and then eventually to the application. During any of these stages, another application or process may take priority.
So what's the solution? For me, I am relying more on hardware for sequencing and haven't really used a computer for sequencing duties in 10 years. Perhaps there will be a resurgence in dedicated hardware sequencers - secondhand Yamaha QY700s still sell for $500 20 years after their release, so there must be some demand. What I'd love to see though is a resurgence in simpler computers and operating systems that are less generalist and and better suited for the task at hand, where real-time performance is prioritised over other elements, such as security or networking or 3D graphics.
The benefit of serial is that it's simple - on older machines, a hardware interrupt could be triggered when MIDI data was received. Software could then trap that interrupt to immediately handle the incoming data. Similarly, hardware timer interrupts could be programmed to reliably send outgoing data regardless of what other tasks the computer is performing at the time. The downside of this approach was that computers couldn't really be used for reliable pre-emptive multitasking. Although modern computers still rely on interrupts, the operating system won't necessarily interrupt a given task to service the interrupt, and I believe this is part of what has lead to increased jitter and latency. The other complexity is that the modern software stack is much deeper. Applications can no longer interface directly with hardware - instead, a USB MIDI packet may first be decoded by the USB controller, passed to the operating system kernel (which will handle it when no other critical sections are running, not necessarily immediately after it's been received), passed through the vendor-specific driver, passed to Core MIDI and then eventually to the application. During any of these stages, another application or process may take priority.
So what's the solution? For me, I am relying more on hardware for sequencing and haven't really used a computer for sequencing duties in 10 years. Perhaps there will be a resurgence in dedicated hardware sequencers - secondhand Yamaha QY700s still sell for $500 20 years after their release, so there must be some demand. What I'd love to see though is a resurgence in simpler computers and operating systems that are less generalist and and better suited for the task at hand, where real-time performance is prioritised over other elements, such as security or networking or 3D graphics.
To folow up your final point...
In the old days, the PC started under DOS by loading CONFIG.SYS, then AUTOEXEC.BAT, which installed your standard extras.
Windows still has these, but they don't really apply to Windows as such. Windows just proceeds to load pretty much everything you've ever used/installed, regardless of wether you really need it for the immediate task.
Back in the old days, you could set up AUTOEXEC to run a menu, and select a second AEXEC2 (say) and you might have different versions, loading different combinations of extras.
It would be interesting if WinDoze allowed something like this, you might have templates for a full-blown total hand-holding Windoze at one extreme, and at the other end a zero frills, extra lean, super fast, setup that did ONLY what you really want/need, and as near to NOTHING ELSE as you can get..
Of course, the designers don't seem to think that mere 'users' are clever enough to cope with anything like this?
Geoff
In the old days, the PC started under DOS by loading CONFIG.SYS, then AUTOEXEC.BAT, which installed your standard extras.
Windows still has these, but they don't really apply to Windows as such. Windows just proceeds to load pretty much everything you've ever used/installed, regardless of wether you really need it for the immediate task.
Back in the old days, you could set up AUTOEXEC to run a menu, and select a second AEXEC2 (say) and you might have different versions, loading different combinations of extras.
It would be interesting if WinDoze allowed something like this, you might have templates for a full-blown total hand-holding Windoze at one extreme, and at the other end a zero frills, extra lean, super fast, setup that did ONLY what you really want/need, and as near to NOTHING ELSE as you can get..
Of course, the designers don't seem to think that mere 'users' are clever enough to cope with anything like this?
Geoff
Hi Geoff,
One of the nice things about Windows - even today - is that you can still customise what runs and what doesn't. You can make a very lean installation of Windows by disabling startup items and unnecessary services, as well as disabling device drivers that have high Deferred Procedure Call counts. Microsoft even make versions of Windows 10 that can run on very minimal hardware such as the Raspberry Pi.
Newer versions of macOS aren't as configurable unfortunately, but tend to perform well out of the box.
However, even with a minimum number of services and background processes running, I'm not sure this alleviates the issue. Modern operating systems use what is called "protected mode pre-emptive multitasking". What this really boils down to is that fact that the Operating System dictates what runs and when, and attempts to provide fairness of resource usage. This is what makes modern operating systems much more stable when running multiple applications - application can't interfere with one another, they can only run for a maximum amount of time in a slice as dictated by the OS. However, this also means that any "time critical" activities, such as processing an incoming MIDI message may be deferred. This actually makes sense from a stability perspective - if the computer is halfway through say, sending a network packet, interrupting that to receive MIDI would lead to data corruption!
On older MS-DOS computers, whatever program was running at the time were able to take complete control of the machine. This meant that a MIDI sequencer could take control of the machine as soon as a MIDI message was received, and this was guaranteed in hardware through the use of interrupts. The downside is that whatever program was running at the time took complete control of the machine - which meant that if the MIDI sequencer didn't relinquish control back to Windows, other processes may break.
So modern operating system design is great for general purpose use cases that aren't real-time in nature, but music IS real-time in nature. Solutions exist to this problem, and there are versions of both Windows and Linux that are customised to guarantee reliable timing. What I'd love to see is perhaps someone release an entire operating system dedicated to music making. This is essentially what the Korg Kronos is. A highly customised Linux computer with modifications to ensure accurate timing, and the latency of both audio and MIDI on that thing is ridiculously tight, even on its modest Atom processor. Wouldn't it be amazing if I could boot into a dedicated OS and run Cubase with timing as tight but all the advantages of modern driver support, VSTs etc?
Now on top of the limitations of modern operating systems, USB presents its own unique challenges around bus contention and polling...
One of the nice things about Windows - even today - is that you can still customise what runs and what doesn't. You can make a very lean installation of Windows by disabling startup items and unnecessary services, as well as disabling device drivers that have high Deferred Procedure Call counts. Microsoft even make versions of Windows 10 that can run on very minimal hardware such as the Raspberry Pi.
Newer versions of macOS aren't as configurable unfortunately, but tend to perform well out of the box.
However, even with a minimum number of services and background processes running, I'm not sure this alleviates the issue. Modern operating systems use what is called "protected mode pre-emptive multitasking". What this really boils down to is that fact that the Operating System dictates what runs and when, and attempts to provide fairness of resource usage. This is what makes modern operating systems much more stable when running multiple applications - application can't interfere with one another, they can only run for a maximum amount of time in a slice as dictated by the OS. However, this also means that any "time critical" activities, such as processing an incoming MIDI message may be deferred. This actually makes sense from a stability perspective - if the computer is halfway through say, sending a network packet, interrupting that to receive MIDI would lead to data corruption!
On older MS-DOS computers, whatever program was running at the time were able to take complete control of the machine. This meant that a MIDI sequencer could take control of the machine as soon as a MIDI message was received, and this was guaranteed in hardware through the use of interrupts. The downside is that whatever program was running at the time took complete control of the machine - which meant that if the MIDI sequencer didn't relinquish control back to Windows, other processes may break.
So modern operating system design is great for general purpose use cases that aren't real-time in nature, but music IS real-time in nature. Solutions exist to this problem, and there are versions of both Windows and Linux that are customised to guarantee reliable timing. What I'd love to see is perhaps someone release an entire operating system dedicated to music making. This is essentially what the Korg Kronos is. A highly customised Linux computer with modifications to ensure accurate timing, and the latency of both audio and MIDI on that thing is ridiculously tight, even on its modest Atom processor. Wouldn't it be amazing if I could boot into a dedicated OS and run Cubase with timing as tight but all the advantages of modern driver support, VSTs etc?
Now on top of the limitations of modern operating systems, USB presents its own unique challenges around bus contention and polling...
I spent some time today measuring MIDI latency in various configurations, and the results are rather interesting.
Using a MOTU MIDI Express XT with various software packages on a Mac , and using the DAW to echo MIDI messages back from a hardware sequencer, there were vast differences in the MIDI round trip latency. Cubase had the lowest latency, at around 6ms, Studio One was around 13ms, and Reaper was around a whopping 27ms (with low latency, low precision turned off).
Using USB, rather than DIN MIDI took around 4ms off each of these times.
The other interesting thing was that disabling the audio engine in Cubase, and just using it for MIDI, substantially reduced jitter. With audio enabled, there was around +/- 2ms jitter for each message. With audio disabled, this dropped to practically zero.
Using a MOTU MIDI Express XT with various software packages on a Mac , and using the DAW to echo MIDI messages back from a hardware sequencer, there were vast differences in the MIDI round trip latency. Cubase had the lowest latency, at around 6ms, Studio One was around 13ms, and Reaper was around a whopping 27ms (with low latency, low precision turned off).
Using USB, rather than DIN MIDI took around 4ms off each of these times.
The other interesting thing was that disabling the audio engine in Cubase, and just using it for MIDI, substantially reduced jitter. With audio enabled, there was around +/- 2ms jitter for each message. With audio disabled, this dropped to practically zero.
- Page :
- 1
There are no replies made for this post yet.
