Logic Pro 9 Midi Fluctuation

EDIT: I've found it, it's ok. My CoreMIDI framework is version 1.7

 

It's found under the preferences> Info tab in the audio midi setup.

Cool. Yeah, bound to have been some changes for Snow Leopold.

 

I still can't get over those Ableton results. Its MIDI is tight internally, but man, it's completely useless for any external synth work.

Dont have that at all..

Maybe i've a different version as im on 10.6.3

I still can't get over those Ableton results. Its MIDI is tight internally, but man, it's completely useless for any external synth work.

 

That's interesting as I was planning on picking up Live to Rewire with Logic...

Thats some money you've just saved my Fader

That's interesting as I was planning on picking up Live to Rewire with Logic...

Thats some money you've just saved my Fader

Well, actually you should be alright with that. But hey, maybe you didn't really need it anyway!

DId a quick 10 track pass using the RME Multiface MIDI out port. Jitter looks as tight as the Unitor8 performance.

I was planning on picking up Live to Rewire with Logic

 

You could try the Live demo. It does ReWire with Logic nicely. Some details about this are described in a LPH comment here.

Would the Unitor midi driver (latest version 2.5) be used by ALL programs using external midi/Unitor 8 interface, or just exclusive for when running Logic?

Its location is Library-->Audio-->midi drivers, which leads me to believe that its a universal driver for all apps when used with the Unitor8?

 

My thinking is i've tested Logic/Unitor8's midi timing and found it be very good, so would I get the same excellent timing if running Live, and if it were to use the same Unitor driver as Logic does?

Would the Unitor midi driver (latest version 2.5) be used by ALL programs using external midi/Unitor 8 interface, or just exclusive for when running Logic?

Its location is Library-->Audio-->midi drivers, which leads me to believe that its a universal driver for all apps when used with the Unitor8?

Yes, it's a coremidi driver. All MIDI-aware apps will see it.

My thinking is i've tested Logic/Unitor8's midi timing and found it be very good, so would I get the same excellent timing if running Live, and if it were to use the same Unitor driver as Logic does?

No. The "Live" jitter measurements in the previous posts were using the Unitor8.

No. The "Live" jitter measurements in the previous posts were using the Unitor8.

 

So the conclusion would be the actual DAW/ App is the culprit with midi jitter and not the midi driver.....?

So the conclusion would be the actual DAW/ App is the culprit with midi jitter and not the midi driver.....?

Correct. The driver just does what it's told to do by the app. In Live's case, the internal MIDI is tight, but when it has to talk to anything in the outside world via MIDI, its timing falls down.

Kenti here's another thought. Not all keyboards are created equal.

What I mean is maybe the jitter is also coming the external synths themselves.

 

Do you get the same jitter with all your externals? that would imply Coremidi and your driver/interface.

 

Do have different jitter with different externals? then the jitter is also caused by your synths; how well they respond to incoming MIDI commands and how stable and accurate they are at responding.

Do have different jitter with different externals? then the jitter is also caused by your synths; how well they respond to incoming MIDI commands and how stable and accurate they are at responding.

 

This is another important fact which is often overlooked.

For example early 90's Rolands were especially prone to slow response times to incoming midi data.

For example I had a Yamaha YS100 keyboard that responded differently if is was in play mode or multichannel mode. In play mode it would take almost a half a second before I could send a note on command after a program change but in multichannel it was instantaneous.

 

That one of the reasons I got rid of all my external gear and I use software synths exclusively. I find the timing is more manageable and NO MORE CABLES.

For example I had a Yamaha YS100 keyboard that responded differently if is was in play mode or multichannel mode. In play mode it would take almost a half a second before I could send a note on command after a program change but in multichannel it was instantaneous.

 

That one of the reasons I got rid of all my external gear and I use software synths exclusively. I find the timing is more manageable and NO MORE CABLES.

 

BT with his micro-second brain detection also used to complain about MIDI latencies concerning external gear. It's very noticeable, even with my slow brain, when you daisy-chain MIDI systems. You should thank the original MIDI spec writers who didn't include a micr-second timestamp value and a slow protocol speed with no way to up-toggle it.

Sorry to resurrect this ancient thread, but it was exactly what I was looking for. I've never been happy with Logic's external midi timing, it just doesn't sound as good as some high quality hw sequencers. With my LP9 > Unitor setup and sending midi out of the external instrument plugin (cuts jitter in half compared to external midi tracks), I can get the output jitter down to ~1 tick, or .5 msec @ 120 bpm. Sounds fine, but I know some of you realize that's still quite high compared to say an old Akai MPC, which have jitter measurements an order of magnitude lower. It's a difference I can definitely feel when listening to hw-sequenced midi tracks.

 

My question is, after all this time, is there a way to impart that feel when sequencing from Logic? Can we get the jitter down to the <100 microsecond range? Has anyone tried anything with SMPTE timecode? Here's an interesting article claiming that Logic can sync via MTC to Protools with a jitter of <10 samples (when setup properly, otherwise it's a mess!) https://www.justaphase.blog/home/2020/4/23/daw-timecode-sync. The article is talking about audio data but the sync method is decidedly midi. Weren't sw midi sequencers originally intended to be used this way, slaved to a tape deck, not running off their internal clocks? Any insight here is appreciated.

 

Btw, I'm aware of the recent gadgets that create solid midi clock from an audio signal (to keep multiple hw sequencers in time), but I'm more concerned with actually sequencing inside of Logic and getting hw-esque timing on the output.

Not having a solution, but a couple of things to consider if this war is even worth fighting:

- SMPTE TC has a resolution of 1000ms / 30frames / 80 subframes = 0,417ms, so there's no way it can help flatten jitter of that same magnitude or less.

- The timing accuracy of the actual MIDI receivers is often abysmally bad, sometimes in the 10ms range.

- MIDI itself reserves 1ms per transmitted byte, so a single note on would need 3ms already just for transmission, even more until actual audio comes out. Two simultaneous notes are transmitted serially, so that's 6ms right there. Add a healthy dose of Poly Pressure and it becomes clear that this is an uphill battle.

- MIDI sequencers weren't 'intended' to be synced, actually they run much better on their own clock instead of constantly trying to chase and lock to a (jittery) SMPTE code from a tape deck itself plagued by wow + flutter. However, being able to be synced is pretty much a necessity, so they all learned that pretty quick.

Are you still on LP9? Or are you really talking about modern Logic on current systems?

 

There's a Logic timing thread over on GS where we went into this, and verified that in the best case, in LPX using the external instrument and MIDI interface hardware with good drivers that support MacOS's timestamping, that timing performance/jitter was about the same as the that of the "legendary MIDI timing" computer, the Atari ST.

 

I can't remember off the top of my head the numbers, but they are respectable.

 

Timing performance in terms of jitter suffers if you go through the "old" MIDI code - ie the environment, and also suffers if your MIDI hardware/drivers don't support timestamping.

 

This jitter performance is of orders of magnitude better than probably most MIDI device's processing of incoming events, so if you expect that with rock solid MIDI output timing/jitter performance, that all of a sudden your MIDI rig will feel "rock solid", it's likely to not be the case, as your receiving hardware is usually by far the defining factor of how the MIDI event timing feels - and as such, you would use age-old techniques of advancing MIDI events to make up for receiving device delays, separating out traffic across different MIDI ports, and so on - or, resorting to audio time aligning when printing to audio.

 

MIDI event timing is a chain where the weak link makes the whole thing fall down - the output timing of the sequencer is one part in the chain that gives you a resultant MIDI timing performance envelope, but it's often more badly let down elsewhere in the chain - so consider this while you purse "perfect" MIDI timing - which no devie *ever* achieves as the protocol is just not that fast, factoring in transmission speed, and the receive device's input event scanning systems/code and CPU response (eg some, notoriously multitimbral, devices slow down handling of events the more work the CPU is doing).

Thanks, Des, for rephrasing my post

Well, it was really more to add some science and numbers as the RP can go and find the GS thread and get the data on the actual performance possible and the factors that go into it - that was the main purpose of the post. And then I added some extra stuff based on my experiences in this area too...

 

But yes, anyone expecting a high degree of timing accuracy using MIDI probably has too high expectations, and should probably be using audio or CV or something, or just using sample accurate software instruments (with all the fun of latency, audio buffers and latency routing compensation to deal with...).

 

Sometimes it's just more fun to hit record and bash some skins, or thrash some guitar or something, and not worry about all that other stuff..!

Appreciate the thoughtful replies, and yes I’m still using LP9 though from what I’ve read LPX hasn’t improved much on the midi timing front. You’re right Logic’s timing with proper time stamping is respectable and probably in line with competing systems and the mythical Atari ST (I’ve never used it). But as regards the timing of receiving devices - I’m concerned with precision, not necessarily accuracy. [And 0.5 msec on a note event that takes let’s say 5 msec to fully occur is an uncertainty of +/- 10% (not great)]. The problem with midi jitter originating at the sequencer is that it is added to the jitter inherent in all the receiving devices. A 0.5 msec jitter from the sequencer + 0.7 msec jitter from a sloppy mid 80s module, and now the combined inconsistency is over a 1 msec, which is audible. Not bad if you’re overdubbing a single external synth for a pad sound (which I think is the imagined use case these days). But if you’re sequencing multiple machines, to try to lock a bass and a drum sound to create a rhythm section, those additive jitters are noticeable. I’ll report back with a test, but I think my lowly Kawai Q80 performs better than Logic in this regard.

 

I don’t expect SMPTE to be a magic bullet since its resolution is no better than the time scale we’re talking about. I’m wondering though what the source of this jitter is — is it USB messaging or the way midi is handled relative to Logic’s internal timebase? If it’s the latter, could putting Logic on an external timebase help? Splitting the incoming MTC and the outgoing midi region data between 2 midi interfaces? Anyone familiar with this low-level stuff willing to chime in muchas gracias!

Edited June 23, 2021 by quietstorm

You seem to be looking for improvements by syncing multiple things together via MIDI - syncing stuff like this is imo only going to make the problem worse as all devices "freewheel" between incoming sync events, and I can't believe this is much better than the regular MIDI jitter you're already getting.

 

However, for your use case the best you're going to be able to do is try a variety of workflows out with the gear you have and see if you can come to an acceptable solution which gives you the timing performance you want, with a workflow that's workable. If it means using hardware sequencers only (ie if you can't find a software sequencer/MIDI interface combo that is tight enough for you), then go that route, and then maybe print the audio back to your DAW afterwards.

 

It's only really you can can determine what is acceptably tight for your use cases, really. Having had many years of using Creator/Notator on the Atari, yes, the timing was good (to a point - you only had a few MIDI outputs so if you were sharing multiple items of gear, again, the timing suffers way more than any jitter affects things) but it wasn't noticably better than my AMT8 which I've been using for years, first on Win, then MacOS... but like a lot of people, my use of external hardware has declined and I'm more in the box which gives you sample accurate instruments anyway, so MIDI timing becomes less of an issue...

 

So I don't really have any solutions for you except try a bunch of different things, and see if you can find something that works for you. MIDI timing has *always* been a bit lumpy, as it's slow and the event timing changes depending on the data flow - it's very hard to make predictable timing behaviours unless you have really simple cases of multiple timestamped ports, with very little simultaneous data travelling through them...

I know it kind of seems like a backwards/roundabout way to fix the issue, and I’m skeptical to even try. That article I linked to piqued my interest though - that by using a relatively low resolution sync (note: not generated by Logic internally, but external hardware), the variation in audio playback tightened up by a factor of 10. If only we could get ~5 sample variation in midi playback! Would love to know more about how core midi and core audio interrelate within the DAW. Maybe hw sequencers are the answer... though I love the sound I dread the workflow

as promised, I did a quick MIDI loopback test with the Unitor and tested the timing of Logic's sequencer vs my Kawai Q80. This is Logic 9 with an in-house interface with the correct firmware, going out of the External Instrument plugin, and it's less precise than a 96 ppq entry-level sequencer from the late 80s. It shouldn't be this way! I also included a run with the Q80 midi sync'ed to Logic and predictably the timing fell apart.

Can't confirm this here. Here's a bar of 64th notes, each at 40 ticks length, and the resulting loopback recording through a Fireface800's MIDI I/O:

 

This seems pretty consistent, with a 2 ticks delay that is expected.

This seems pretty consistent, with a 2 ticks delay that is expected.

That does look good. Is your interface timestamping those midi notes?

I don't know. It's built into the RME Fireface800, presumably because there still was place for a couple of jacks on the back panel....

RME’s are known for their solid midi timing but I didnt know it was necessarily better than the emagic stuff. Can anyone with a Unitor do a loopback test and get less jitter than what I posted?

I did a loopback test with a MotU interface recently and it was spot on.

I can do one with an MT4 also if that helps.

Anyway, here's a simple loopback test on Logic Pro X 10.5.1 with an MT4:

 

 

Left side is source, right side is loopback result.

It's practically dead on, except for the first note.

All notes are shortened by two ticks. I think that's not unusual because one can't have two MIDI events at exactly the same time. So the previous note can't actually end at the very moment the next note starts. It's probably sensible to shorten it then by one or two ticks (as in this case).

Now I feel bad about complaining when it's obviously my setup that's sloppy. If anyone has any ideas as to why, I'd appreciate the help. My Unitor is firmware 2.0.4 so I think the drivers are fine.