Hi Jauqq, Glad you're finding the tutorial useful, and thanks for the kind words. From what you've written, the way you have been doing things is basically fine. My method is a little more complicated, as it involves a two-step process using both the track delays and the All MIDI Output Delay preference. The reason I use this method, is that ultimately it provides more flexibility than when using the track delays alone. For example, with my method, if I need to change buffer size mid-project (which I rarely do ... but you never know!), I can quickly re-sync all external MIDI instruments to the new buffer size by simply adjusting the All MIDI Output Delay (as outlined in video 45, [i]Compensating MIDI Playback Latency after Changing Buffer Size[/i]). The alternative in this situation would be having to reenter the track delay for each instrument in the project, which could potentially be quite time consuming. Also, with the method I outline, you end up entering positive track delay amounts, rather than negative ones. This leaves the option open to use a Sample Delay plug-in on the instrument's input channel, in place of the track delay parameter (as outlined in video 49, [i]Alternative Method for Compensating MIDI Playback Latency[/i]). (Incidentally, as of last week, using Sample Delay plug-ins instead of track delays is my preferred method for working around the track delay bug that I outlined in video 48, [i]Bug Shop - Part 3[/i].) So if you don't think you'll ever need to change buffer size, and the track delay bug isn't rearing its head on your system (btw, I'd be interested to hear if it's not, as it's happening on both my systems), then there's no reason to change your method - except for possibly one thing ... ... and that is, how you record the MIDI instrument's audio signal. Take another look at video 40, [i]How to Record External Instruments to Audio - The Right Way[/i], as it explains why, when recording external MIDI to audio, I set the audio track to receive its signal from a bus, instead of directly from the audio interface's input. In essence, though, for the MIDI playback latency test to be accurate, the MIDI instrument must be recorded from the point at which it is heard. Recording directly from the instrument's input into Logic, records it from before this point. This means that if you don't use the bus (or loopback) method that I talk about in this video, and instead record directly from an input, the waveform on which you will be basing your measurements will be placed early against the grid, by the amount of the system's roundtrip latency. This will lead to you under-compensating your playback latency - so it will look fine, but sound late. At a buffer size of 32 samples, this will only amount to a few ms, so its impact won't be too apparent, but when testing and working at larger buffer sizes, it will be more so. Hope that helps clear things up for you. I know I can only get my head around this stuff after a good strong coffee or two! Tom

Hi Jauqq, What I mean when I say that MIDI instruments should be recorded from the point at which they are heard, is that you should record them from the end of their output/monitoring path. When monitoring through an external mixer, this means recording from the mixer's output. If the mixer is analog, which introduces no latency to the monitoring path, then you could record directly from the synth's output instead. So your current method works perfectly in this scenario. When monitoring through Logic's mixer, though, the end of the instrument's output/monitoring path is at the audio interface's output, so you should record from there (using the loopback method). Alternatively, you can fake a loopback recording by using the bus method outlined in the videos. Let me know if this, the coffee and video 40 haven't cleared things up for you. Tom

Hi Jauqq, Routing the signal through a bus won't impact on the monitoring path at all, so leave it in place for times when you want to print an external MIDI instrument to an audio track. If you don't use this, or the loopback method, your MIDI to audio recordings will be positioned out of sync. Tom

Hi John, For a quick question, you sure chose a curly one! I don't have the Silent Way plug-in, or an analog synth to test this on, but having given some thought to the signal paths you are dealing with, I think this is what's going on ... Let's think about what would happen if you had a MIDI note on beat 1 of an External MIDI track feeding your synth, and a control message on beat 1 of the Silent Way's Software Instrument track also feeding your synth. Assuming you've calibrated your external MIDI track and output delays as outlined in the videos, the MIDI note will be sent before the playhead reaches beat 1, so that after passing through the synth and audio interface's input, it enters Logic's mixer exactly when the playhead reaches beat 1. At this point, the control message from the Software Instrument track will trigger Silent Way to produce an audio signal. This audio signal, and the already-triggered note from the external synth, then both make their way through the audio output path, resulting in them both arriving at the audio interface's output at exactly the same time. The note from the synth is then heard from your speakers, while the signal from Silent Way travels to a VC input on the synth. Assuming that the reaction time to the VC signal is zero, the effect of the of this signal won't be heard until the resulting output from the synth travels back in and out of Logic's mixer, to the speakers. In other words, the VC signal from Silent Way will be heard late, by the system's roundtrip latency amount, while the notes triggered from the External MIDI track will be heard spot-on in sync with the grid. So the answer to your question is to still record your synth to audio via the bus or loopback methods, so that what is recorded matches exactly what was heard. Sure, your VC will not be aligned to the grid, but it will be no different to how you were hearing it before printing to audio. (Incidentally, one way to check sync between the recording and the original is to listen to both together. If sync is tight you will hear mainly phasing, provided there aren't too many random LFOs, etc in the sound. If sync is off, you will hear flamming - or at least very little phasing.) If you do want to sync your VC signal more tightly to the grid, then you could try converting any track-based automation to region-based automation and setting the region delay to negatively compensate for the system's roundtrip latency (as displayed in the Audio Preferences). Like I said though, I can't test this, so I'm just making an educated guess. So try it out and see. As a side note, I don't think this sync problem will exist when monitoring external synths through an external mixer, as any MIDI track and output delays will be set to match the output latency of the audio path, meaning that the CV and external MIDI signal should arrive to trigger the synth at the same time.) Hope this is clear enough for, as it's definitely a brain twister! Tom

As a follow up, if you're not worried by the VC signal being slightly out of sync before it's recorded to audio, but really want it bang-on after it's recorded to audio, then the no-fuss solution would be to record ([i]the wrong way[/i]) through the inputs. The MIDI notes will then of course be slightly early, but that may or may not be a problem. It all depends on what you are trying to achieve in that particular instance. The important thing is to understand the cause and effect of things, so that you can make the best (and easiest) choice for a given situation. Tom

Thanks Victor. Glad to hear you like the tutorial! :-) Tom

Hi Jauqq, If pressing the right arrow expands the marquee selection, then press the left arrow a few times until you get a single pixel selection. From then on, pressing the right arrow will advance the selection as in the video. The problem you are experiencing with the entire region being deleted to the right of the selection is a bug that can occur at high zoom levels. When this happens, simply press cmd-z to undo the operation. This will reinstate the deleted portion of the region, while retaining the desired cut at the marquee selection. Tom

Hi Rounik, Glad you're enjoying the tutorial. I happened to go through some of your OSX tutorial last week and picked up some nice tips on Automator - so thanks for that! I'm using 9.1.3 too, but have also experienced this behaviour in other versions of 9 (and possibly 8 too). I just did some fiddling, and it only happens when Snap is set to a non-beat based value. That is, when set to Smart (and zoomed in), Samples, or QF. So I'm guessing it's caused by some kind of quantisation error occurring when Logic converts the marquee position to a sample or SMPTE value, to perform the cut. Tom

Hi vibrance, Glad to hear you like the tutorial! The All MIDI Output Delay preference only affects external MIDI. Software Instruments and ReWire instruments remain unaffected - so just set it and forget it. Tom

Hi vibrance, Good question! The test I'm running in that video is for determining the playback latency of external instruments only. Remember, an external instrument is any MIDI instrument not running within Logic itself - so MIDI messages must leave Logic to reach the instrument. This means that an external instrument can be a hardware instrument, or it can be a virtual instrument running in standalone mode. As I have Kontakt running as a standalone application, rather than as an AU plug-in within Logic, Kontakt is an external instrument as far as Logic is concerned. The reason that Kontakt's latency is so much higher than the (hardware) external instruments in this video, is that I've set its output buffer quite high - 512 samples from memory. Setting the output buffer to 32 or 64 samples would bring it more into line with a typical external hardware instrument. (Kontakt's output buffer is set from within Kontakt's audio preferences - don't confuse it with Logic's I/O buffer). As far as your EXS is concerned, Software Instruments have no playback latency, so running this test is not necessary for them. However, if you do run the test, it should result in a measurement of zero samples. If you're not measuring zero samples, then either your Recording Delay is not set correctly (see the earlier videos for how to set this), the sound you're triggering in the EXS is not trimmed to start on the first active sample, or you have latency-causing plug-ins inserted in your project. Check those things and see if that corrects the situation. Glad you're enjoying the videos! Tom