Quote Chris Edwards:

---

Quote desmond:

---

This is how AMT is implemented:

---

Good find. Presumably, that's from OS9 days, when much fuss was made.

---

Yep. That was from Emagic.de around 2002, as part of the product info for the AMT8. I tried to find the article talking about AMT in respect to OSX without success - I suspect it was an emagic techweb article, and is thus no longer available.

Quote Chris Edwards:

---

- OSX Core MIDI natively incorporates midi timestamps

- The USB-midi spec does not. Hence timestamps can't reach an interface using generic "class" driver.

- Some interfaces support timestamps (in hardware) and come with a custom driver such that OSX can take advantage. The protocol over the USB link is (due to prev point above) proprietary in nature.

- Timestamping can apply to midi input when recording, as well as midi output when playing back.

- For output, the key property, as supported by certain hardware, is known as schedule-ahead

- Haven't found a list of what hardware supports this AND has suitable drivers.

- Looks like some MOTU 8 port interfaces may do.

- There's an edirol interface with a physical switch on the back to choose between standard USB midi "class" operation (no need to install driver), or, using a proprietary driver, which offers some advantages (timestamping?).

---

Great stuff. So, it's not all MIDI hardware than can take advantage of time stamps, a device/driver has to specifically support this feature of Core MIDI - as you suspected. Cool.

I'm pretty sure the Unitor/AMT drivers support this feature, in conjunction with the interface's own engines, especially based on what my memory says emagic said of this in the past - like I say, it's not exactly the same implementation as AMT, but should offer a similar performance.

As to the rest, short of the ones mentioned in the posts you cite, it's a bit of a guessing game. It might make sense, when considering purchasing a MIDI interface, to check out their manuals beforehand, and/or drop an email to the manufacturer explictly asking whether time stamping is supported under OSX, in order to benefit from the best possible MIDI timing performance.

Just to let you all know I have logged back in and read all your responses since last posting.

Thanks for all your input.

Been testing Logic over the past few days and have seen with even the smallest buffer size, there is still major timing differences. And you cant delay compensate for it, because the delay is not consistent.
Do these same midi timing errors happen in Ableton Live?

Quote desmond:

---

Quote Chris Edwards:

---

- OSX Core MIDI natively incorporates midi timestamps

- The USB-midi spec does not. Hence timestamps can't reach an interface using generic "class" driver.

- Some interfaces support timestamps (in hardware) and come with a custom driver such that OSX can take advantage. The protocol over the USB link is (due to prev point above) proprietary in nature.

- Timestamping can apply to midi input when recording, as well as midi output when playing back.

- For output, the key property, as supported by certain hardware, is known as schedule-ahead

- Haven't found a list of what hardware supports this AND has suitable drivers.

- Looks like some MOTU 8 port interfaces may do.

- There's an edirol interface with a physical switch on the back to choose between standard USB midi "class" operation (no need to install driver), or, using a proprietary driver, which offers some advantages (timestamping?).

---

Great stuff. So, it's not all MIDI hardware than can take advantage of time stamps, a device/driver has to specifically support this feature of Core MIDI - as you suspected. Cool.

I'm pretty sure the Unitor/AMT drivers support this feature,

---

Brining this thread back...
It's been long speculated that old Emagic Unitor8/AMT USB midi interfaces still support midi timestamping. This is where midi data is sent from the host software in packets to the USB interface, and there it is buffered and sent to all the multiple midi out ports simultaneously. Under Mac OS9, this technology was known as AMT (active midi transmission) and was an Emagic protocol. They developed the Emagic Unitor8 and AMT8 interfaces to support this protocol, and it worked really well...... very well infact!!
However when OSX came out, Emagic Logic dropped support of AMT as time stamping was native within OSX. And so many people guessed that their old Emagic units still supported a version of the old AMT, now known as OSX midi time stamping.

However MTS under OSX will only work if BOTH the software and hardware support it....

Now then, as the Emagic Unitor 8 and AMT8 both come out BEFORE OSX , how could they support a feature native to OSX? Remember they do support AMT, but not MTS. Even though they give similar results, they are two different protocols.
From various sources i've learned that even if the host software supports OSX timestamping, if the interface does not, then you have no benefit from the timing improvements...

I ran a brief test to investigate. I loaded 5 midi tracks in Logic, sending to 5 ports on my Unitor8 Mk2 and 5 midi synths. I then recorded the synths outputs as audio, and checked the sample editor for timing jitter etc.
The synth on port 5 was around 6-8 ms off the grid.
I then soloed midi tracks 1 to 4, and recorded synth 5 to audio. Checking its recorded audio, it was now more or less bang on the grid. I repeated the test with 5 tracks going, and once again the synth on port 5 was late. Infact the other synths timing would cascade as you went along from midi ports 1 to 5.

This proves that old Emagic USB interfaces do not support time stamping under OSX. If they did, then the timing of the synth on port 5 would not increase as more tracks are added.

Not all USB midi interfaces support midi time stamping.
From what i understand the only multi port USB interfaces to support midi time stamping under OSX are the Motu ones. They even have MTS labels on the front of them.

According to old Motu info "MTS uses software components in Digital Performer and firmware components in MOTU’s new MIDI Timepiece AV-USB, Express XT-USB and micro express-USB interfaces"
So OSX midi time stamping needs compatible firmware within the interface, and as Emagic USB interfaces came out before OSX and are only AMT firmware enabled, that would make it impossible for them to now be MTS compliant.
Am I correct in my assumptions? Hoping Desmond or Chris can add their thoughts on this.

Quote Jauqq:

---

So OSX midi time stamping needs compatible firmware within the interface, and as Emagic USB interfaces came out before OSX and are only AMT firmware enabled, that would make it impossible for them to now be MTS compliant.

---

Hi,

Hmm - not entirely convinced. If the info in my last 2009 post is right, then presumably what's required is an OSX driver (ie. software) able to take the OSX core midi timestamp info and send it to the old AMT hardware, over USB, in a format that hardware understands.

Interestingly/sadly, your tests suggest the current OSX driver doesn't do this

Fraid I don't have any new info, having gone "soft", at least for the moment.

PS - anyone want a couple of MIDEX 8x8 doorstops, for which there is no Intel Mac driver, let alone one doing timestamping...

Quote chris...:

---

Quote Jauqq:

---

So OSX midi time stamping needs compatible firmware within the interface, and as Emagic USB interfaces came out before OSX and are only AMT firmware enabled, that would make it impossible for them to now be MTS compliant.

---

Hi,

Hmm - not entirely convinced. If the info in my last 2009 post is right, then presumably what's required is an OSX driver (ie. software) able to take the OSX core midi timestamp info and send it to the old AMT hardware, over USB, in a format that hardware understands..

---

Hi Chris,
I beg to politely differ.... from Motu docs they clearly state that for MTS to work, both software and an MTS firmware enabled interface are needed. An Emagic unit is not MTS firmware enabled, but AMT enabled...totally different thing. If it was this simple then any USB interface could be flashed with MTS firmware to make it compliant.

Link to Motu doc:
Motu MTS doc
The relevant info is on the top of page two.

Quote Jauqq:

---

from Motu docs they clearly state that for MTS to work, both software and an MTS firmware enabled interface are needed.

---

Perhaps it's a case of "they would say that wouldn't they".

Either way, I don't see what's theoretically stopping Apple writing a driver that sends timestamps to the old AMT hardware in the way it expects.

Sounds to me simply like they couldn't be arsed.

If I was getting back into external midi, I'd almost certainly buy the MOTU interfaces.

Quote chris...:

---

Quote Jauqq:

---

from Motu docs they clearly state that for MTS to work, both software and an MTS firmware enabled interface are needed.

---

Perhaps it's a case of "they would say that wouldn't they.

Either way, I don't see what's theoretically stopping apple writing a driver that sends timestamps to the old AMT hardware in the way it expects.

Sounds to me simply like they couldn't be arsed.

If I was getting back into external midi, I'd almost certainly buy the MOTU interfaces.

---

That's what i've just gone ahead and done. Ordered a Motu 128 express from DV and will run the same test again under Logic 9. If it doesn't perform, then it's a simple return under their 30 day return policy, and i'll know MTS is Motu marketing BS.

Edited by Jauqq (10/04/11 10:45 AM)

Quote Jauqq:

---

I beg to politely differ.... from Motu docs they clearly state that for MTS to work, both software and an MTS firmware enabled interface are needed. An Emagic unit is not MTS firmware enabled, but AMT enabled...totally different thing. If it was this simple then any USB interface could be flashed with MTS firmware to make it compliant.

---

Without knowing the specifics of what's going on the driver and the interface, it's difficult to say. You are correct in that AMT was pre-OSX and works a little differently to OSX native time-stamping, and that both the driver and the hardware need to support time stamping events.

The AMT interfaces definitely support timestamping and unpacking of events, so I'm fairly sure the driver and the AMT8 can handle OSX timestamping - as I've written above, and from (my memory of) the comments from emagic themselves back in the day.

> Now then, as the Emagic Unitor 8 and AMT8 both come out BEFORE
> OSX , how could they support a feature native to OSX?

Assuming that the interface itself has to support "OSX" midi timestamping is not necessarily the case. The OSX *driver* must handle OSX's timestamping, and it must be able to send packed, timestamped events to the interface, and the interface itself must be able to unpack them and fire them off at the timestamps contained - and that's exactly what the AMT8 should be doing, as far as I'm aware.

However, I haven't run any tests (and quite frankly nor do I care that much anymore, as like many people I'm using less and less live MIDI hardware these days). It's difficult to comment too much about the accuracy of your tests, though what you say is interesting...


Edited by desmond (10/04/11 10:52 AM)

For the sake of comparison, i've just tested my aged PowerBook G4, Mac OS9, Logic Platinum 6, Unitor8 Mk2 with AMT version 2. Same as before, with 5 midi tracks loaded up with 16ths, firing out to 5 ports on the Unitor8. Track 5 recorded to audio, and checked in the sample editor.
Tested over a large number of takes, timing would vary between each one. Sometimes i'd find timing to be excellent with jitter in the range of 0.5 ms !!!! Other takes would still yield a very passable jitter amount of 1.5 to 2 ms.
Still better than the 8ms immediate latency (plus jitter) I found under OSX and L9 with a Unitor8 interface.
To compare the OS9 figures, IIRC the mighty Atari + Notator combo had jitter of around 2ms.

Edited by Jauqq (10/04/11 04:49 PM)

Interesting.

What version of the EmagicUSBdriver were you using for the OSX tests? Does using different versions make a difference?

You say you are recording the audio output of a MIDI-triggered synth - how are you factoring out it's own MIDI latency and audio latency from the test results?

Quote desmond:

---

Interesting.

What version of the EmagicUSBdriver were you using for the OSX tests? Does using different versions make a difference?

---

Im using the latest OSX 10.6.7, with Logic 9.1.3. Unitor driver is 2.5 and Coreaudio.framework is 3.2.6....i'm one of those people who updates to the latest versions. One day i'll regret it i know.....

Quote desmond:

---

You say you are recording the audio output of a MIDI-triggered synth - how are you factoring out it's own MIDI latency and audio latency from the test results?

---

I only use software monitoring through my audio interface.
The first thing I did was to set the "recording delay" value for my audio interface. This ensured that audio gets recorded at the correct point.
I then set up a midi track to trigger my midi synth. Just a simple 4 bar pattern of quarter notes, with its audio recorded to an audio track. Then i open the audio file in the sample editor, and count how many samples late the recorded synth is. Of course there'll be jitter, but it's very minimal. I had an average delay in samples of 132 samples, and at 120 bpm this is around 3.1 ms. This is the synths delay/reaction time to incoming midi data.
In the midi track, i then set the delay parameter to -3.1ms, and repeat the above. Now recorded audio from the synth lines up more or less bang on the grid. This all works fine with only one midi track going, but as more midi tracks are introduced, the timing goes off the further along the ports you go.

I have just recently been through the process of minimizing various latencies in my Logic Pro system. I have been moving back to using more of my old hardware and could no longer accept the slop I was getting without tweaking Logic preference settings.

I apologize if this comes across as spam but, I assure you, I am in no way affiliated with their service beyond being a customer. macprovideo dot com has a lengthy series of videos that go into great detail to explain causes of latency in the analog and digital domains. While the topics apply to all DAWs, they are specifically tailored to Logic and the tools Logic provides to get your tracks in sync.

Problem one, for me, was to discover that my Motu audio interface does not report the correct latency to Logic. I had to apply an audio offset to ensure that audio recording would end up in sample accurate sync with playback tracks. This is a fairly straight forward process that requires creating a track with a single sample ping then playing out of the interface while recording it back in to the various input types you will be using. You then open the recorded track in the sample editor to determine the number of samples off the newly recorded track is.

The hardware midi side is a bit of a different story. This process is alway a bit of a moving target as midi jitter varies quite a bit. The process involves determining which hardware instrument has the longest latency and then averaging out the differences between the transients of each individual piece of hardware and the most latent. You then divide that average number of samples by your projects sample rate, this gives you the track offset you need for each given instrument.

There is a bug in Logic that causes offset tracks to influence subsequent tracks in the arrange window. For me, it seems to work best to order my tracks for the lowest offset to the longest offset. This seems to negate the interaction of the offset. This bug is discussed in the videos.

Once you have all of your midi hardware hitting more or less in sync (within a ms or two is about the best you can hope for due to the serial/sloppy nature of midi), you then need to determine the global midi offset to apply in your Logic preferences. If you do not apply the global offset, then all of your midi tracks will be late.

Again, because midi is jittery, the process can be a bit frustrating. That said, it is crucial and worth while to take the time to run these tests and make a template that works for your setup. I have been able to get the majority of my midi notes to land in under 2ms of the grid markers. Most are tighter than that, some are a bit longer. The important thing is that my tracks are much tighter and I no longer feel like I am doing something wrong.

The midi timing issues are a result inherent limitations of the technologies. Logic, albeit with some bugs, provides the tools to understand and compensate for latencies to a largely satisfactory degree.

The macprovideo tutorial "Logic's Latency Toolbox" is a godsend. I have been so angry with latency issues and midi slop that I almost gave up on Logic to use an old MPC with external HardDisk recorder and then use Logic for mixing. I am much happier now and have a far greater understanding of what is happening when things sound out of sync.

Also, please do report the bugs to Apple. They do pay attention, but, the wheel has to squeak before it will be fixed. In the meantime, my tracks are in better sync than ever and I can just about call myself happy using hardware again.


-Trevor

Quote alphabyte:

---

Problem one, for me, was to discover that my Motu audio interface does not report the correct latency to Logic. I had to apply an audio offset to ensure that audio recording would end up in sample accurate sync with playback tracks. This is a fairly straight forward process that requires creating a track with a single sample ping then playing out of the interface while recording it back in to the various input types you will be using. You then open the recorded track in the sample editor to determine the number of samples off the newly recorded track is.

---

This is the "recording delay" offset I spoke of in my earlier post. It's further explained here in post number 9.
workng out your recording delay value for Logic

Appreciate you posting your method for lessening the effects of midi latency and jitter for hardware synths. It seems a bit more complex than my method, but i'll investigate your way further.

I've also learned that Logic has tighter midi sync when running at the lowest buffer setting. ie 32 samples. Any higher than that, and midi jitter increases.

Quote alphabyte:

---

The hardware midi side is a bit of a different story. This process is alway a bit of a moving target as midi jitter varies quite a bit. The process involves determining which hardware instrument has the longest latency and then averaging out the differences between the transients of each individual piece of hardware and the most latent. You then divide that average number of samples by your projects sample rate, this gives you the track offset you need for each given instrument.

---

This seems to be more or less what i'm doing. Triggering each hardware synth in turn, and recording it to audio. Then counting the samples of how late it is off the grid, and getting an average figure. So the average sample count divided by 44.1, gives you the number of ms you need to enter into the track delay parameter.

Quote alphabyte:

---

There is a bug in Logic that causes offset tracks to influence subsequent tracks in the arrange window. For me, it seems to work best to order my tracks for the lowest offset to the longest offset. This seems to negate the interaction of the offset. This bug is discussed in the videos.

---

However im doing my method for each synth in turn. So synth A has -3.1ms for its track delay, synth 2 has -2.6ms for its track delay, etc

I've never come across the mentioned bug...
I wonder if that's the cause of the increased latency as more midi tracks are played back?
In which exact video is this bug mentioned?

Quote Jauqq:

---

I've also learned that Logic has tighter midi sync when running at the lowest buffer setting. ie 32 samples. Any higher than that, and midi jitter increases.

---

Yep, this is a known issue.

The video series is "Logic 207: Logic's Latency Toolbox" and the specific chapter is "48. Bug Shop - Part 3"

This is a serious bug. When I was first running the tests to get the offsets, I was going out of my mind because tracks that were fine seemed to be staying behind the tracks I was trying to tweak. Finally, I entered a large, unreasonable offset and confirmed it was delaying the Midi, and therefor recorded audio, of tracks I had applied no delay to. It was hard to notice with small offsets because I kept blaming jitter and getting angry.

Ordering the tracks from lowest to highest offset solved the problem, but, it is kind of a limiting way to work. The videos suggest some workarounds, but, this solution works for me at the moment.

There is also a bug with the global midi offset. If you have a global offset that is not a whole number, the fractional portion is not retained. My global Midi Sync offset preference is -12.0. If you enter, say, -12.7 then go to another preference pane and return to the global midi sync offset, you will find it is -12.0. The solution is to adjust the track offsets by the fractional value appropriately.

I honestly feel these tutorials are well worth looking into. Apple should create a guided tour to walk users through this process. It is so essential if you using external gear.

Already being an existing MPV customer, i've just downloaded the Latency toolbox videos. I never knew about these before, so thanks for the heads up. Have just flicked forward to the chapter you spoke of and am sitting here gob smacked!! This could be the cause of my problems but i'll have to investigate the whole tutorial further. Although for now i'm confused as to why I found that muting higher ordered tracks will bring back the timing of lower ordered ones? Does not seem to fit in with the bug...

I've never encountered the global midi offset before, as up to now i was just offsetting individual midi tracks in ms. Still i'm confused as to why you'd need a global offset, when you have individual track offsets?

Hope the videos will make it a bit clearer.

Thanks again.

Edit: Alphabyte, out of interest which midi interface are you using?

Edited by Jauqq (10/04/11 11:30 PM)

I am confident you will find the videos immensely helpful. There are periods of frustration, but, once you wrap your head around what is going on, you can see the light.

The Global offset is to compensate for the track offsets. The process the videos takes you through has you offset your external Midi to match up with the slowest responding instrument. For me, this was my Virus. So my Virus has no track offset, all of my other external Midi instruments do. This puts all Midi behind the beat but, in sync with each other, Midi jitter not withstanding.

After you have all of your Midi notes hitting in sync, you use the global offset to apply a negative delay moving all Midi instruments back in line with the grid. Amazing difference for me. As I mentioned, most audio recording of my Midi instruments now land within < 2ms of the beat divisions, with the occasional straggler of course. This is at a compromise buffer of 128 and a sample rate of 88.2kHz.

What really surprised me was to find that running my Moog Rogue via Volta actually is sample accurate. All the slop was coming from the midi. Astounding. The tools are there to set things right though, thankfully.


As for midi interfaces, I am using a MOTU Micro Lite and a Micro Express. Each one is connected to a separate USB port on the back of my Mac Pro.

I am hoping better midi interfaces are on the horizon with Thunderbolt taking hold in the next 18 months or so. No likely, but, I still hope. Even so, I'm not sure how much the midi jitter will improve.

Edited by alphabyte (10/04/11 11:35 PM)

Quote alphabyte:

---

What really surprised me was to find that running my Moog Rogue via Volta actually is sample accurate. All the slop was coming from the midi. Astounding. The tools are there to set things right though, thankfully.

---

That only goes to prove that you have the recording delay offset for your Motu set correctly. Amazing to see an external hardware synth line up and sample accurate as a softsynth.

I've dived straight into chapter 4: Midi latency. Really interesting stuff!!! Going to run through the examples and hope that things improve.

After doing some noodling around on MOTU's website, they are claiming their OS X drivers allow OS X applications to support the MTS protocol. This is supposed to allow .3ms latency. I am most definitely not getting that kind of a figure with any consistency.

I will be running through the procedures again at different buffer settings and then contact their support with details of what I find. This might be a best case figure of one port sending one note per beat. Very curious... I know I want .3ms latency if I can get it. I might actually be pleased rather than mollified.

Quote alphabyte:

---

After doing some noodling around on MOTU's website, they are claiming their OS X drivers allow OS X applications to support the MTS protocol. This is supposed to allow .3ms latency. I am most definitely not getting that kind of a figure with any consistency.

---

Just been running through some brief testing with my newly arrived Motu Express 128, but first results do not look promising. Using my synth latency test, on a synth which had latency of approx 3.1ms with my Unitor 8 Mk2, now has latency of around 9ms !! Infact the Motu seems to add much more latency all round than the Unitor8, and this is with the latest Motu drivers.
Although it may not be such a big deal as you can compensate for latency using track offsets etc, but it's jitter which you can not compensate for, and thats the major problem with midi hardware.

It is interesting that you are using an Emagic interface and now trying MOTU. I should be receiving an AMT-8 today for comparison to my MOTU interfaces. Jitter is definitely the unavoidable variable when trying to minimize these latencies. I think, were we to simply measure the response of the interfaces, the numbers might not be so bad.

The real delays come from the instruments and their scanning of incoming midi data. I think of it sort of it sort of like trying to throw a ball into a basket spinning about on a carousel. While you probably have relatively stable timing coming from the computer, each instrument in your rig is independently and asynchronously scanning for midi data responding according to its own clock/response times. Again, they are moving targets and about the best we can do is observe the range of jitter and aim for a compromise.

For us as Logic users, the track bug is perhaps the biggest offender of sloppy timing. Once you have decent delays set, things should sound acceptable. After the ATM arrives, I am going to set my track delays and get on with making music.

I've been running further tests today with the Motu express 128 and Emagic Unitor 8 mk2 units, and after my initial negative thoughts on the Motu, im now very impressed with it.
To summarize i've a number of custom made cables with a midi plug one end, and an audio jack the other. This allows me to plug the midi end into a midi interface, the audio jack into an audio interface, and then to record midi on/off data as an audio pulses/files.
I first tried the Unitor 8, and from Logic was sending it eight tracks of quarter notes to all individual midi ports. I took audio recordings from ports one and eight. I then zoomed in both audio tracks to the sample level, to see if both midi on pulses were occurring at the same time. Sadly they were not. The difference was somewhere around the 6ms region.

I then repeated the same test with the Motu 128, and zooming in both recorded tracks to the sample level, both midi ons were at the exact time. Impressive. I even tried with 16ths being sent to the Motu, so as to try and choke it, but it still performed amazingly, with all pulses happening in parallel.

There was however some jitter, but this was universal, so if one port would jitter slightly so would the others. Jitter in the region of 1ms to 1.5ms.

Clearly the Motu unit and it's drivers have midi time stamping implemented correctly, allowing it to send midi data across its ports simultaneously... the Apple/ Unitor drivers do not do the job i'm afraid.

Won't be needing to use the 30 day return window on the Motu.

Edited by Jauqq (14/04/11 08:03 PM)

That is not surprising given the time stamping of Core Midi is based on MTS, at least that is my understanding. It is a shame that Apple do not support the Emagic AMT protocol as well. I assumed they would considering they maintain the driver and include it with Logic.

Out of curiosity, what pins are you measuring from on the audio jack side of your test cables? I would like to compare my interfaces as well given I don't seem to be achieving consistent results with my MOTU gear.

Found another post that seems to corroborate your findings:

http://www.macosxaudio.com/forums/viewtopic.php?t=49786&p=375030

Edited by alphabyte (14/04/11 09:21 PM)

That post *is* John's findings. Same poster.

Right you are. Didn't pay attention to the date

Quote alphabyte:

---

Out of curiosity, what pins are you measuring from on the audio jack side of your test cables? I would like to compare my interfaces as well given I don't seem to be achieving consistent results with my MOTU gear.

---

My friend gave me those custom leads some time ago so i'm not 100% sure how he wired them. However I did contact Kenton of midi interface fame and they advised that the leads could made by:
"Pin 2 of the DIN to the SLEEVE of the Jack
Pin 5 of the DIN to the TIP of the Jack
Note that DIN sockets are not wired sequentially 1-4-2-5-3 (find
something on the web to show) some plugs and sockets have the pin
numbers on in very small figures moulded in the plastic."

However someone else advised me it's actually pins 4 and 5 that need wiring. Also please be aware that your D/A converter is probably not designed to take 5V DC directly so you may risk damage to your audio interface doing this.

Thanks for the info. Seems like adding an appropriate resistor will drop the voltage to a safe level. I'll best out my meter and scope and have a look at the signals.

Quote alphabyte:

---

Out of curiosity, what pins are you measuring from on the audio jack side of your test cables? I would like to compare my interfaces as well given I don't seem to be achieving consistent results with my MOTU gear.

---

As has been mentioned, try running at 32 samples buffer size and that should considerably improve things .
Interested to see what your tests will show.

I Also understand how PDC works and what it does for other timing dependent things. Run some tests if you're not sure. 。。

--------------------
RS Gold Sell and Purchas

at low buffers sizes anyway, is in many cases a lot better than the MIDI response times of many MIDI instruments anyway....

--------------------
RS Gold Sell and Purchas

Quote chuangya:

---

at low buffers sizes anyway, is in many cases a lot better than the MIDI response times of many MIDI instruments anyway....

---

Midi synths reaction time (latency) to incoming midi data can be compensated for by using track offsets. It's the jitter that can not be compensated for.

As far back as Cubase and Notator on the Atari you had track offset parameters.

Quote alphabyte:

---

That is not surprising given the time stamping of Core Midi is based on MTS, at least that is my understanding.

---

It seems to be that midi time stamping in OSX is based on the Motu protocol. (and not on the old Emagic AMT)
Check this post from someone at Motu.
Motu MTS

Edited by Jauqq (15/04/11 09:44 AM)

I have been running with a 32 sample buffer at 44.1kHz for my new battery of tests actually. I decided I needed a larger data sample than the MPV tutorials suggested. At this point, I still have a lot of tracks to record and data to collect for each instrument I wish to use. That being said, I have discovered some interesting patterns.

I thought at first my Virus was the sloppiest instrument because it was later than my other instruments and seemed to exhibit more jitter. What I have discovered is that all of the instruments have a range of jitter. It is just that some cycle through at a faster rate.

The Virus, for instance, jitters somewhere around 2.8 ms. This range of jitter is about half of any other instrument I have tested thus far. The Virus jitter occurrs within a predictable 6 quarter note pattern at 120 bpm, to the sample in many cases.

My Microwave XT, once I had found a ballpark offset was landing exactly on the beat. I was ecstatic. Then, I made a tiny tweak and the next series of recorded tracks were way off again. That is when I decided I needed a larger data sample.

I recorded sixteen tracks of around 100 quarter notes at 120bpm. While collecting the data, everything looked perfect, very little jitter spread over a long period of time and then all of a sudden, I got to a note that was around 5ms earlier than the preceding beat. That is when I realized it too has a jitter. A larger jitter spread over a longer period of time. It was about 30 seconds into the track before this happened.

This tells me if you don't take an adequate sample of real world data to see what the inherent jitter of the instrument is, you won't know what the proper offset should be. I don't see how taking measurement based on three or four bars of playback can be reliable. It would seem a pattern should emerge. If you don't see a pattern, then you likely need a longer recording to provide accurate data. I know this is why he later recorded five or so tracks and split the difference in the start times, but, I have found this to be unreliable, particularly with my older instruments. It really helps to see the instrument's jitter play out over the course of a track.

Again, I haven't had time to run all necessary tests and I may be missing something all together. My methodology could be suspect, but, I feel confident I am on the right track. I feel I am close to zeroing in on what is actual Midi jitter that has alway existed and what kind of bugs exist in Logic.

I am increasingly convinced that the actual midi output from Logic is fine. It really comes down to determining the appropriate offset for each piece of gear you have and how sensitive to the jitter you are.

After spending the day with the AMT8, I don't think it is any worse than the MOTU interfaces. In fact, I don't think they were ever at issue at all, perhaps with the exception of my misbehaving Micro Express. Given the instrument with a long jitter period consistently hit beats in the same place for bars at a time, I think the Midi out from Logic is good from a timing perspective. Where it falls apart is when you try to use offsets to tighten things up. There is a nasty bug in there that causes the tracks to interact in negative ways.

I suspect the jitter would be much less of an issue is Logic properly handled the offsets. Please do consider submitting a bug report if you have not already.


I will post back once I feel I have a better grasp of what is going on.

Quote alphabyte:

---

The Virus, for instance, jitters somewhere around 2.8 ms. This range of jitter is about half of any other instrument I have tested thus far. The Virus jitter occurrs within a predictable 6 quarter note pattern at 120 bpm, to the sample in many cases.

---

I too can confirm this finding. I once tested 16th note patterns to a Virus and recorded the hits as audio. I found every 5th note would jitter, and that the jitter amount was the exact same every time. Even to the sample!

I'm surprised you're not noticing anything untoward with the AMT. Perhaps try to send it a midi track to each of it's ports, and check if there's a difference between the first and a later selected port?

Using the custom cables I did find a major difference with the Unitor, which was not evident on the Motu. Of course this means my test were taken at the purest level, bypassing any receiving hardware synths MIDI latency/jitter from the results.

Edited by Jauqq (15/04/11 10:52 AM)

Quote Jauqq:

---

I'm surprised you're not noticing anything untoward with the AMT. Perhaps try to send it a midi track to each of it's ports, and check if there's a difference between the first and a later selected port?

---

Thinking of this - did you send from ports 1 to 8 on Logic tracks 1-8?

If so, try repeating the test across ports 1 to 8, but reverse the tracks - ie Track 1 sending to port 8, track 2 sending to port 7, etc...

Any difference? Trying to see whether it's the processing on the AMT that's causing the difference across ports, or the order of track scanning in Logic...

Quote desmond:

---

Quote Jauqq:

---

I'm surprised you're not noticing anything untoward with the AMT. Perhaps try to send it a midi track to each of it's ports, and check if there's a difference between the first and a later selected port?

---

Thinking of this - did you send from ports 1 to 8 on Logic tracks 1-8?

If so, try repeating the test across ports 1 to 8, but reverse the tracks - ie Track 1 sending to port 8, track 2 sending to port 7, etc...

Any difference? Trying to see whether it's the processing on the AMT that's causing the difference across ports, or the order of track scanning in Logic...

---

Yes i did send from Logic midi tracks 1 to 8, to Unitor ports 1 to 8.
I'll re-run the test as you suggest Desmond, and report back.

Trevor, im using Motu drivers Version 1.5 37320. (found in Lib>Audio>Midi Drivers) And my Emagic USB driver is version 2.5. Both of these are the latest drivers. See if you have the same versions.

Edited by Jauqq (15/04/11 11:40 AM)

I was not running the most up to date MOTU driver when I started testing. I did update to 1.5 37320 and around that time, my Micor Express started disappearing. I have had this problem in the past, however. I would have to say it has been a while though.

I am running version 2.3 of the Emagic driver. This is the version that was included with my copy of Logic Studio. I have not checked for an update.

I don't have the cabling to perform the test you outlined to check track offset via the interfaces. I can only rout outputs to inputs and multitrack record. The problem here is, Logic does not allow for a one to one recording relationship, i.e. Output 8 to Input 1 ch1, Output 7 to Input 2 ch1 etc...

Logic can effectively record from 16 channels at a time. It records to a single track and then splits the data by channel. It is as if you were recording a 16 channel split from a single controller through a single port.

This does result in note offset on a channel per channel basis. Channel one will be on the beat. Subsequent channels will be about two to four ticks later than the preceding channel. Track order does not seem to matter. This method provides no value in determining how the interface itself transmits data.

I sent playback of four bars of quarter notes from four tracks on channels 1-4:

Track 1-> Out Port 8 ch1 -> Track 5 In Port 3 ch1
Track 2-> Out Port 1 ch2 -> Track 6 In Port 2 ch2
Track 3-> Out Port 2 ch3 -> Track 7 In Port 3 ch3
Track 4-> Out Port 5 ch4 -> Track 8 In Port 6 ch4

Setting all tracks and ports to ch1 only results in one track recording with all data present. The notes still exhibit the offsets. Again, this is a limitation of Logic and does not reflect the accuracy of the interface in my opinion. I will test with my Micro Lite as well.

Attempted Multi-port test with MOTU. Can not come up with a method that does not cause Midi feedback.

I expected this to occur with the AMT8 and it did not. I guess because I am only using four tracks and the AMT has enough to ensure no overlap. Then again, the MOTU might be doing something differently.

I tried muting the record tracks hoping it would terminate midi through. Obviously, this had no affect.

Back to testing instrument jitter...