jb_blog

Anyone who uses Pluggo, in order to run any of the really great TriTone plug ins, needs to be made aware of an issue with the latest Pluggo installation (v3.5.2). Evidently, this new version adds 64 samples of latency, which is not documented anywhere in Pluggo's documentation. This is not a problem for those who are running these plugs with FULL delay compensation, as the additional 64 samples are accurately compensated. But, for those of you who (like me) are MANUALLY adjusting for any plug in latency, this will effect the value you need to compensate.

For instance, using TriTone plugs as an example, ValveTone62 has always had a latency value of 44 samples. Running under Pluggo 3.5.2, ValveTone's latency value is now 108 samples (VT's 44 samples + Pluggo 3.5.2's added 64 samples).

Another interesting discovery... HydraTone has always had a latency of 33 samples. The latest version of HydraTone (v1.22, released July 25, 2005) seems to have an additional 1 sample latency, making its total latency value now 34 samples. And when running it under Pluggo 3.5.2, Pluggo's added 64 samples bring this up to a grand total of 98 samples of latency (HT's 34 samples + Pluggo's added 64 samples).

Because I am working with some Logic projects which were begun before updating to Logic 7.1 (where FULL PDC was available), I am still running Logic's compensation in the Audio channels and Instruments mode, where I am manually compensating for latency in busses. This means that under Pluggo 3.5.2, I would have to change all the latency correction values for my busses which have any Pluggo (or TriTone) plug ins on them. So I have chosen to revert Pluggo back to v3.5.1 in order to avoid this.

TriTone promises an update, as well as notification, to address these issues. Cycling 74 states "The 64 sample offset you noticed is due to an improved buffering scheme for PLuggo." I will keep you posted if I hear anything further...

Logic claims to have Full Plugin Delay Compensation. I find this to be a technically accurate claim, although in actuality there should be a caveat to clear up at least one little "problem" encountered when Bouncing files, with PDC engaged.

Logic does accurately compensate for the delay (or latency) induced by plugins in the chain, when bouncing. However, for what ever the number of samples of latency Logic is correcting in any particular bounce operation, that exact number of samples at the beginning of the bounced output file, are going to be SILENT. ??!! That's right.. silent.. blank.. as quiet as a church-mouse. In discussing this issue with Apple, they seem to think this is completely acceptable, however I say that this renders the claim (of Logic) to have "full PDC" to be a little bit deceptive.

For a visually demonstrated picture of what this translates to, visit this page

Good luck!!

Edit: Make sure to see the "Plug-in Latency" entry below for more info on this topic

IF you have constructive feedback for Apple on issues related to how Logic works, then by all means, TELL THEM. Don't do what most users do, and simply complain to other users, who can do nothing to fix the problem. Tell Apple.

Apple's Official Logic Feedback Page
Please... DON'T use that page if you only want to vent. Or if you only want to complain about something.
DO use it if you have a constructive suggestion that will make Logic work better. Even if you only want to complain about something that seems broken to you please choose to phrase your submission in such a way that Apple will see it as a constructive suggestion. Be nice.. it seems that Apple likes it better when we treat them with respect, and chances are, your suggestion will make more of a dent in the pile of things that need to be addressed if you say it in a way that sounds nice. Do unto others, and all that...

Granted, it's extremely frustrating when we submit valid feedback, and then never ever hear a single word of acknowledgment that any human-person ever sees our comments. Personally, I think Apple would do themselves a huge favor with their user-base if they'd reverse their behavior on that. However, it appears that people do actually see those submissions, and at least some of the issues submitted do actually get fixed down the road in future updates.

Interesting, this one. I've noticed, ever since v7.0 (and continuing through 7.0.1 and 7.1), that there is a strange start-time display issue going on in Logic. Here's the deal:

If Display prefs are set to "Display SMPTE with Milliseconds" (which is where I usually leave it), then changing the song start-time (in Song Prefs/Sync settings) makes the display (and the actual start-time) go to a point OTHER than what I enter. This is not at all good, if you need to specify a particular starting point, for any number of completely valid reasons. Logic SHOULD set to start-time to the exact point the user specifies, or am I wrong? For instance, if I change the start-time to 0Hr 00Min 20Sec 00Frames/00MS, the setting jumps to 0:00:20:04. Why?? I haven't figured out why. Only Logic knows why it does that.

I've found a FIX for this annoying little problem. Change the Display pref setting to "Display SMPTE with Bits." Then enter the start time. If it still jumps to the "wrong" value, then double click on the "incorrect" value to select it (the "04" in the example above), press Delete (Backspace), then Tab. And THAT process should set to the desired value you've entered. At that point, you may change your Display pref back to "Display SMPTE with Milliseconds" and all should be good. I've noticed a time or two that I have to repeat this process twice in order to get the proper value to "stick."

Strange, but at least on my system, this fix only seems to work with the Display setting set to "with Bits." Why, Logic, why?

Annoying? You bet. But at least there's a work-around. There you have it.

Edit: Make sure to see the "Logic 7.1 & Bouncing""Logic 7.1 & Bouncing" entry above for more info on this topic

About delay compensation and Logic.. In all versions of Logic, there have been issues requiring some manual manipulation in order to accurately deal with latency introduced by plug ins. This is true all the way up through and including the current version, as of this post, which is 7.1. And it can get quite confusing, but once you get a handle on it, it makes sense.

If you are using Logic 7.1, you can select FULL delay compensation in the Audio prefs, and thereby avoid having to manually correct at all. However, if you're on an earlier version, or if you only select (in 7.1) the option to compensate in normal channels and not busses, then you'll need to compensate in some way for latency induced when processing with a delaying plug in a bus, but not for channel processing. In THAT instance, if you use the plugs in a normal channel insert (not a bus), then you won't have to adjust at all. If you use the plug in a bus, and you have only the channel option checked in your Logic Audio prefs, then you would have to adjust for anything feeding that bus. However, if you're using Logic 7.1 and you select the compensation to adjust for ALL plugs, then you won't have to manually adjust.

If you choose to use the FULL compensation option in Logic 7.1, there may be some issues with new recordings of midi performances. If that's going to be a problem for your usage, see this thread for more info:
http://www.bigbluelounge.com/forums/viewtopic.php?t=21192&highlight=

If you DO need to adjust, you need to know the exact number of samples the plug-in in question is adding to the process in order to correctly adjust for it. A thread I started a long time ago which outlines the way I had to set up for compensation on busses under older versions of Logic, which is pretty detailed, and quite possibly much more reading than you want to do, is here:
http://www.bigbluelounge.com/forums/viewtopic.php?p=71716

An easy way to compensate without having to alter any actual audio files, if you are adjusting before doing any bounce, is to use ExpertSleepers Latency Fixer plug: http://www.expert-sleepers.co.uk/downloads/latencyfixer_1_0.tgz
If I've set the prefs to only correct on channels (and not busses), It forces Logic to correct for processing on a bus by inserting the LatencyFixer on each channel which feeds that bus, and setting each instance to the correct number of samples. Since Logic will be correcting for the normal channels, this fools it into thinking that those tracks need to be adjusted by x-number of samples. Easy fix.

If you've already bounced files which you want to compensate for, and you decide to do it by altering the actual audio file, I usually go ahead and actually trim the file, permanently deleting the correct number of samples (of induced latency) from the very front edge of the bounced file. If you want to play it safe, you may choose to simply move the anchor forward by x-number of samples, just to be safe. For instance, for HydraTone, you'll have 33 samples of induced latency, so open the bounced file in your sample editor, blow it up big (so you can see down to the individual sample-level), and simply drag the anchor forward and park it at the 33rd sample of the file.

The latency I've measured with some of my recent plugs is:
[These results are @ 44.1KHz, however, most of them seem to be the same @ 48KHz, except where noted - disclaimer: I did not test ALL at both sample rates]
HydraTone: 33 samples
ValveTone: 44 samples
BlockFish: 4 samples, uncompensated anywhere in Logic
SpitFish AU @ 44.1KHz: 663 samples. When used in a channel, it evidently reports the wrong value to Logic, because there are still 2 samples of latency even after it is automatically compensated for.
SpitFish AU @ 48KHz: 721 samples. When used in a channel, it evidently reports the wrong value to Logic, because there are still 2 samples of latency even after it is automatically compensated for.
FloorFish @ 44.1KHz: 132 samples
FloorFish @ 48KHz: 144 samples
Elemental Audio:
- Neodynium: 0 samples, unless using Lookahead, then add correct # samples for x-ms of Lookahead
- Finis: 58 samples
-Firium: 3,072 samples
PSP MixPak (AU) latency is listed in the manual:
- MixBass: 1,023 samples
- MixSaturator: 0 samples
- MixPressor: 1,023 samples, may vary depending on the process
- MixTreble: 1,023 samples - may be different if Hiss Removal is engaged

Here is an older listing, compiled back in September 2004, so some of these may have changed slightly with newer versions of some plugs.. I don't know
PSP VintageWarmer: 511 samples
Antares AutoTune 4 (via VST-AU Wrapper): 35 samples and it seems to be UNcompensated anywhere in Logic, even with Delay Compensation checked!
Bias SoundSoap (not Pro - via VST-AU Wrapper): 1,924 samples
Waves RenBass: 0 samples
Waves RenChannel: 65 samples
Waves RenComp: 64 samples
Waves RenVox: 64 samples

If a plug you're wondering about is not in those lists, then I don't have a value for it, and you'd need to figure it out yourself.

Cheers.
jb