dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 21:31:53
(permalink)
ORIGINAL: pianodano
In the instance quoted I am referring to a tweaked (perfectly satisfactory) midi track which is driving the softsynth and what then happens to the audio after said audio is frozen. Realguitar is a perfect source to test this because every note has a strong attack. It may play along perfectly for a while and then suddenly 2 or 3 notes get screwed up. Somehow during the freeze process the audio becomes slightly mis timed and it usually continues to get worse. YMMV. It is a part of the frozen track and will always be and start in the same place - Not randon.
Yea man, I hear ya. I'm trying to identify whether the problem is that the freezing process is messing it up, as you believe, or if rather, the whole time you are tweaking it in the PRV...what you are hearing is not correct...you tweak it and make it "sound" correct..but then the freezing process makes it sound wrong again...perhaps the frozen version is actually exactly what is shown in the PRV, but what you tweaked in the PRV was made wrong because you weren't hearing it right while you were tweaking it...see what I mean? I'm much more suspicious that the midi track plackback unfrozen would be incorrect than that track freezing would be wrong...but then again..who knows.... Sounds like something is not right somewhere in there though...
|
Jim Wright
Max Output Level: -66 dBFS
- Total Posts : 1218
- Joined: 2004/01/15 15:30:34
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 21:34:35
(permalink)
ORIGINAL: dewdman42
The problems that I keep hearing people talk about on here I think are mostly much greater than 1-2ms of discrepency. That implies to me they are having DRASTIC midi timing problems under certain circumstances and those are the situations we need to identify and try to get Cakewalk to fix. I've heard a scattering of stories here, but one common theme seems to be related to audio buffer sizes and I'm wondering if delay compensation is a culprit here.
That sounds right to me. When I was a MIDI test-aholic (around 2000) - I found some truly 'pathological' situations where audio and MIDI drivers clashed. MIDI jitter of 80 to 400 milliseconds (yes, up to four hundred) could easily result. 1st-generation USB MIDI interfaces tested out at 7+ milliseconds of jitter, btw. Newer ones have been measured (by Martin Walker) with jitter levels around 1-2 milliseconds. What we need -- is a fairly simple way for Sonar users to test their set up, and see if it's gone really wonky. Ok, I just Googled. The easiest way to test MIDI latency, today, is probably with the Miditest utility written by Evert van der Poll. See http://www.soundonsound.com/sos/apr04/articles/pcnotes.htm for a writeup. See http://earthvegaconnection.com/evc/products/miditest/index.html for the actualy utility (freeware). Caveat: I haven't tried it myself, and can't vouch for it. If you try it - let us all know how it works for you! - Jim
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 21:37:34
(permalink)
ORIGINAL: Jim Wright
Agreed: that's not the answer. What's needed is a) MIDI interfaces that really timestamp; b) MIDI drivers that respect timestamps; c) MIDI sequencers that use timestamps, every step of the way.
Yep. Seems like everyone gave up on that when most consumers decided that 1-2ms of jitter was acceptable. (shrug). hardware timestamping during record is the only way around XP and OSX limitations IMHO. Playback is another story, pretty difficult for external midi, but Sonar should absolutely be able to make sure that playback to softsynths during mixdown and freezing is 100% jitter free. Even playing back a project through softsynths should be jitter free as far as I'm concerned...if there are problems...then it must be related to various buffers and programming in Sonar that needs to be improved.
Since the standard Windows 'MM' MIDI driver stack doesn't use timestamps - look for MIDI interfaces that support the DirectMusic Core API (which does). Since stock USB MIDI doesn't use timestamps (and has inherent jitter of 1-2 msec in every USB interface I've seen) -- look for alternatives if you want lower jitter than that. What alternatives? PCI-based interfaces (EMU still makes them, cunningly disguised as an EMU 1616M and the like). Non-stock USB interfaces (i.e. the MOTU interfaces that use their own proprietary MIDI timestamping protocol). Firewire interfaces (The Firewire MIDI spec doesn't timestamp, but does support accuracy down to 1/3 millisecond).
Yea. I have to say though, I have MOTU traveler and the midi is VERY latent compared to my MOTU parallel port interface. Probably not the fault of firewire, it probably has timestamping though.
It would be a big help if Cakewalk would test Sonar's MIDI timing performance with different MIDI interfaces, and post the results. Now, that might tick off some of the MIDI interface vendors - but it would certainly be a service to Sonar users.
Yea, that would be nice.
|
pianodano
Max Output Level: -67 dBFS
- Total Posts : 1160
- Joined: 2004/01/11 18:54:38
- Location: Va Beach Virginia
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 21:43:42
(permalink)
ORIGINAL: dewdman42
The problems that I keep hearing people talk about on here I think are mostly much greater than 1-2ms of discrepancy. They are blatantly bad midi timing glitches. That implies to me they are having DRASTIC midi timing problems under certain circumstances and those are the situations we need to identify and try to get Cakewalk to fix. I do not think Cakewalk can do anything about the 1-5ms range of jitter due to limitations of the operating system.
I've heard a scattering of stories here, but one common theme seems to be related to audio buffer sizes and I'm wondering if delay compensation is a bigger culprit here with some of these stories about seemingly drastic midi timing problems.
You're on to it now. Look in my case, I'm getting older now so I really don't expect my timing to be as precise as it was in the 70's and 80's. But dag nab it, I had tempos drilled in my head so many years, I felt like an atomic clock. I can nail it on tape OR if I startup the old MC500 I can still hit pretty darn close to a consistent 5 to 10 ticks late (its 480 or 96tpqn) if I feel the part should be laid back that way. But I cannot reliably put it in the pocket with my current DAW setup.. I really wish I knew why.
Best, Danny Core I7, win XP pro, 3 gig ram, 3 drives- Lynx Aurora firewire- Roll around 27 inch monitor, 42 inch console monitor- Motif xs controller - Networked P4's and FX Teleport for samples- Muse Receptor VIA Uniwire for samples and plugs- UAD QUAD Neve - UAD 1- Sonar X1 but favor 8.5 GUI - Toft ATB 32 - Vintage hardware - Tascam MS-16 synched via Timeline Microlynx -Toft ATB32 console
|
pianodano
Max Output Level: -67 dBFS
- Total Posts : 1160
- Joined: 2004/01/11 18:54:38
- Location: Va Beach Virginia
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 21:47:04
(permalink)
ORIGINAL: dewdman42
ORIGINAL: pianodano
In the instance quoted I am referring to a tweaked (perfectly satisfactory) midi track which is driving the softsynth and what then happens to the audio after said audio is frozen. Realguitar is a perfect source to test this because every note has a strong attack. It may play along perfectly for a while and then suddenly 2 or 3 notes get screwed up. Somehow during the freeze process the audio becomes slightly mis timed and it usually continues to get worse. YMMV. It is a part of the frozen track and will always be and start in the same place - Not randon.
Yea man, I hear ya. I'm trying to identify whether the problem is that the freezing process is messing it up, as you believe, or if rather, the whole time you are tweaking it in the PRV...what you are hearing is not correct...you tweak it and make it "sound" correct..but then the freezing process makes it sound wrong again...perhaps the frozen version is actually exactly what is shown in the PRV, but what you tweaked in the PRV was made wrong because you weren't hearing it right while you were tweaking it...see what I mean? I'm much more suspicious that the midi track plackback unfrozen would be incorrect than that track freezing would be wrong...but then again..who knows.... Sounds like something is not right somewhere in there though...
Man you have good insight on the issue. Interesting hypothesis. Thanks
Best, Danny Core I7, win XP pro, 3 gig ram, 3 drives- Lynx Aurora firewire- Roll around 27 inch monitor, 42 inch console monitor- Motif xs controller - Networked P4's and FX Teleport for samples- Muse Receptor VIA Uniwire for samples and plugs- UAD QUAD Neve - UAD 1- Sonar X1 but favor 8.5 GUI - Toft ATB 32 - Vintage hardware - Tascam MS-16 synched via Timeline Microlynx -Toft ATB32 console
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 21:57:45
(permalink)
ORIGINAL: pianodano
You're on to it now. Look in my case, I'm getting older now so I really don't expect my timing to be as precise as it was in the 70's and 80's. But dag nab it, I had tempos drilled in my head so many years, I felt like an atomic clock. I can nail it on tape OR if I startup the old MC500 I can still hit pretty darn close to a consistent 5 to 10 ticks late (its 480 or 96tpqn) if I feel the part should be laid back that way. But I cannot reliably put it in the pocket with my current DAW setup.. I really wish I knew why.
ah ha. MC500 was 96ppq. Well playing into a pocket is not needing necessarily more than 96ppq. You are still essentially getting it to land your notes evenly on a tick. So in fact, the 96ppq was actually giving you an automatic form of input quantize, which made your parts sound tighter..because even if you were actually playing a little looser than you might think...the 96ppq was input quantizing you, mostly to the correct tick for each note. See what I mean? And then when you played it back, it sounded even tighter than when you played it....but 96ppq is precise enough to not sound "quantized". The main advantage at that point is the zero jitter that the MC500 was giving you, making your grooved performance sound absolutely tight according to a 96ppq grid. In case you're wondering, 96ppq = 1/128th triplets. I don't think you can ever get this from Sonar except with a midi interface that does hardware timestamping. If you get an interface like that, then set the resolution to 96ppq and try it out. The sonic latency will be off though...which might screw you up, but timing wise that should be as close as you're going to get to it. Otherwise, use the MC500 or get a Mc-50mkII and transfer the tracks to Sonar after laying them down. The OS limitations will not solve that problem. However, the track freezing issue is something else entirely I think.
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 22:09:36
(permalink)
By the way, one review I read about one of the MPC's said; that the argument from Akai about why 96ppq is enough? They said that their feeling is that if you need more than 96ppq precision then you should just record directly to tape without any quantization at all. Of course, that assumes you are a pro with the skills to play every note accurately to tape, and also that you have no desire to alter the sound source after the fact or editing the notes creatively. Kind of a weak excuse if you ask me. But undoubtedly there are constraints and we don't really know for sure that the expensive 480ppq MPC is jitter free. Perhaps the older boxes are jitter free only because they use a low resolution of 96ppq which give them 5ms between every tick to do what they need to do. Myself, I prefer to record without quantize and then I go fix the few odd notes that I was too loosy goosy on. The rest are unquantized. But now you have me thinking that I would probably be best off most of the time using something like 64-128ppq to basically be a form of input quantize.....most of the time. Occasionally I would need to lay down something with more precision. But if the jitter is off by 1-2ms anyway...a lot of this is kind of a moot point anyway. However, it does show a nice advantage to using a hardware sequencer for laying down grooves..and that is probably not likely to change for quite a while. PianoDano, one suggestion I would have for you is to try recording with input quantize set to 1/128th notes or 1/128th triplets. The jitter will still be there...but perhaps the input quantize will mostly correct the notes to where they need to be. it will mostly fall into that tight performance you used to get with the MC500. However, playback jitter, and the freezing problem..that may still be a problem I guess....
post edited by dewdman42 - 2007/10/08 22:27:08
|
dstrenz
Max Output Level: -69 dBFS
- Total Posts : 1067
- Joined: 2005/12/10 09:59:06
- Location: Rochester, NY
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 22:39:15
(permalink)
Thank for the details, Jim (and pianodano)! It's getting late so I'll test tomorrow evening and post the results.
|
strungdown
Max Output Level: -79 dBFS
- Total Posts : 573
- Joined: 2007/04/12 13:15:26
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 23:01:01
(permalink)
Greetings amigos! You may be interested in the article, Inside Windows NT High Resolution Timers available at http://www.microsoft.com/technet/sysinternals/information/highresolutiontimers.mspx "High resolution timers are desirable in a wide variety of different applications. For example, the most common use of such timers in Windows is by multimedia applications that are producing sound or audio that require precise control. MIDI is a perfect example because MIDI sequencers must maintain the pace of MIDI events with 1 millisecond accuracy. This article describes how high resolution timers are implemented in NT and documents NtSetTimerResolution and NtQueryTimerResolution, the NT kernel functions that manipulate and return information about the system clock." There's also a tool at http://www.microsoft.com/technet/sysinternals/SystemInformation/ClockRes.mspx to tell your your Clock Resolution I get 15.6 ms on my system.
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/08 23:32:58
(permalink)
Note that this tool is only supposed to operate correctly on NT4 or Win2k. Its not designed for XP.
Nonetheless, many tests have been done by people showing that 1ms is almost never obtained in reality.
|
Nick P
Max Output Level: -44 dBFS
- Total Posts : 3112
- Joined: 2006/09/01 18:08:09
- Location: Area code 392 - Arlington Hts, IL
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 04:25:38
(permalink)
I said this a few posts ago - think about 120BPM - set it as a quarter note click. Now think about each click being divided into 96 parts. I think you'd be hard pressed to be able to discern anything much finer. Not that I'm complaining about the higher PPQs. I remember when DP first came out at 480PPQ. And so on. What are we up to now, like 4800PPQ or something? But who cares? If the operating system (Windows or Mac) and other software is introducing anomalies into the stability of the MIDI output, then who cares how many PPQs the system is resolving at? It doesn't matter because the whole system is unstable. I think that's what we've been talking about throughout this whole thread.
By the way, I haven't tried it, but from the videos and audio demos, the Roland MV-8800 is a really tight and funky feeling workstation (hardware). I don't know what it clocks out at, but it's most likely very stable at dealing with MIDI. It will be interesting to see where Roland goes with the linear audio + MIDI hardware solutions they've been producing. They're due for something new at this coming Winter's NAMM. Right now the Fantom-X keyboards and the MV-8800 record both linear audio and MIDI. I think they're the only hardware rompler workstation manufacturer to be producing this format.
Cakewalk Forums - A Great Learning Resource For All Things Cakewalk!
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 05:39:09
(permalink)
The feedback I'm hearing is that a lot of that is going away as people are moving to using tools like Reason and Guru and satisfied with the results. You can find an MC-808 groovebox, the latest from Roland, on ebay for under $600 these days.
|
RTGraham
Max Output Level: -57 dBFS
- Total Posts : 1824
- Joined: 2004/03/29 20:17:13
- Location: New York
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 06:13:24
(permalink)
ORIGINAL: pianodano
In the instance quoted I am referring to a tweaked (perfectly satisfactory) midi track which is driving the softsynth and what then happens to the audio after said audio is frozen. Realguitar is a perfect source to test this because every note has a strong attack. It may play along perfectly for a while and then suddenly 2 or 3 notes get screwed up. Somehow during the freeze process the audio becomes slightly mis timed and it usually continues to get worse. YMMV. It is a part of the frozen track and will always be and start in the same place - Not randon.
I wonder if this is a Fast Bounce issue. Have you tried disabling Fast Bounce? Some plugins have audio artifacts or misplaced notes when you render with Fast Bounce; if you disable it and bounce in realtime the rendered audio is accurate. With BFD, for example, I have to engage the "B" (for Bounce) button in BFD's interface *and* disable Fast Bounce in SONAR if I want to know conclusively that my rendered audio will be accurate. If I forget either step, there's the potential for glitchy audio or notes that move. I have yet to see an explanation of why some softsynths are fine with Fast Bounce and some aren't, but maybe someone has the answer.
|
kwgm
Max Output Level: -52.5 dBFS
- Total Posts : 2271
- Joined: 2006/10/12 00:14:20
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 10:22:10
(permalink)
ORIGINAL: dewdman42
ORIGINAL: Jim Wright
Agreed: that's not the answer. What's needed is a) MIDI interfaces that really timestamp; b) MIDI drivers that respect timestamps; c) MIDI sequencers that use timestamps, every step of the way.
Yep. Seems like everyone gave up on that when most consumers decided that 1-2ms of jitter was acceptable. (shrug). hardware timestamping during record is the only way around XP and OSX limitations IMHO. Playback is another story, pretty difficult for external midi, but Sonar should absolutely be able to make sure that playback to softsynths during mixdown and freezing is 100% jitter free. Even playing back a project through softsynths should be jitter free as far as I'm concerned...if there are problems...then it must be related to various buffers and programming in Sonar that needs to be improved.
Since the standard Windows 'MM' MIDI driver stack doesn't use timestamps - look for MIDI interfaces that support the DirectMusic Core API (which does). Since stock USB MIDI doesn't use timestamps (and has inherent jitter of 1-2 msec in every USB interface I've seen) -- look for alternatives if you want lower jitter than that. What alternatives? PCI-based interfaces (EMU still makes them, cunningly disguised as an EMU 1616M and the like). Non-stock USB interfaces (i.e. the MOTU interfaces that use their own proprietary MIDI timestamping protocol). Firewire interfaces (The Firewire MIDI spec doesn't timestamp, but does support accuracy down to 1/3 millisecond).
Yea. I have to say though, I have MOTU traveler and the midi is VERY latent compared to my MOTU parallel port interface. Probably not the fault of firewire, it probably has timestamping though.
It would be a big help if Cakewalk would test Sonar's MIDI timing performance with different MIDI interfaces, and post the results. Now, that might tick off some of the MIDI interface vendors - but it would certainly be a service to Sonar users.
Yea, that would be nice.
In reference to your remark on Firewire/1394, as Jim has already mentioned, the 1394 protocol does not timestamp, however, it is an isochronous protocol which means the timing of packets is guaranteed, but delivery of every packet is not, so Firewire/1394 alone has no built-in fault tolerance--packets can be dropped without notification and the system will not resend lost packets, as in certain synchronous datacomm protocols. Firewire/1394 packets come at regular intervals which makes it an ideal protocol for sending time-critical data. The Firewire 800 / 1394b spec claims a max jitter rate of 1/3 ms, which should satisfy the most exacting of MIDI requirements. Now, if our CPU can't get back to the Firewire/1394 driver in time to empty the input buffer, or gets preempted before it can refill Sonar's input buffer, we can hardly blame Firewire nor Sonar, but that's another issue.
|
Jim Wright
Max Output Level: -66 dBFS
- Total Posts : 1218
- Joined: 2004/01/15 15:30:34
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 13:37:38
(permalink)
ORIGINAL: pianodano
Jim,
Any thoughts on midisport 8x8's ? They're USB.
Danny
Danny, When I last looked (years back), MIDISports used the stock USB MIDI driver stack. They did not have any of the special driver tweaks that Edirol included in drivers for the UM-550 and similar vintage gear. So -- years back -- I would have assumed that MIDISports would have pretty mediocre timing performance. These days? I'm not sure what, if anything M-Audio has done to improve their drivers, or if M-Audio has possibly benefited from general improvements to the Windows XP USB MIDI driver stack. They might be ok now; I can't say. I do know that I'd try a MOTU product first (if the latency was ok; see dewdman42's post about latency with his MIDI Traveller) -- and then maybe an Edirol UM-880. You might have wondered about the 'special Edirol driver tweaks' I mentioned. Roland/Edirol have long had a special relationship with Microsoft; Roland/Edirol and Microsoft basically cooked up USB MIDI together (other companies got involved very late in the game). To their credit, Edirol got very concerned after I presented hard evidence about timing problems with USB MIDI -- and their subsequent products have been reviewed (by Martin Walker) as having better performance. The best 8-port MIDI interface I ever personally tested - was an 8-Port SE, made by Music Quest. It connected via parallel port, and had great latency and jitter. This was designed for Win98, but the earthvegaconnection guy developed a replacement Windows XP driver for it. So, if you can find one -- you could use it, in XP, with the replacement driver. See http://8portse.earthvegaconnection.com/index.html
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 13:48:23
(permalink)
Jim, that is good to know about the Edirol tweaks. As you say, we have no way to know what other USB midi interfaces have also done such tweaks to their USB drivers...INCLUDING, we don't know if the same tweaks have gone into the Microsoft USB driver.
I used to have an 8 Port SE and can you believe I sold it at some point at a pawn shop a long time ago for almost nothing because I thought it was outdated technology...ha ha. That earthvegaconnection guy provides DirectMusic based timing too it looks like...I think that depends on Sonar supporting it though, not sure.
One clarification, the MOTU traveler uses a single firewire connection to handle all audio and midi. I did feel the latency was poor. Could have been the audio as much as the midi. I am using a MOTU2408mk3 now which seems less latency because I can get away with lower buffer settings, I gain a few milliesconds that way. I never trusted the midi on that thing though. Now I am using MOTU MidiTimepiece(parallel) and it works great....I would have to measure to find out if there are timing issues. Feels solid.
|
Jim Wright
Max Output Level: -66 dBFS
- Total Posts : 1218
- Joined: 2004/01/15 15:30:34
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 13:52:29
(permalink)
Original: kwgm
... as Jim has already mentioned, the 1394 (Firewire) protocol does not timestamp, however, it is an isochronous protocol which means the timing of packets is guaranteed, but delivery of every packet is not, so Firewire/1394 alone has no built-in fault tolerance--packets can be dropped without notification and the system will not resend lost packets, as in certain synchronous datacomm protocols. Firewire/1394 packets come at regular intervals which makes it an ideal protocol for sending time-critical data. The Firewire 800 / 1394b spec claims a max jitter rate of 1/3 ms, which should satisfy the most exacting of MIDI requirements. This is all true. It's worth noting -- that MIDI-DIN is also not fault-tolerant; if the cable is pulled out, MIDI events are just lost (never resent). Further, audio packets are sent by the same isochronous transport - and the ear is hugely sensitive to even brief dropouts in audio (Glitch city!). Therefore, Firewire / 1394 has been engineered to provide extremely low packet-loss rates, and in practice I am not worried at all that MIDI data will be lost because it's sent using a non-fault-tolerant protocol. Now, if our CPU can't get back to the Firewire/1394 driver in time to empty the input buffer, or gets preempted before it can refill Sonar's input buffer, we can hardly blame Firewire nor Sonar, but that's another issue. Yup. The only solutions for this are to either increase the buffer size (which increases latency) or to rework the driver and/or application architecture for faster turnaround, so that buffers don't overflow/underflow (which can be tricky, and may well require kernel-level magic, depending on how cooperative the OS is towards low-latency processing). - Jim
|
pianodano
Max Output Level: -67 dBFS
- Total Posts : 1160
- Joined: 2004/01/11 18:54:38
- Location: Va Beach Virginia
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 14:01:27
(permalink)
Jim,
Thanks for the valuable info. And also thanks RTGraham and Dewdman42. Everyone else also.
I will try what you have suggested when bouncing Realguitar tracks. I have, the last year or so, been recording them to tape but that kind of defeats the purpose of midi. I was originally freezing to free up proscessing of course and could always revert.
It sure seems to be some extremely knowledgeable guys involved in this thread. Lets' hope something good comes of it.
Best, Danny Core I7, win XP pro, 3 gig ram, 3 drives- Lynx Aurora firewire- Roll around 27 inch monitor, 42 inch console monitor- Motif xs controller - Networked P4's and FX Teleport for samples- Muse Receptor VIA Uniwire for samples and plugs- UAD QUAD Neve - UAD 1- Sonar X1 but favor 8.5 GUI - Toft ATB 32 - Vintage hardware - Tascam MS-16 synched via Timeline Microlynx -Toft ATB32 console
|
Jim Wright
Max Output Level: -66 dBFS
- Total Posts : 1218
- Joined: 2004/01/15 15:30:34
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 14:12:12
(permalink)
dewdman42 - the earthvegaconnection guy also states that DirectMusic doesn't handle usually sysex correctly. He's got some evidence for the claim -- see http://earthvegaconnection.com/evc/products/miditest/index.html#sysex and various links he cites. The DirectMusic/WinXP driver for the 8-PortSE apparently avoids these sysex problems.... - Jim
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 14:30:32
(permalink)
Yea. It also looks to me that Sonar may not be taking advantage of the DirectMusic driver in any case...so it may be a moot point for us. He infers that only cubase users are using DirectMusic drivers and everyone else is just using the MM timer. I actually had a few email back and forths with that guy a few years ago when I was researching midi programming and timers. Nice guy. I don't remember much about our discussion other than that I wished I had kept my 8PortSE. ha ha.
|
Jim Wright
Max Output Level: -66 dBFS
- Total Posts : 1218
- Joined: 2004/01/15 15:30:34
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 15:53:09
(permalink)
I've wondered about Sonar and DirectMusic drivers myself .... could never find any info on the Sonar site. It may be possible to a) query Windows to get a list of the currently-available MIDI drivers and then b) see how that list compares with the list of drivers Sonar reports. If Sonar omits the DirectMusic ports - it should be pretty obvious. There's actually a standard Java library that should provide the necessary hooks (6 years ago I would have used C++, but these days I'm strictly a Java guy, so using Java is easier than installing the C++ toolset on my current machines...) So, what have you done with MIDI programming and timers? - Jim Edit. Heh. I just looked in a box in my office - there's an old 8PortSE there (long story). Guess maybe it's time to drag it out and dust it off.....
post edited by Jim Wright - 2007/10/09 16:04:02
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 16:10:20
(permalink)
I never got around to coding much of anything, but its in the back of my mind. Always a conflict of time between writing software and writing music. Music always wins. I'd had some ideas floating around in my head for an ultimate sequencer/compositional/notational program, but the amount of work that would be required to do it would be astronomical...so basically....just haven't really gotten started. One thing I want to do that won't take much time, but I promised to do it, just haven't gotten around to it...is to port the TSE3 library to windows, including both a MM timer and DirectMusic timer version. Check it out if you're curious: http://tse3.sourceforge.net/ Right now I'm also trying to find out if there are any old DOS based sequencers or something like that I can run on an INTEL box and get closer to hardware quality midi timing. The Atari's were always rumored to be solid this way, but I don't know if there have been any tests. Atari's are hard to find. There is an Atari Emulator now, called STEEM, that runs on windows..and you can run all those old Atari midi programs now, apparantly a lot of them are being re-released because of STEEM. But I reckon the midi timing under STEEM would be the same or worse than windows. Supposedly it can also run on top of linux though, so I am curious about that. Otherwise, last night I resarched a bit more. Found a few hardware sequencers that might occasionally come up on Ebay. They are all about $500 or so for the ones with 480ppq. The older ones that are 96ppq tend to go for $100-150. Some of the newer Roland Grooveboxes look interesting, for 500 bucks used you get sample handling and synth features, etc.....but mainly.....a hardware sequencer. THe Akai MPC-4000plus sounds to be the one to get, but they are in the $1500 range for a used one. I'm also curious if anyone can compare their midi timing jitter experience on say Reason or Guru (on Windows) compared to Sonar's. Or maybe some other oddball windows sequencers like SweetSixteen(which started out on Atari actually).
|
dstrenz
Max Output Level: -69 dBFS
- Total Posts : 1067
- Joined: 2005/12/10 09:59:06
- Location: Rochester, NY
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 18:32:59
(permalink)
I may be going insane.  In Sonar 7 in Options|Project, would someone try changing the clock to internal, hitting OK, then reopening that dialog to see if it took? I tried it 3 times and the first 2 times didn't stick, 3rd time did. Same with changing the timecode format.
|
pianodano
Max Output Level: -67 dBFS
- Total Posts : 1160
- Joined: 2004/01/11 18:54:38
- Location: Va Beach Virginia
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 18:47:02
(permalink)
ORIGINAL: dewdman42
Right now I'm also trying to find out if there are any old DOS based sequencers or something like that I can run on an INTEL box and get closer to hardware quality midi timing. The Atari's were always rumored to be solid this way, but I don't know if there have been any tests. Atari's are hard to find. There is an Atari Emulator now, called STEEM, that runs on windows..and you can run all those old Atari midi programs now, apparantly a lot of them are being re-released because of STEEM. But I reckon the midi timing under STEEM would be the same or worse than windows. Supposedly it can also run on top of linux though, so I am curious about that.
I find that interesting. I have a Motif XS, Yamaha Tyros and Korg PA80. All 3 all have on board sequencers. Many times I have started a song outline on those seqencers because it's so easy to do and transfered to Sonar via sneakernet as a smf. I have found that as hardware based seq/instruments they simply faithfully record and play back what was originally played. But the 1st major problem in staying with the keyboard seq'er then becomes editing klinkers and such which could not be made any more convoluted imo. Additionally I have midied up electronic drums to the Tyros sequencer and it worked great also - So I think you guys are really on the right track with your theory as far as it perhaps being a windows problem. Sonar is my only venture into a PC daw. As I mentioned previously, the old C64 didn't have these problems (that I ever noticed anyway) nor did the Roland MC500MII hardware sequencer. I missed out on the Atari my going straight to dedicated hardware. Thinking maybe I was asking to much of my music computer, a couple years back I bought a Muse Receptor so I could offload some of my softsynths. Problem with that is Muse says it runs all VSTI's but it really doesn't because it runs on linux and Muse has to port over whatever instruments folks ask for. I've been waiting these last couple years on getting Realguitar to run on it buy afaik it's not done yet. Sheesh.
post edited by pianodano - 2007/10/09 19:01:26
Best, Danny Core I7, win XP pro, 3 gig ram, 3 drives- Lynx Aurora firewire- Roll around 27 inch monitor, 42 inch console monitor- Motif xs controller - Networked P4's and FX Teleport for samples- Muse Receptor VIA Uniwire for samples and plugs- UAD QUAD Neve - UAD 1- Sonar X1 but favor 8.5 GUI - Toft ATB 32 - Vintage hardware - Tascam MS-16 synched via Timeline Microlynx -Toft ATB32 console
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 18:53:46
(permalink)
Pianodano...try setting the midi resolution in Sonar to 96ppq and see what kind of results you get. You might be surprised.
|
pianodano
Max Output Level: -67 dBFS
- Total Posts : 1160
- Joined: 2004/01/11 18:54:38
- Location: Va Beach Virginia
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 18:58:16
(permalink)
ORIGINAL: dewdman42
Pianodano...try setting the midi resolution in Sonar to 96ppq and see what kind of results you get. You might be surprised.
I will and see what happens. Sorry for my spelling in my last post. 
Best, Danny Core I7, win XP pro, 3 gig ram, 3 drives- Lynx Aurora firewire- Roll around 27 inch monitor, 42 inch console monitor- Motif xs controller - Networked P4's and FX Teleport for samples- Muse Receptor VIA Uniwire for samples and plugs- UAD QUAD Neve - UAD 1- Sonar X1 but favor 8.5 GUI - Toft ATB 32 - Vintage hardware - Tascam MS-16 synched via Timeline Microlynx -Toft ATB32 console
|
dstrenz
Max Output Level: -69 dBFS
- Total Posts : 1067
- Joined: 2005/12/10 09:59:06
- Location: Rochester, NY
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/09 22:51:17
(permalink)
ORIGINAL: dewdman42
Pianodano...try setting the midi resolution in Sonar to 96ppq and see what kind of results you get. You might be surprised.
After hours of testing and trying different sync methods with the Fantom, the largest wav offset between the originally recorded wav and a wav recorded into Sonar playing midi from the Fantom sequencer was 112 samples (2.53ms) with Sonar set to 480ppq. Repeating with Sonar set to 96ppq and that went down to about 20 samples (.452ms)! I'm beat. Will try to do more testing tomorrow.. maybe I'll print the wav on the Fantom and see how that compares to the one recorded in Sonar..
|
Nick P
Max Output Level: -44 dBFS
- Total Posts : 3112
- Joined: 2006/09/01 18:08:09
- Location: Area code 392 - Arlington Hts, IL
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/10 06:31:07
(permalink)
So contrary to what seems logical, in fact it seems that lowering the clock resolution actually improves MIDI accuracy. Weird.
Also, although I haven't thoroughly read each reply, I will comment that whatever the issues with the OS and drivers, it appears that from a practical/pragmatic viewpoint, Ableton has both recognized the issue of MIDI jitter, and done something about it with the latest version of Live, unless it's just marketing hype.
I would love to see some MIDI sequences recorded in non-quantized mode to both Live 6 and Live 7 and compare the results, both with the ear, and looking at where the waves hit graphically.
Cakewalk Forums - A Great Learning Resource For All Things Cakewalk!
|
dstrenz
Max Output Level: -69 dBFS
- Total Posts : 1067
- Joined: 2005/12/10 09:59:06
- Location: Rochester, NY
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/10 08:15:14
(permalink)
ORIGINAL: Nick P
So contrary to what seems logical, in fact it seems that lowering the clock resolution actually improves MIDI accuracy. Weird.
Yes, but bear in mind that the test was with just 8th notes. Don't know what will happen with 64th notes yet, or adding pitch bend and modulation controller events. Also, I should note that all this was done using the Fantom's USB midi driver and I should probably retest using the emu 1820m midi ports.
|
pianodano
Max Output Level: -67 dBFS
- Total Posts : 1160
- Joined: 2004/01/11 18:54:38
- Location: Va Beach Virginia
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/10 08:26:33
(permalink)
ORIGINAL: Nick P
So contrary to what seems logical, in fact it seems that lowering the clock resolution actually improves MIDI accuracy. Weird.
Maybe I'm missing something here but that's exactly what I think should happen if you are aiming for say... the exact beat. But I don't think improved acurracy is the correct term if you're intentionally playing behind the beat and want exactly what was played captured. It stands to reason, ALL midi is quantized to one tick or another. More ticks should equal capturing with higher accuracy the original performance. Whether the orginal performance was accurate or not is another matter entirely and, in my mind, a poorly timed performance is what quantization is used for, traditionally. Danny EDIT: Without opening up a giant can of worms (I hope), I have suspected for sometime now that this very issue is why many have requested INPUT quantization. Many users knew/know something is wrong but they just assume it is not the DAW. So in their minds they must not be a accuarate as they think they are and need some help. On and on it goes. I do know that if you set down at a Yamaha disklavier and enable record, you will be blown away by just how good midi can made to work.
post edited by pianodano - 2007/10/10 08:50:11
Best, Danny Core I7, win XP pro, 3 gig ram, 3 drives- Lynx Aurora firewire- Roll around 27 inch monitor, 42 inch console monitor- Motif xs controller - Networked P4's and FX Teleport for samples- Muse Receptor VIA Uniwire for samples and plugs- UAD QUAD Neve - UAD 1- Sonar X1 but favor 8.5 GUI - Toft ATB 32 - Vintage hardware - Tascam MS-16 synched via Timeline Microlynx -Toft ATB32 console
|