Logic Pro Help

Are there any disadvantages to permanently setting the Process Buffer Range to Large (2048 samples) ??

I mean 40 ms (approx. for 44.1k-48k) is still a pretty short amount of time, and due to Logic's hybrid engine, the I/O Buffers take care of "live" audio with much lower latency than the Process (mix) Buffer.

Once Logic has started playing pre-recorded material via the Process Buffer, surely all that matters is that everything stays in sync??

Some thoughts would be appreciated.

: D

Obviously as subject close to people's hearts

Anyone?

: D

I don't know much about exactly what this affects, but I ran into a problem with timing using the DMXIS USB->DMX light controller when I had the process buffer set to large.

Are you running into performance issues? If not, I suggest leaving it on the default setting, just to reduce the possibility that it will case some random subtle problem to crop up in 10 months, after you've forgotten that you changed it, and drive you nuts trying to find the cause.

Not that I've ever experienced that or anything....

I remember that UAD used to recommend setting the Process Buffer size = I/O Buffer.
I also remember this thread where Logic chased better with a small PBS.

Mod Wheel RBA not chasing

OK, so far I'm not affected by these particular problems.

I've read ski referring to higher buffer sizes affecting MIDI timing. Is this just "live" MIDI input and the I/O Buffers?

Or does the Process Buffer affect MIDI timing too?

Thanks,

: D

I think the issue is when you start using other non-Logic software plugs... not all of them seem to be compensated correctly, which makes for an unpredictable usage scenario. Hit & miss ain't fun for laying down tracks...!

RedBaron wrote:

I've read ski referring to higher buffer sizes affecting MIDI timing. Is this just "live" MIDI input and the I/O Buffers?

Or does the Process Buffer affect MIDI timing too?

My writings on I/O buffer size and how different settings affect MIDI timing go back a while (maybe even a few years). I haven't investigated lately whether this is still the case with more recent versions of Logic (i.e., Logic 9). And I don't recall if process buffer settings influenced that at all.

Larger I/O buffer settings definitely negatively influence how quickly virtual instruments appear to respond. High settings = high latency. My gut instinct is to say that it's not the response of the instrument itself that's being delayed... rather, the audio they produce in response to MIDI is delayed. That my guess.

If you're playing external MIDI instruments and monitoring using the external instrument I/O and software monitoring in Logic, then higher I/O buffer sizes will delay when you hear the audio they produce. But again, I don't know if the Process Buffer has any influence.

On the process buffer itself, I used to have it set to "small". But as I changed my system over time, including use of Vienna Ensemble Pro and setting the number of Threads in Logic to 16, I had to set my process buffer to "medium". No other setting works at all.

Back to the I/O buffer, I've found that on numerous occasions when I'm mixing, the higher the I/O buffer size, the better the sound. More clarity, more definition. Even if a project seems to run fine at 128 or 256, the sound quality improves at 512 and 1024.

FWIW...

ski wrote:

Larger I/O buffer settings definitely negatively influence how quickly virtual instruments appear to respond. High settings = high latency. My gut instinct is to say that it's not the response of the instrument itself that's being delayed... rather, the audio they produce in response to MIDI is delayed. That my guess..

So are you saying that there is no delay once the virtual instrument receives a MIDI note on. In other words, the VI spits out audio the instant it receives a note on, but it's the incoming MIDI message that's jittering.

Or are you saying the incoming MIDI note on is received with relative timing intact, the VI generates it's audio instantly, but that audio sits in a jittery output buffer(s)?

Thanks for the great info by the way.

: D

ski wrote:

Back to the I/O buffer, I've found that on numerous occasions when I'm mixing, the higher the I/O buffer size, the better the sound. More clarity, more definition. Even if a project seems to run fine at 128 or 256, the sound quality improves at 512 and 1024.

FWIW...

Are you sure this is not psychoacoustics, Ski? I have never noticed this and considering what the I/O buffer size actually does, which is buffering incoming and outgoing data data to protect against clicks, pops, and dropouts, I cannot think of a logical reason why it would be so.

Holger, if you are out there, I would like your take on this.

@ RedBaron, I'm suggesting that the VI reacts as soon as it sees a MIDI Note On, but that we hear the audio late due to buffer latency. The buffer is part of the audio system. OTOH, MIDI has nothing to do with audio. MIDI notes only trigger the onset of sound.

@ Ashermusic, I'm sure it has nothing to do with psychoacoustics. It's a phenomenon I've noticed for years. My ears don't lie. I hear things other people don't hear ("I hear dead people") It's both a blessing and curse. While Holger might be able to offer a technical explanation, he's not going to be able to refute my experience. Really, Jay, you can take my word for it. Or not

ski wrote:

@ RedBaron, I'm suggesting that the VI reacts as soon as it sees a MIDI Note On, but that we hear the audio late due to buffer latency. The buffer is part of the audio system. OTOH, MIDI has nothing to do with audio. MIDI notes only trigger the onset of sound.

@ Ashermusic, I'm sure it has nothing to do with psychoacoustics. It's a phenomenon I've noticed for years. My ears don't lie. I hear things other people don't hear ("I hear dead people") It's both a blessing and curse. While Holger might be able to offer a technical explanation, he's not going to be able to refute my experience. Really, Jay, you can take my word for it. Or not

Hey Ski, yes, we had those (and many more very deep) discussions 6 or 7 years ago on that "other" forum. The suggestion that MIDI has nothing to do with audio, and that we hear audio late due to buffer latency stands correct in my opinion as well.

Furthermore, I can confirm your "blessing and curse" experience first hand, hearing it daily and since many years as well! Maybe "clicks, pops and dropouts" are just part of an underlying spoof about a newly invented style of music we have not experienced yet.

OMG!! Sonther! OMG!! How the heck are you? (PM to follow)

sonther wrote:

Furthermore, I can confirm your "blessing and curse" experience first hand, hearing it daily and since many years as well! Maybe "clicks, pops and dropouts" are just part of an underlying spoof about a newly invented style of music we have not experienced yet.

ROFL! Brilliant as ever.

ski wrote:

@ Ashermusic, I'm sure it has nothing to do with psychoacoustics. It's a phenomenon I've noticed for years. My ears don't lie. I hear things other people don't hear ("I hear dead people") It's both a blessing and curse. While Holger might be able to offer a technical explanation, he's not going to be able to refute my experience. Really, Jay, you can take my word for it. Or not

I hear you, and when someone that I respect's experience disagrees with science (and I am not saying it will in this case) then I can only turn to my own experience the tie breaker.

ski wrote:

... MIDI has nothing to do with audio. MIDI notes only trigger the onset of sound.

This is something I have a problem with. In my system, I regard MIDI as having a very close relationship to my Audio. My MIDI events need to occur at precise timing points relative to sample-accurate Audio. I think I should be given the option to relate/lock/quantize MIDI events to the sample/word clock coming from my ADAT master clock.

The following article has some interesting points regarding Logic's "live" MIDI input buffer. Apparently, Logic always has a MIDI frame-offset of 0, suggesting the MIDI input itself is badly buffered (jittery):

MIDI jitter might be ruining your live performance

Hi Red Baron,

You say you have a problem with my statement that MIDI has nothing to do with Audio, but what I wrote is accurate. And you can bank on it.

MIDI messages are simply digital messages that are produced in response to each action you perform on a controller. When you play a note, a Note-On message is generated saying which note you played and how hard you played it. Included in that message is the MIDI channel. Once that Note Message is done (and it lasts approx 1 ms) the sound propagates on its own from the instrument itself until you release the key. Then, a Note-Off message is generated for that note. When that's received by the instrument, the sound will stop at a rate determined by the properties of the instrument itself (specifically its release time).

(Some of the above is paraphrased from my video tutorial on MIDI available at MacProVideo.com.)

My MIDI events need to occur at precise timing points relative to sample-accurate Audio.

But again, MIDI has nothing to do with audio or sample rates.

MIDI is not time-stamped when you generate it. And as it is, every time you play a note, there is going to be a minimum delay of one millisecond because that's the length of a MIDI Note-On message (and one that's not generated under "running status"). Besides, MIDI is a serial protocol, so even when you think you're playing simultaneous events (like a chord), the result is actually an extremely fast arpeggio of MIDI messages for each note.

And because it's a serial and asychronous protocol, it's impossible not to have jitter in MIDI messages from the source (your controller).

Thus...

I think I should be given the option to relate/lock/quantize MIDI events to the sample/word clock coming from my ADAT master clock.

Need more coffee to address that one.

The following article has some interesting points regarding Logic's "live" MIDI input buffer. Apparently, Logic always has a MIDI frame-offset of 0, suggesting the MIDI input itself is badly buffered (jittery):

MIDI jitter might be ruining your live performance

I'll have a look and get back to you on that too.

Wow, that really didn't come across the way it was intended

I wasn't criticizing your statement. From what I understand, it's how Core Audio works.

ski wrote:

My MIDI events need to occur at precise timing points relative to sample-accurate Audio.

But again, MIDI has nothing to do with audio or sample rates.

...

MIDI is not time-stamped when you generate it.

...

I think I should be given the option to relate/lock/quantize MIDI events to the sample/word clock coming from my ADAT master clock.

My point is that my external MIDI (synths) are using software monitoring on input audio channels, and that audio is being mixed with audio generated inside Logic (soft synths). Every time a MIDI note triggers a sound in an external MIDI synth, that audio is mixed inside Logic with this other (internal) audio. I want both sets of audio to stay in sync/time. For me they share a relationship because their audio is being mixed inside Logic in some musical way.

Now you can tell me to take a running ski-jump...

: D

Oh, I didn't take what you wrote as criticism at all. So no worries I tired to indicate that with my "mr greeny" smiley. It's all good.

I hear what you're saying about wanting everything to be sync'd, especially to word clock. But there are tons of technical limitations that prevent things from being the way you described.

When it comes to any audio that you're monitoring through Logic, it's all eventually sync'd to word clock. So in effect, your internal and external sound sources are merged and are played back under the same clock. It's true, for MIDI devices that don't have a wordclock input, that audio is going to be generated independently from Logic's – until such time as it's analog-to-digitally converted; then it's as in-sync with all of your other audio. But this isn't really a problem. An external synth's analog audio output is no different from that of a live musician or vocalist (and their audio output wouldn't be locked to word clock LOL!) But the sampling that takes place at your A/D converter is driven by the wordclock, so at that point the analog, "free running" audio is converted to following-word-clock samples.

I hope that makes sense.

Sorry for opening this thread again, but in my experience the buffer size has a tremendous impact on midi timing. I've set it to small after I tried to work for way too long with a large buffer range and was struggling with staccato's and percussion. One percussion-loop I made (with East West samples) was actually "limping" on this setting. Glad that nightmare is over...

Interesting.

Are you talking about MIDI going to Software Instruments (internal).

Or External MIDI going to stand-alone plugins, or external MIDI devices?

dD

Idsz wrote:

...in my experience the buffer size has a tremendous impact on midi timing.

RedBaron wrote:

The following article has some interesting points regarding Logic's "live" MIDI input buffer. Apparently, Logic always has a MIDI frame-offset of 0, suggesting the MIDI input itself is badly buffered (jittery):

MIDI jitter might be ruining your live performance

I can verify that when using Direct MIDI Input (such as a live keyboard) software instruments in Logic 9 will exhibit the "MIDI quantization by duration of the sample buffer size errors" discussed in the above eigenzone.org MIDI Jitter link.

The same channel strip driven by a Recorded MIDI Region will play back fine however. (Perhaps in this more leisurely mode, Logic is programmed to take more care with exact MIDI timing while calculating the instruments audio output.)

This unpleasant MIDI Jitter can easily be verified by sending, for example; a semi-ridiculously fast arpeggio from an external MIDI keyboard feeding a software instrument in "Live Mode". Notice the differences in timing as you try out various I/O Buffer sizes, from the largest to the smallest. At larger settings the timing can audibly "limp" as it strobes against the buffer's audio latency. The "Jitter" clears up quite well at 32 samples. (I've also found this setting will remarkably tighten up even dense "Virtual MIDI Output" from a plugin such as the Kirnu Cream arpeggiator.)

To recap:
This section from the eigenzone.org MIDI Jitter article explains what's going on.

The timing of the MIDI data is completely unrelated to the audio stream, it’s up to the host to correlate them. MIDI events merely arrive as reliably as possible at the host who subsequently has to pass them on to the audio plugin. Again, the host uses an internal buffer to store the MIDI data that arrived while the plugin was calculating a batch of samples. When it’s time to calculate the next batch, the host simply passes the buffer of MIDI data to the software plugin so that it can calculate the corresponding audio.

It’s here that additional MIDI jitter can set in. If the host doesn’t remember when the MIDI events arrived while storing them in a buffer, the software plugin can only assume that they started at the beginning of the sample buffer it’s generating and that they followed each-other, one by one, without any delays in between. Since everything is snapped to the beginning of a sample buffer, this effectively applies a quantization effect to the MIDI events with the duration of the sample buffer size. For a buffer of 512 samples at 44.1kHz, the audio is then quantized at intervals of 11.6ms.