Latency and External effects

Beya, if you asking me, than again, I have to say, that although I see the "Ping" function in Cubase as the big advantage over LogicPro, it still will not make Cubase my favourite DAW. I do work with Cubase and Nuendo for many years. If I can decide at the beginning of the project work to choose between SX/Nuendo or LogicPro, I'll take Logic. It's just a matter of taste. My taste is affected also by cushiness 🙂 And I know that certain tasks will take more time in Cubase than in Logic (in my case...)... Also-I know I feel more comfortable with Logic (not that I spent less time with SX/Nuendo). I can find easily workarounds for things from SX/Nuendo that I migt miss in Logic. I will hardly find them in opposite case (or I know it will take more time to find workarounds for my favourite things and functions from Logic inside SX/Nuendo). Probably no DAW in this world is perfect in all it's aspects. To me it seems like Logic is way more flexible and customizible than SX/Nuendo. And you can find workarounds. Like the TINKERTOY'S workaround with saving a Channel strip with I/O Helper plugin and LatencyFixer plugin . Great time saver. Once you set latency for your device, you are done, and you do not need the "Ping" function... I really respect you like SX/Nuendo and I can imagine that and why you prefer it. I only felt like "jeeeez, c'mon, You are not the only one who has Cubase!" 😉

PS-If you read about the apple FW driver problem, than THAT is what really matters and what affects every audio application that uses FW device that relies on apple FW driver.

Despite what the above poster said, there is NO means
to adjust for insert latency in Logic. There is a
recording delay parameter , but that has no effect on
this problem.

I just wanted to officially recant my comments since
I did not understand what you were trying to do. I
always will admit when I did not get it right and
this is one of them. I have to respect the superior
knowledge you have in this area and am reading
this thread hoping that I will learn and take something
away to increase my knowledge base.

I dont know if you all heard, but while you have
been slamming Apple for the bad driver, they may
have already fixed it. I cannot say for certain that it
has been fixed. First reports are good but you can
try it for yourself and find out. Check 3/4 down
the page for themudshark's post. He put in the link for
the driver. (It is only for the Ensemble right now but
he tells you how to get it.)

http://discussions.apple.com/thread.jspa?threadID=675079&start=0&tstart=0

Apogee Ensemble Updater can be made to update OSX with newer (beta) versions of Apple's 'AppleFWAudio.kext' (Firewire streaming driver), and 'AppleMLANAudio.kext' (which I assume only affects mLan users, though Yamaha have not made any comments to us regarding new beta versions that might concern us being distributed by Apple).

Having run carfeful 'loopback' tests to determine latency consistancy, it has had a noticable affect, the average latency on my setup is nearly half what it was before installing the new versions, BUT ... the randomness (of latency after restart or reloading of the driver) is just about the same - frequently 40 samples adrift from the previous measured latency for me. So it's definitely NOT fixed for mLan. I assume the update has fixed other issues for Ensemble users.

Someone else has tested the driver on a TC Konnekt 24D (non mLan), and has apparently found latencies as much as 95 samples adrift - so it's not just mLan still affected.

I'd be surprised if anyone found that careful testing produced an absolutely stable offset, with Ensemble or any other device that uses Apple's driver (MOTU and M-Audio, for instance, do not) - but stand to be corrected by anyone that runs careful tests and finds otherwise (the latencies involved can be small enough to be unoticeable under many circumstances).

I don't think I believe that Apple have yet fixed this issue for any device; they certainly haven't fixed it for all devices.

Andy.

G5 Dual 2.7, MacMini, iMac 700; P4/XP Desk & Lap. Mac OS X (10.4.8) mLan:01x/i88x; DP 5.1, Cubase SX3, NI Komplete, Melodyne.

Phillip, after I did fast look at the topic I think I can say it is about the latest beta driver (released a week or so ago) for Apogee enssemble. this driver changes something inside OSX, however after a few massive tests from fellas from aogee and 01x forums it is clear that it does not fix the RANDOM offset issue. Ít will be quite a surprise if it can fix this problem for Focusrite only.
Enssemble itself does have even worse issues (you can read some topics here) like computer freezing and random offset problem seems to be too far away from this perspective. There is something rotten inside (this) apple.

That is too bad, I was hoping you folks could put
this behind you. As for as the Apogee, I am glad I
bought the RME. I guess you can all get back to
bashin Apple. Sorry to interupt.

I posted this a few times but never got a feedback... so I don´t know if I crazy or just stupid...
I work with Logic professionally since 1998 more or less,so I think I know the app...

I think PDC is done backwards (also in Nuendo, but I don´t care about that). Why the approach is to delay everything to match the most delayed processed track? IMO it should be done the opposite: read the processed tracks BEFORE to have time to calculate the fx and be in time with the non processed ones. This approach solves the problem with PDC+MIDI, and also lot of the other problems regarding full PDC and music recording.

Can someone please explain me why it´s done the way it is? I just can´t get that nor what´s wrong with my idea (other than have ti rewrite the PDC part wich should be done anyway...)

gpiccolini , your suggestion seems "logical" to me. I also think this probably will solve the MIDI+PDC issue (which is really nasty)
Probably it requires to rewrite Logic from scratch as ZMIX posted?

IMO it should be done the opposite: read the
processed tracks BEFORE to have time to calculate the
fx and be in time with the non processed ones. This
approach solves the problem with PDC+MIDI, and also
lot of the other problems regarding full PDC and
music recording.

This is indeed the way DP does it. Works perfectly.

I get the strong impression that Apple jumped into Logic (and before that CoreAudio) without quite realising or thinking through just how many important little 'nuts and bolts' there are to professional audio processing, and now they're playing catch up. The only silver lining I'm hoping there is to this cloud is that I don't see how a company like Apple can possibly afford to get a reputation for being useless for professional audio - sweeping statement I know, but if their solve-it-all Coreaudio, and drivers for class compliant Firewire (and I think USB as well, from my tests) devices, can't be relied upon, it's kind of true at the moment.

And as someone else mentioned, aggregating any device to built in audio is an absolute disaster, it introduces random latency values from one take to the next. Hopeless. OK, it's only built in audio, but on a machine where I'm paying, amongst other things, for built in optical in and out, I'm sorry but I really do expect sample accuracy.

I think Apple have to sort all this out eventually, I just wish they'd get a move on. With so many of us accumulating a variety of interfaces, what we could really do with is a Coreaudio that caters for multiple devices, *each with their own latency compensation setting*, and for class compliant devices it ought to be possible for the OS to automatically calculate, report, and set these values. My mLan audio almost always prints ahead of where it should be, so something, somewhere, is trying to compensate, but getting it wrong I guess.


G5 Dual 2.7, MacMini, iMac 700; P4/XP Desk & Lap. Mac OS X (10.4.8) mLan:01x/i88x; DP 5.1, Cubase SX3, NI Komplete, Melodyne.

Andrew, (AndyLuvsMac-aren't you?)
Indeed , my mLan audio also prints ahead (which was the first time I saw it "breaking news related to Einstein's theories and to basic physics laws")

Aggregated Device is really a toy/marketing hype. Unusable for real pro audio work. I tried it not only with mLan devices but with motu and other devices as well. Only had problems. I agree with your statement that apple jumped into Logic without having a clue about REAL PRO AUDIO needs. As someone (zmix?) wrote, whenever anybody tries to attent Apple to our problems from real world, it seems their answer is always some kind of :" not on the top of to-do list". I am really afraid apple wants to keep focus on users that are working completly In The Box and which are not affected by problems we have. I think we have to ask for things we want. And keep asking until we get them.

IMO it should be done the opposite: read the
processed tracks BEFORE to have time to calculate the
fx and be in time with the non processed ones.

This is how Logic does it.

IMO it should be done the opposite: read the
processed tracks BEFORE to have time to calculate

the

fx and be in time with the non processed ones.

This is how Logic does it.

...are you sure??? why are we getting latency then...? why midi is early???

I think you didn´t understood my post clear enough. I´m sorry if it´s my fault because my English...

the only case you get latency taking the opposite way that Emaple has taken is if you try to apply fx to a live input... I can live with that a hundred times more than with the present approach.... Do I need to process that input and ALSO need no latency??... Let´s record it and apply the fx after that... solved! and with no timing problems all over the place... ( I´m exagerating just to see if someone at that fruit company hears me and gives a proper explanation about why oh why they decided to go this way...)

IMO it should be done the opposite: read the
processed tracks BEFORE to have time to calculate

the

fx and be in time with the non processed ones.

This

approach solves the problem with PDC+MIDI, and

also

lot of the other problems regarding full PDC and
music recording.

This is indeed the way DP does it. Works perfectly.

Nice to hear that.It proves it´s possible besides logical. It´s the proper way to do it. We don´t put all the population in jail because some are killers...

hmmm... foget about that example... it wasn´t a good one... 😉

Actually, there are 2 kinds of latency compensation in Logic. The first one has been in place for a very long time and occurs on all audio tracks and audio instruments. this is the one i believe you are referring to, and works by 'pre-reading' tracks by the amount of the plugin on that track. the second one is the kind on buses and is switchable (they actually both are switchable on and off now) but was recently introduced. That's the one that everyone is complaining about, and I think (not totally sure about this) works by delaying all other tracks by the abount of latency introduced on the bus with the plugin on it.

All the answers to you questions are here:

http://docs.info.apple.com/article.html?artnum=304112

"In Logic Pro 7.1, if you set Plug-in Delay Compensation to All, any new tracks you record will be late and out of sync with previously recorded tracks. You may also experience increased latency when playing Audio Instruments live. Here are some concepts behind the issue and tips for resolving it."

Sombody please give me some points!