A bug that has bothered me for 20 years

[LittleJJ]

Sometimes (seemingly randomly) when I print audio from a VI in DP I will get an enormous transient spike on the first note. Like 20 dB!! I have had this problem for probably 20 years. This is clearly a strange bug. I can work around it by playing a dummy note before the part actually starts and then cutting that part of the soundbite off later, or by carefully crafting a fade in at the start of a note, but it means I cannot just have a “normal,” natural start point for my audio. I have probably spent a hundred + hours correcting for this bug over 20 years, and I have never seen anyone else post about it. This is, of course crazy making because 1. How can I be the only one having this problem (it is not at all subtle, we’re talking about enormous spikes well into distortion territory)? Or 2. How can it be that no one else is bothered by having to work around this chronic problem. To anyone who responds, a thousand thank yous! [fyi: For what it’s worth, I’m a longtime music industry professional, not a noob.]

[Tidwells@aol.com]

If I understand correctly, you are saying the spikes happen when you use the "freeze" function on a VI track, correct? Personally, I've had trouble with the first note not getting recorded when I freeze a VI track. In those cases, I have to move the start point for freezing a little earlier, maybe 50 or 60 ticks before the start of the first MIDI note. You might check and change your smart selection options and see if that helps any. I wonder if it's starting the freeze after the beginning of the first MIDI note? But it sounds like you may have already tried moving the start point for freezing earlier and that does not fix the problem. You have to actually insert another note earlier.....Fascinating! As Spock would say....

Doug

[LittleJJ]

Not “freeze,” just tracking a VI to audio. Actually, it happens sometimes when I’m recording guitar too, but way less often.

[Tidwells@aol.com]

In that case, I suggest trying the freeze function to create the audio tracks of your VI parts. Perhaps that will eliminate the audio spikes....or maybe not. Regardless, freeze is a very convenient function, as it automatically creates a new audio track of the correct type (mono or stereo), does the bus routing for you, and also somehow "remembers" the connection between the original VI track and the new audio track, so later you can just go back and refreeze a couple of measures if you've changed the part and it will record over only the specified measures on the new "frozen" track. Or, you can create a new take on the "frozen audio" track and re-freeze the whole track, keeping both versions. I often freeze 4 or 5 VI tracks at once. The only caveat I warn of: watch the peaks on the audio monitor window. If a track you are freezing is clipping, cancel or undo the operation, then insert a trim plug-in on your VI track and reduce the level, perhaps by 10 db. Then, after freezing the track, insert a trim plug-in on the frozen audio with a boost matching the amount of the cut on the original VI. Maybe this will help, or maybe you will still get the "spikes"....

Doug

[Tidwells@aol.com]

Sorry, after reading your post again, I realize you may be saying the "spikes" happen when you are recording the audio of a VI you are playing live. In that case, all my advice about freezing is pointless. However, perhaps you should consider recording just the MIDI performance instead of the actual VI audio to avoid the problem, then freeze it when you are happy with it. Or, find a way to record both the MIDI performance and the audio at the same time, so you have a "backup" and don't lose a brilliant take.

Doug

[stubbsonic]

That this has plagued you for 20 years, is the real takeaway. I have to imagine 20 years of troubleshooting, experimenting, etc. etc. Ugh. Gives me a sympathy-headache just thinking of it.

[Tritonemusic]

Are you recording with a compressor plug-in, by any chance?

[Irimi Nage]

YES, I get this too, and also have for many years. I use the same workarounds, and probably like you, some others devised as needed. Off the top of my head it can happen when printing VI's, freezing any track or using bounce to disk. I don't think I've seen it while merging soundbites.

I don't know about other DAW's really, but historically MOTU's not been great about removing some of the long-standing bugs in DP.

Like when you click on a currently straight automation line to insert a new point, it won't enter the point at the current value of the line. It'll enter it as -.1 db or something completely irritating like that. If I'm doing a lot of automating in a day I'm constantly cursing this. Enter the point, then EDIT the point. Almost every single time. Rarely will it enter the point correctly on the first move. Such a waste of time and energy! Especially when compounded over decades. OBVIOUSLY I'm trying to enter the point at unity gain, I CLICKED RIGHT ON THE DANG LINE ugh COME ON. Of course I have workarounds for these things but they're corrective and not preventative. There are several other weird behaviors or bugs like this.

Ok, topic-borrowing mini-rant over. Back to IRL cursing at DP while I finish this song
I actually came here to see how widespread this window blackout issue is, another real time waster these days.

[mikehalloran]

Are you recording with a compressor plug-in, by any chance?

I see that this question never was answered.

[bayswater]

Has anyone reported this to MOTU? It’s one of those problems that seem to be specific to certain setups, so it could be something in the OS, plugins, etc. I’ve never had this problem, nor the problem of the first note missing, excessive time to render, missing tails, etc etc etc, and I’ve never been able to reproduce these. Rather than a bug, it seems to me it must come down to some difference in one or more aspects of the setup. It seems to me quite possible that developers and beta testers never see them either.

These problems are real, but they won’t be solved until some who see them send projects to MOTU support so they have a chance of reproducing them.

[mikehalloran]

Has anyone reported this to MOTU? It’s one of those problems that seem to be specific to certain setups, so it could be something in the OS, plugins, etc. I’ve never had this problem, nor the problem of the first note missing, excessive time to render, missing tails, etc etc etc, and I’ve never been able to reproduce these. Rather than a bug, it seems to me it must come down to some difference in one or more aspects of the setup. It seems to me quite possible that developers and beta testers never see them either.

These problems are real, but they won’t be solved until some who see them send projects to MOTU support so they have a chance of reproducing them.

I'm in the same boat as Bays. I read about these issues and have no doubt that they are real for some users but have never experienced them. Likewise, no one has ever posted a complete enough description of their setup so that the curious can try and reproduce the condition.

[Irimi Nage]

There is no system info that would be relevant here to post. Some of these bugs have been around for decades, across so many versions of hardware and software that the details are basically inconsequential. I've personally reported them to MOTU numerous times, they obviously don't care.

I admit I'm hella pissed off right now, I keep getting session-destroying UA Native/iLok licensing errors and am getting really frustrated with developers not fixing these basic issues.

[LittleJJ]

Are you recording with a compressor plug-in, by any chance?

I see that this question never was answered.

The answer is no

[mikehalloran]

Unfortunately, no one has posted enough specifics for anyone to be able to try and reproduce the problem. Not saying it doesn't exist but the idea that all VIs do it… No, they don't. If that were true, it would be happening to everyone.

What VIs? What players? What platform (AU/VST/VST3)? What OS and build?

[bayswater]

Since that topic fizzled out, there was another with some hints, suggesting that the problem is specific to certain VIs. It looked to me like these VIs didn't entirely meet specs according to MOTU, but other DAWs had accommodated them. I think M Canavan had the specifics.