Suggestion for CWA: Improving midi and drivers
With all the recent talk of midi issues I'd like to mention this again now that CWA Frank and other members are actively listening:
Currently midi timing isn't bad, but it's not great either. All of the users tests are showing that it could be improved. Since the bulk of midi data is coming from host sequencers, is it possible to implement a protocol such as Rewire for sample accurate timing? All of the major PC sequencers (Calkwalk, Nuendo, Cubase, Ableton, etc) already support this.
Can Creamware implement this?
Keep the midi as it is and improve it if possible, but include the ability to use Rewire for midi.
Is this possible?
Thanks
Currently midi timing isn't bad, but it's not great either. All of the users tests are showing that it could be improved. Since the bulk of midi data is coming from host sequencers, is it possible to implement a protocol such as Rewire for sample accurate timing? All of the major PC sequencers (Calkwalk, Nuendo, Cubase, Ableton, etc) already support this.
Can Creamware implement this?
Keep the midi as it is and improve it if possible, but include the ability to use Rewire for midi.
Is this possible?
Thanks
I never read the midi specs in depth, but afaik a simple midi through (by 'regular' hardware) introduces about 5 ms delay.
We're probably talking way beyond the specs here.
Midi isn't sample accurate by definition, so every supplier like Motu, Steinberg, Emagic etc implements their own extensions (and workarounds) to approach that accuracy.
Add the fact that a regular OS isn't realtime either, you can only guarantee a certain degree of accuracy within a restricted environement, as the result from the various tests show.
Btw I once read that the sequencer's metromomes are anything but precise, (can't remember where) it was mentioned in a context where someone was looking for a reliable 'timing source'
cheers, Tom
We're probably talking way beyond the specs here.
Midi isn't sample accurate by definition, so every supplier like Motu, Steinberg, Emagic etc implements their own extensions (and workarounds) to approach that accuracy.
Add the fact that a regular OS isn't realtime either, you can only guarantee a certain degree of accuracy within a restricted environement, as the result from the various tests show.
Btw I once read that the sequencer's metromomes are anything but precise, (can't remember where) it was mentioned in a context where someone was looking for a reliable 'timing source'
cheers, Tom
-
- Posts: 627
- Joined: Fri Aug 15, 2003 4:00 pm
It would be nice if CW could figure out a way to make SFP and XTC some how relate to each other, thus giving any CW modules sample accuracy such as a VSTi has.
I know nothing of progrqaming, but I am guessing the reason it cant be done for the CW cards is due to the fact that DSP cards intruduce additional latencies?
Luckily for myself its not something I worry about with full PDC, though I have never tested XTC mode in say SX where there is zero compensation..
Does XTC mode even offer delay compensator plugs for group channels? Im at work so I cant look
Cheers!
I know nothing of progrqaming, but I am guessing the reason it cant be done for the CW cards is due to the fact that DSP cards intruduce additional latencies?
Luckily for myself its not something I worry about with full PDC, though I have never tested XTC mode in say SX where there is zero compensation..
Does XTC mode even offer delay compensator plugs for group channels? Im at work so I cant look

Cheers!
I'm almost certain that SFP in itself is sample accurat, given you use devices that take care of this aspect.
Some older ones obviously do not, but since it has been adressed by Adern (afaik they were the first to mention this to a broad public) everyone is aware of the facts.
VDAT (which I don't have) has frequently been notes as to deliver excellent (probably even the best) results when it comes to recording SFP stuff.
But as soon as you're depending of another apps internal clock and the OS has no appropriate means to publish that clock signal with top priority (or provide a reliable 'super-clock' for all apps), trouble is unavoidable.
At least in the precision range you prefer to work in
cheers, Tom
Some older ones obviously do not, but since it has been adressed by Adern (afaik they were the first to mention this to a broad public) everyone is aware of the facts.
VDAT (which I don't have) has frequently been notes as to deliver excellent (probably even the best) results when it comes to recording SFP stuff.
But as soon as you're depending of another apps internal clock and the OS has no appropriate means to publish that clock signal with top priority (or provide a reliable 'super-clock' for all apps), trouble is unavoidable.
At least in the precision range you prefer to work in

cheers, Tom
I think it would be a good idea to come up with a standard test, which would be possible to perform with any sequencer/host.
I think the sequencer plays a BIG role in quality of MIDI timing, and MIDI-Audio sync.. I use Logic and I've never had to question the timing I get, which is rock solid to my ears.
I think the sequencer plays a BIG role in quality of MIDI timing, and MIDI-Audio sync.. I use Logic and I've never had to question the timing I get, which is rock solid to my ears.
Neutron has suggested a couple of times to run a 1/64 steps sequence to a (dsp) hihat, and raise the sequencer's BPM untill irregularities in the stream appear...
Logic's engine optimizes midi transmission so certain data (notes etc) are given priority. Again, a flaw in the midi spec is that it doesn't itself specify what data can be given priority.
I know that Cubase has always been less adept at doing this (although they claim improvements when using 'their' midi interfaces as most sequencer makers do) but there is another way to optimize midi transmission a bit to SFP.
Use more midi source & dest pairs.
My typical project starts with 5 midi source & dest pairs. In use more sources wind up connected than destinations, but i try to keep them together for simplicity. Mmy maximum 'available' set in the windows driver's properties is 8.
Some OS versions are more limited Xp seems fine for me (I also have an 8-port midi interface).
I know that Cubase has always been less adept at doing this (although they claim improvements when using 'their' midi interfaces as most sequencer makers do) but there is another way to optimize midi transmission a bit to SFP.
Use more midi source & dest pairs.
My typical project starts with 5 midi source & dest pairs. In use more sources wind up connected than destinations, but i try to keep them together for simplicity. Mmy maximum 'available' set in the windows driver's properties is 8.
Some OS versions are more limited Xp seems fine for me (I also have an 8-port midi interface).
more exactly, make a sequence of exact the same note on every step, i use a hihat because it has a sharp attack, but you could use single shot of a waveform or whatever you want. as long as the sample has a fast attack or you will not hear anything as you speed it up.On 2004-03-09 09:16, at0mic wrote:
Neutron has suggested a couple of times to run a 1/64 steps sequence to a (dsp) hihat, and raise the sequencer's BPM untill irregularities in the stream appear...
just to test your system/sequencer play that sequence, looping and speed the tempo up gradually. if you get a steady pitched note then you are golden, if you start to notice irregularities before it even becomes a pitched note then you have possible problem.
eventually you will break the maximum bitrate of the MIDI spec which is quite low
and the test will become useless, but within the computer (no ext device being triggered)
that bitrate is not really applicable. - I also used this test for my Yam FS1R which works very accurately considering slow MIDI cables/interface)
for the longest time i was sure it was creamware issue, but found out it could be fixed.
the biggest cause of these problems i have ever found are MIDI routers for windows (hubis? loop-back device, and there was a similar thing for NT based windows 2000, xp etc) anyways i do not use them any more becaue i have never found a good one. I run soft synths on a different computer than creamware/sequencer now.
there is a software thing you can get that
sends MIDI over network connection, it also cause this problem as well but to a much lesser amount for me.
you may get a small glitch on the loop returning to the start, its just the sequencers problem then.
this is not such a big problem for me but could be if you do the "live recording to a loop" type thing. on the programs i have used for this test (cubase and logic) i have noticed the glitch is worse if you return to 0.0.0.0 than looping somewhere else.
when i started doing this test was when i changed from 98 to ME and the problem remained, it was solely due to the midi router program (hubis looback). also I noticed ME was much smoother than 98 (without loopback)
when i changed to XP i tried it again, it was not as good as ME (not surprising due to HAL of XP) but still much better than 98 and very acceptable. I had a much faster computer by then so that could figure into the mix.
You can also use this test to check if MIDI in your PC is being affected by other CPU usage.
do the same thing, and grab your most monstrous CPU hog soft-synth. play huge chords on it with its sound turned off or down while the test is going and see if the "pulses" vary. this is something where hyperthreading really shines.
2.4 ghz p4 "a" without hyperthreading (overclocked 1.6) when you play big chord on absynth then you hear a slowdown, which is more on the attack of the chords.*
2.4 ghz p4 "c" with hyperthreading
you cant alter the steady sound of the test even if you mash your hands on the keyboard to get as many notes as possible.*
*only my experience of course.
if you trigger your creamware synths from an external sequencer you can also try this test and u will find it is good. (well i do anyways)
<font size=-1>[ This Message was edited by: Neutron on 2004-03-20 23:40 ]</font>
- kensuguro
- Posts: 4434
- Joined: Sun Jul 08, 2001 4:00 pm
- Location: BPM 60 to somewhere around 150
- Contact:
reliable timing source.. I still think syncronizing using audio clicks is as accurate as you can get. Not sure how that'll translate to MIDI, but audio clicks are rock solid. Your 1000hz saw wave doesn't wiggle around. Max/msp's metronome isn't accurate, so this is a standard workaround. Seems no major sequencer software does this tho.
<font size=-1>[ This Message was edited by: kensuguro on 2004-03-20 23:47 ]</font>
<font size=-1>[ This Message was edited by: kensuguro on 2004-03-20 23:47 ]</font>
if it is about midi clock accuracy in SFP, I have an ultra stable external midi clock when I use the one from dd55 directly plugged into scope Midi In (dd55 is a toy electronic drum pads) . Everything works fine in that case.
It is not good with cubase for ex.
For me it means that it has nothing to do with SFP but rather with the clock generator itself.
But I have been told it is cubase, and that it could be much better with Logic or Live (someone will confirm, as I do not know those apps).
In any case, an external clock will not provide a start message (start phase) and I think midi note trigger is the way to go, eventhough it takes a few minutes more to setup, but that's the way you should go forfreeing yourself from SequencerStart slavery (8-) (sure ,it depends what you want your clock for, what latency you use etc ...)
<font size=-1>[ This Message was edited by: spacef on 2004-03-21 09:12 ]</font>
It is not good with cubase for ex.
For me it means that it has nothing to do with SFP but rather with the clock generator itself.
But I have been told it is cubase, and that it could be much better with Logic or Live (someone will confirm, as I do not know those apps).
In any case, an external clock will not provide a start message (start phase) and I think midi note trigger is the way to go, eventhough it takes a few minutes more to setup, but that's the way you should go forfreeing yourself from SequencerStart slavery (8-) (sure ,it depends what you want your clock for, what latency you use etc ...)
Btw I once read that the sequencer's metromomes are anything but precise, (can't remember where) it was mentioned in a context where someone was looking for a reliable 'timing source'
cheers, Tom
<font size=-1>[ This Message was edited by: spacef on 2004-03-21 09:12 ]</font>
There was another thread somewhere here on PlanetZ where Steinberg users were complaining about the horrible midi performance they were experiencing with SFP and pointing fingers at Creamware.
I conducted the following test (also posted there but I'm posting here since I don't feel like using the search feature atm):
http://www.kief.net/studio/tests/MidiTi ... gic-pc.htm
Logic is definately fine for midi timing to SFP, although I'd prefer to have something for external midi other than my Midisport
I conducted the following test (also posted there but I'm posting here since I don't feel like using the search feature atm):
http://www.kief.net/studio/tests/MidiTi ... gic-pc.htm
Logic is definately fine for midi timing to SFP, although I'd prefer to have something for external midi other than my Midisport

- BingoTheClowno
- Posts: 1722
- Joined: Wed Nov 12, 2003 4:00 pm
- Location: Chicago
- Contact:
I use a Peavey 1600X MIDI controller that has the ability to acctually introduce delays either after each MIDI byte or after each MIDI message. My Pulsar 2 card used to crash predictably when used with my Yamaha keyboard but now after introducing a 5ms delay after each byte through the Peavey's controller, the system never crashes.
I have not tested what was the smallest latency I could use, I was just happy it wasn't crashing.
<font size=-1>[ This Message was edited by: BingoTheClowno on 2004-03-22 12:17 ]</font>
<font size=-1>[ This Message was edited by: BingoTheClowno on 2004-03-22 12:19 ]</font>
I have not tested what was the smallest latency I could use, I was just happy it wasn't crashing.
<font size=-1>[ This Message was edited by: BingoTheClowno on 2004-03-22 12:17 ]</font>
<font size=-1>[ This Message was edited by: BingoTheClowno on 2004-03-22 12:19 ]</font>
Well unfortunately it puts the blame back on the maker of your choice in sequencer. I do know that Cubase SX uses Microsoft's Directmusic (DirectMIDI) for all midi ports and this is ALSO the cause of the [emulated] ports showing up as standard. What this means is that Cubase SX users with problems now have to look towards not just Steinberg, but also Microsoft and their particular hardware setup. Fun fun...
For my 2 cents I think its worthwhile to try an alternative software when you're having problems, even if its just a demo from another competing company.
For my 2 cents I think its worthwhile to try an alternative software when you're having problems, even if its just a demo from another competing company.
Hi
I now get similar results with SX2. I replaced my Midisport with a Midex8, tweaked a few things and now my external equipment is rock solid as well. Although I did notice that my Nova only had a couple of samples of jitter, my Vintage Keys was about the same as SFP, 10-15 samples of jitter. VSTIs appear to be sample accurate.
I am really happy with the timing of SX2.
Regards
Kenf
I now get similar results with SX2. I replaced my Midisport with a Midex8, tweaked a few things and now my external equipment is rock solid as well. Although I did notice that my Nova only had a couple of samples of jitter, my Vintage Keys was about the same as SFP, 10-15 samples of jitter. VSTIs appear to be sample accurate.
I am really happy with the timing of SX2.
Regards
Kenf
It's too bad that there isn't a universal MIDI time stamping format. All of the DAW developers figure they can slack on MIDI communication w/ 3rd party products & make it really good for their interfaces. I believe MOTU created the technology & I've heard theirs is the most accurate. Any DP users w/ a midi time piece?On 2004-03-23 04:46, valis wrote:
Yes, that's one of the unfortunate aspects of modern sequencers...they work best with hardware from their own manufacturers.
-
- Posts: 1454
- Joined: Tue Dec 11, 2001 4:00 pm
- Location: California
- Contact:
I don't know about the rest of you, but all my MIDI interfaces going to everything works just fine with Sonar -- I'm not having any timing problems. And Pulsar works just as well as anything else. What's the big deal?
Shayne
_________________
Discover Human Music by Shayne White at: http://www.shaynesworld.com
<font size=-1>[ This Message was edited by: Shayne White on 2004-03-24 18:19 ]</font>
Shayne
_________________
Discover Human Music by Shayne White at: http://www.shaynesworld.com
<font size=-1>[ This Message was edited by: Shayne White on 2004-03-24 18:19 ]</font>
Scope+SX 1.6 here, hyper stable and accurate audio recording (i only have audio-card latency, but no jitter). I mean, if I record a "kick me" audio track, i just have to move it a few samples (card latency+1 sample) and the whole track is now in perfect sample synch). I haven't tried with a different midi interface than scope though.
Digital Performer and Motu : yes the problem I experienced were possibly due to the Motu interface (crazy midi jitter, for everything, including VSTis which do Not use the MOTU interface for midi transmission), and the bug, which existed for a loooong time, was corrected in the latest DP version (4.12?) I haven't checked myself, but I have been told it was fine now. I do not know if it is the most accurate sequencer... but i like it very much.
USB : yes i think usb info easily interfere with each others, may be that cause some delay in transmission of info. There was an article from RME website about USB1 and how it can be bad for audio (due to the quality of some controllers mainly).
<font size=-1>[ This Message was edited by: spacef on 2004-03-28 14:44 ]</font>
Digital Performer and Motu : yes the problem I experienced were possibly due to the Motu interface (crazy midi jitter, for everything, including VSTis which do Not use the MOTU interface for midi transmission), and the bug, which existed for a loooong time, was corrected in the latest DP version (4.12?) I haven't checked myself, but I have been told it was fine now. I do not know if it is the most accurate sequencer... but i like it very much.
USB : yes i think usb info easily interfere with each others, may be that cause some delay in transmission of info. There was an article from RME website about USB1 and how it can be bad for audio (due to the quality of some controllers mainly).
<font size=-1>[ This Message was edited by: spacef on 2004-03-28 14:44 ]</font>