Ow! This is something I hadn’t seen before, thanks for posting it. I, too, and getting into the EEB and I have run into a few issues. Now notably my click is gone if I list all my outputs in my VST window, and remains lost if I remove the extra outputs. This isn’t good, I can’t fly without a click.
I have used the ping and it seems like it is working, but I say this because I did have a different path and it registered 31 ms, I added a VST plugin before the EEB and it reduced to 20 ms. All of which tell me that something is trying to work at least. I should also add that as I addded all the outputs to my Output Bus via the VST connections window, besides losing the click, I also lost the 20 ms delay - and the ping shows ‘0’. ?? Reading that article really makes me wonder what the recorded results actually are in regards to delay compensation.
FWIW, I have manually moved the track and adjusted the compensation in the Channel window and things seem to be OK with playback. Of course I am compressing something, too. Eh, you know, how can I compare the original and the compressed waves exactly?
I do hope that Steinberg responds to this. I have to think a poster here does not have the social weight of SOS mag… However, I do hope that Steinberg designers/experts would at least be up front about this with the forum members. I really find this feature a bonus to the Cubase software and would feel even better about using it if I knew the ping check was working properly.
Rereading that article I see it was just published this month. Well, SOS is pretty on the ball so I have to conclude that they are using 6.0.5. I mean, they are smart enough to use the most recently updated software else their complaint will look a little exaggerated? So this does not look good. Too, they mention a possible fix for Cubase 7? Eh, disheartening.
That said, my issue with the click was self-created. When you expand the Outputs Bus from a Stereo Pair, the click track becomes unchecked in the VST window. Click it back on and all is good. Thank you mashedmitten!
I definitely going to test this in my system - possibly tonight…
I will be mixing a record in just a few months with Cubase and I am going to be using some external hardware. I was all excited because of the integration Cubase offers with the “ping” function… but if it’s broken, obviously I will have to manually correct for the offset. I hope by some miracle they can fix this quickly… hopefully SOON - before I start final mixing on this album!
I have emailed with the author of the article, he mentioned that 6.05 hadn’t been released when the article went to press, and so that’s why my post was titled that way … to see if anyone using 6.05 had noticed if it was fixed.!
He did recommend a workaround:
Meanwhile… it’s not a huge issue, unless working with parallel compression. The workaround there is to use a physical loopback on an audio interface channel (ie jack cable connecting your output to an input) on the uncompressed version. You could even set up an external instrument called ‘interface latency’ or some such. That way, you can send one half to the compressor, and one half through this physical loop, and both will experience the same latency and thus remain in time. People might worry about the artifacts of conversion, but that’s not going to be a significant issue with one pass like this. (The only downside, apart from the fiddling, is that you tie up physical I/O like this.)
toader - can’t wait to hear the results of your test!
The author seems pretty nonplussed about the problem in your personal conversation. ? I have to say that I have the attitude that he seemed have when he wrote the article, if you follow. My thinking is - since I have no way of perfectly measuring the throughput, I am just stumbling in the dark. But sure, maybe you can get it close. Then again, the phasey audio he refered to in his article? Well, I do have this occuring when I pair the comped track up with the original track - no matter how I adjust the two tracks in time/sync. At this point I am thinking it may be unavoidable even if Steinberg assured me that the initial ping is correct. And I say this because, listening to the paired tracks, I get the strange feeling that there is some constant movement in the EEB recorded track. I guess this is just what ‘phasey’ describes, sure, but you would think there would be one lucky moment when I could get things perfectly aligned. No, I don’t think it’s possible.
Well, so perfection. Would a correctly time aligned EEB produce a less phasey sound when the original track and the Efx’d track were combined? It should. So have at it, try it for yourself and you will see what I mean.
OK, all of this said, my external comp does an amazing job on my kick drum track. So good, in fact, I am thinking of just pulling the original out and replacing it with this. It’s that or pulling up (slightly) either one against the other at mixdown time. Frankly, where this should sound killer, it doesn’t. If I replace the original track it means I will also have phasing issues with my overheads of course. Maybe a small price, I’ll let you know.
Oh, one last thing. Where the author was saying to run two identical versions of the track out two different EEBs (the only way I can see to do what he suggested), one straight and the other compressed? Well, that’s some added work but I will try this just to see if it can possibly work. It may well be that, again, even run this way, that combined with my overheads, my overall drum mix will suffer too much. I’ll see. But I definitely see where an isolated bass guitar track could work. Well, or any isolated track for that matter.
The author mentions a free tool to measure the precise loop back time, “the free NAT sampler that comes with Acustica Audio’s Nebula”. I wonder if that would help with your “phasyness” more than slipping and sliding by ear?
Are you guys sure this bug doesn’t just show up with certain hardware? I’ve been using the ping function with C6 for some time and have not had any problems in Windows 7 - I get the same delay as I always did through my converters (1.86 ms). I’m using an RME RayDat, BTW.
Ping has never worked with RME Fireface 800 because of negative latency values being reported by RME hardware which Cubase cannot handle. Steinberg know about this and every time this thread comes up, I chime in, but I wait in vain for it to be fixed…
Are there not any other RME FF800 users who need this feature???
WEIRD HOW STEINBERG HAS NOT RESPONDED TO THIS POST.
OK, I was out for a day, I am going to try the dual EEB and get back here on that.
As to the response that the author wasn’t using 6.0.5, I guess with all the updating and Steiny pushing the software edge, this kind of thing will happen. Still, I’m glad for the SOS article because I think it explains what I was hearing. And I’m glad Steinberg has kept the updates coming.
I also want to ask the poster who said he was not having any problems using the EEB? What external efx were you using and did you hear any phasey issues as you played the original track against the efx’d one? With a latency number of 1.86 ms, well, that seems reasonable. Still, reading the article and the author stating that RME can produce negative latency I am wondering if your hardware is unique, as you suggest.
Well, I think Steinberg needs to comment on this post. If they say it is working as intended, I would love to hear what kind of latency #s they are getting - with whatever interface they are using - I don’t care what brand. I would just like to have a general idea of what kind of delay a working Cubase 6 EEB setup is producing. In other words, if they say they are getting ‘0’ ms delay or .85 ms, or 10 ms, whatever, then I would at least know what the Mother Ship is dealing with. This would at least give me an idea of what to expect. The way it stands right now, my numbers went from 32/20/0 ms and I was blindly happy with all of them.
Bullocks, I wrote a long and detailed testing result earlier, but not again. I timed-out apparently.
The short comment is this: To the best of my abilities, I have decided that my EEB target ms delay compensation number is around 20 with my DAW. I have seen a range of 32/20/19.75/18.75/17.75/17.73/0. The 32 # was the hardware making friends, my take. The ‘0’ number was an error on my part - I did not engage the insert on my Mackie board. I would also recommend pinging a few times just before recording. As I did this, the number typically goes down a bit. Not a clue as to why, just a report.
I am signing off on the ping feature then in Cubase 6.0.5. I think it works perfectly. Which means I have now realized that my first recordings were flawed. I had managed to record only ‘half’ the bus, not recorded the results of the full EEB path -my very bad. Listening to the original track, an imported EEB recorded compressed track, and another EEB recorded ‘straight’ track, both recorded in two different passes, dragged and dropped back into the project, the sound is fat and full - no phase issues in the slightest. Comparing waves visually, the two non-compressed tracks are identical, and the compressed track is compressed. I did the work correctly.
The fact that I see the ms #s change during a 5 minute window rather puzzles me. For example it might first fire up at 19.75. And then as I come back to make another pass 5 minutes later, it might be 17.73. Is this the DAW? The AC to my house? The oxidation on the connector? Cubase 6.0.5? I have no idea. I do know that I can get the recording I need now so I am a simple happy camper. No, not perhaps, the Albert Einstein in Yellowstone Park camper… Er, a speed of the varying bus joke.
I would hope someone else can make these same tests, as well, on different DAWS. Hearing some more delay compensation numbers would be interesting. Refering back to the article, the 1.86 ms number reported by the RME user, and now my confirmed numbers, it is clear to me that there is a spread here. In fact, seeing my numbers I say WOW! to anything approaching ‘0’ ms. This will never happen over here. Hope this helps someone.
OK, when you say ‘digital connections’ do you mean optical cables? On my DAW this is a physical connecting with cables from the mixer to the external unit. My send and return to the DAW from my interface is via firewire, that’s digital, but when the original track is sent out to be modified, it’s all cables from the mixer to the efx unit and back to the mixer. This would probably explain your 0 latency then vs. my 20. Yeah, my external effects units are entirely analog.
As to the ping being tested with the unit bypassed, sure makes sense and I always try it both ways - the number is always the same either way, FWIW. Maybe it’s the analog thing, dunno. How about you, different ping number?
Your point is well taken I think. If it works in Nuendo it should work in C6 and it does here. Thanks for the post.
Hi - I set up an external effect years ago in SX3, but have forgotten anything I learned then, and so am reading the chapter and various posts in preparation for doing it in 6.5. I will be using 1) an analog compressor, and 2) a digital signal processor.
A couple of questions I have:
The chapter in the manual on setting up external effects (pages 30 and 31) says I need to “create a new MIDI Device for the external effect”. What does MIDI have to do with it again, is it just for automation? It refers to a chapter that is very confusing to me, “Using MIDI Devices” on page 356. Can someone give me the Cliff Notes version for the part relating to External Effects please? I’m afraid I’m not sure which part of the MIDI Devices chapter I need to be paying attention to, and which of the boxes should be checked/unchecked in the MIDI Device Window …
Re: Bredo’s post at the bottom of this one - Just wondering - in bypass, won’t the ping then be shorter than it would be when the device was actually in use (which would add some processing time to the round trip time)? Would that cause problems in things lining up?
to get an accurate ping time you need to bypass the FX, as mostly you’ll be using digital outboard you will get the FX input/output converter time, and for analog outboard you wouldn’t want any compression/EQ, whatever interfering with the ping signal and the delay on analog gear is basically zero.
So…is this a problem WITH 6.05? I still have the OTB 6.0 installed…and ping seems to work fine here. Granted, the only thing I’ve been doing that would cause phasing is multimic’d drums…sent some out to the IBP since they HAD phase issues, and resolved them. So, is it that it doesn’t ping (or reports zero)? Or that it doesn’t actually respect the compensation value the ping finds?
This is a bit of a big deal…I’m about to buy a lot of expensive IO to use the external insert function…which appears to work fine here, unlike um…other softwares…
Wow, I did a lot of whining and writing on this post!
OK, in trying to answer your question let me just point out, and I do think the 6.05 is going to be the same as 6.5 as far as working for you goes, that you need to set up the ping, record the new part using your analog gear (bringing the track back to your project on another track!), and then deal with your mixing of the original part and the effected track. Part of my problem was thinking that I was going to be able to mix down the whole project on the fly. The ping feature doesn’t work this way. Make your path>record the results>mix down.
Well, ‘by on the fly’ I meant that I was mistakenly thinking originally that I could set up the ping to the external efx and do a full project mixdown back into the DAW.
Like, say I had my bass gtr track going to an external comp and I had twenty other tracks that had VST efx on them and I wanted to mix the entire project down. I realized that this is not the way of the DAW mixdown and an external efx, that bringing the comped bass gtr back to the DAW is something that is done ahead of time. So it’s like freezing a track sort of, you apply the efx to the track, Cubase pings it, you rerecord the track and drop it back into the project (keeping the original of course), and then do your DAW mixdown blending the efx’d track into the total project. Well, you could skip the original track if you want, but I find keeping it and blending the two is better for me. But the point is, the time alignment of the rerecorded vs. the original track is perfect.
Yeah, so there is no mixdown engineer drag and drop alignment in my process. In fact, no matter what I THOUGHT I was accomplishing when I tried to drag and drop a efx’d rerecorded track done with and external routing, there is no way to do it without some type of phasing when the original and the rerecorded track are played simultainiously. Even knowing the ping ms delay number did not help. HOWEVER, the Cubase ping, used the way it was intended, the same way I describe using it, it works perfectly. There is no phasing at all when the two are blended. (And this not being able to physically align the two tracks does not include just routing the track out and back in via the EEB without any device in the chain because I have never tried this. This may work, but I’m not sure why anyone would do this actually. My thinking here is that, rerecording the original track using an efx in the EEB, the efx itself puts a spin on things such that a hands-on alignment becomes impossible.)
Lastly, I know I read here about people with ‘0’ ms ping delay using the Cubase ping Ext Efx Bus setup, but I don’t believe it. If the prerecorded signal/track is coming from the DAW and going to an Ext Efx Bus, and then going back into the DAW to be rerecorded, the ping number can’t be ‘0’. You can wish is was, but it can’t be.