Hello,
We’ve had some strange behavior with automation during playback. The cursor passes over the waveforms correctly, but for some reason the automation is not in sync with the waveforms. It is early by the amount of compensation delay in the mixer. In other words, the visual waveforms on the tracks are in sync with what is heard coming out of Pyramix, but not the automation written to the tracks.
An example to illustrate the problem: there are very short noises on some tracks that I want to minimize in the mix (thumps and bumps, stage noises, etc.) Typically, I would mouse click to insert automation points and draw the dips, rather than use the faders to quickly dip the channel. But now, in order to put a very short dip, I have to measure 430ms BEFORE the noise that I’m seeing in the waveform. This is very frustrating and time-consuming.
There is reason to believe it is caused by the Delay Compensation in the mixer. We inserted a third-party EQ on a mixer channel, then took it off, but this problem remains.
Is there a setting somewhere that I’ve overlooked? Or is this a new “feature”?
Many thanks,
Nat Koren
San Francisco Opera
Sound Dept.
Automation and Delay Compensation
Forum rules
The Merging Technologies team cannot be held responsible for support queries logged on the public forums. If a support query is logged here and only here, it may not be found and dealt with by the appropriate team.
To ensure that your support issue or bug report is dealt with properly and in good time, please use the link to the tech support request form page on the Merging website.
Make sure to let us know what version you are using when you send your mail. THANKS!
The Merging Technologies team cannot be held responsible for support queries logged on the public forums. If a support query is logged here and only here, it may not be found and dealt with by the appropriate team.
To ensure that your support issue or bug report is dealt with properly and in good time, please use the link to the tech support request form page on the Merging website.
Make sure to let us know what version you are using when you send your mail. THANKS!
Re: Automation and Delay Compensation
Huh, no responses after a week.
Either 1. This made no sense at all and is too confusing. I agree, I'm confused too.
or
2. It made total sense but nobody has anything to say about it
or
3. Halloween fast approacheth and you're all too busy building costumes to bother about bizarro Pyramix bugs.
Either 1. This made no sense at all and is too confusing. I agree, I'm confused too.
or
2. It made total sense but nobody has anything to say about it
or
3. Halloween fast approacheth and you're all too busy building costumes to bother about bizarro Pyramix bugs.
Re: Automation and Delay Compensation
Is it in sync when delay compensation is set to off? If so, is it at all possible to work with delay compensation off? I must say 340 Ms is a lot of delay. With that amount of delay I witness a similar phenomenon ( I do Post Production for TV, music and movie). In my case the waveforms are out of sync, or at least they appear to be. Anyway it is utterly confusing, so I live with delay comp off while editing, and only when mixing switch it on. (BTW: recently discovered that there is a delay comp switch mini popup in the Mix!er/configure page, bottom left)
So really have no answer here, none but switching it off while editing.
BTW: for the thumbs in multitracks: why dont you just delete them? instead of drawing? Make a macro that does split selection, crossfade, delete. Now the clips edges is neatly faded. Very effective in my case.
So really have no answer here, none but switching it off while editing.
BTW: for the thumbs in multitracks: why dont you just delete them? instead of drawing? Make a macro that does split selection, crossfade, delete. Now the clips edges is neatly faded. Very effective in my case.
...Gracefully Ignored...
Re: Automation and Delay Compensation
J.Wajer wrote:So really have no answer here, none but switching it off while editing.
BTW: for the thumbs in multitracks: why dont you just delete them? instead of drawing? Make a macro that does split selection, crossfade, delete. Now the clips edges is neatly faded. Very effective in my case.
Jaap, thank you for the suggestions. We record, edit, and mix opera performances for later radio broadcast and audio-for-video. I will try turning off delay comp the when performing these automation moves, that is a good workaround.
We cannot delete the noises("thumbps", footfalls, etc) because they happen in the middle of a live performance, and we need the music on other tracks to remain whole, with no gaps in the timecode.
thanks,
Nat
Re: Automation and Delay Compensation
No, thats not what I meant. Ungroup all of your tracks and just remove the one thumb on one track! I mean: it's gotta go anyhow. Simple and clean operation, and far more faster then going into drawing mode.Nat wrote:We cannot delete the noises("thumbps", footfalls, etc) because they happen in the middle of a live performance, and we need the music on other tracks to remain whole, with no gaps in the timecode.
And, once again: 340 Msec is really like a lot of delay; thats equivalent to nearly 10 frames in 25 fps Video. I would never be able to work that that amount of latency. Find out what's causing this excessive latency.
BTW: This is the macro:
Edit: Split
Clips: X Fade Default (<-Requires you to have set a default xfade in the fade editor)
Edit: Delete
Now all you need to do is: select the region you want to remove and hit the macro. The selection will be removed and the clips will be neatly faded with the default X-Fade.
...Gracefully Ignored...
Re: Automation and Delay Compensation
Jaap,
I regularly see these kind of latencies if I have a bunch of VST or VS3 plugins in one channel. Add in the possibility of internal nested loops and processing on the buses and the number grows precipitously.
Nat,
Unfortunately, I really don't have an answer to the problem. In our live opera productions, we remove the thumps, bumps, bangs and clangs typically with ReNOVAtor after the editing is done and before the mixing starts.
We have a guy here that is VERY fast at it and then we don't have to spend inordinate amounts of time in mixing fixing the noise problems. It ends up simplifying the mix process so much that it actually saves us time in the big picture.
You should give Jack Vad a call over at the SFS. I know he has a system for working through these things with renovator that goes pretty quickly. The great thing about using reNOVAtor or Cedar Retouch for this is that you can do it as a render in PMX so the file stays in place and in sync and the automation continues unchanged. You can also do the fix on individual tracks or the whole multitrack.
The other thing I have taken to doing is having a "cleanup/editing" desk that does not have any plugins or delay compensation. I then just load this desk when I have a bunch of things to denoise and switch back to the big desk and move on. The one caveat to this is that I really don't use the automation in PMX very much, so I don't know what happens to your automation data when the desks are switched back and forth.
All the best,
-mark
I regularly see these kind of latencies if I have a bunch of VST or VS3 plugins in one channel. Add in the possibility of internal nested loops and processing on the buses and the number grows precipitously.
Nat,
Unfortunately, I really don't have an answer to the problem. In our live opera productions, we remove the thumps, bumps, bangs and clangs typically with ReNOVAtor after the editing is done and before the mixing starts.
We have a guy here that is VERY fast at it and then we don't have to spend inordinate amounts of time in mixing fixing the noise problems. It ends up simplifying the mix process so much that it actually saves us time in the big picture.
You should give Jack Vad a call over at the SFS. I know he has a system for working through these things with renovator that goes pretty quickly. The great thing about using reNOVAtor or Cedar Retouch for this is that you can do it as a render in PMX so the file stays in place and in sync and the automation continues unchanged. You can also do the fix on individual tracks or the whole multitrack.
The other thing I have taken to doing is having a "cleanup/editing" desk that does not have any plugins or delay compensation. I then just load this desk when I have a bunch of things to denoise and switch back to the big desk and move on. The one caveat to this is that I really don't use the automation in PMX very much, so I don't know what happens to your automation data when the desks are switched back and forth.
All the best,
-mark
*********************
Mark Donahue
Soundmirror, Inc.
Boston, MA
mark@soundmirror.com
www.soundmirror.com
*********************
Mark Donahue
Soundmirror, Inc.
Boston, MA
mark@soundmirror.com
www.soundmirror.com
*********************
Re: Automation and Delay Compensation
Hi ALL,
I have been looking in to this automation issue a bit more and what I have found is the amount of delay in the automation "reaction time" is equal to the amount of delay compensation induced in the mixer after all of the buses, plugins and nested looped internal buses have been added up. Here at the SF Opera media suite we have Ceder ReTouch and will use it on occasion. Ducking the fader has been our default way to get rid of the thump and other stage noises. There are other situations when the action on stage is noisy but there is still singing going on. One example is the "anvil chorus" in Il Trovatore or a scene I am currently mixing from Faust where the chorus is singing while pounding their beer mugs on the stage floor. Here I need to duck the foot mics quickly and restore them. The really issue with the automation delay is that if you add or subtract some big plugins after you have gone through with you mixing automation, now all of the automation is in the WRONG place. It is unacceptable that our mix work is screwed up as a result of having to adjust you mixer set up later. I spoke with Dennis Gaines of Independent Audio and he thinks that version 7 will address many of these automation issues. I certainly hope the delay problem gets taken care of.
I seem to remember that with a previous version, when we were editing with the mixer loaded up, that the play back cursor was not in alignment with the waveforms because the audio was delay compensated. This made editing difficult so we stopped editing that way and just started using a simple mixer for editing only. Now with version build 7777 what you hear matches what you see in the timeline waveforms. GREAT, but... Merging seems to have left a little bug in there in that the cursor is delay compensated but not the automation on that timeline. If anyone else can verify this issue I would impress upon the user community to get the message to Merging so this is definitively resolved in the new version 7.
thanks for you comments,
Michael Chen
San Francisco Opera Sound Dept
Audio Recording Engineer
I have been looking in to this automation issue a bit more and what I have found is the amount of delay in the automation "reaction time" is equal to the amount of delay compensation induced in the mixer after all of the buses, plugins and nested looped internal buses have been added up. Here at the SF Opera media suite we have Ceder ReTouch and will use it on occasion. Ducking the fader has been our default way to get rid of the thump and other stage noises. There are other situations when the action on stage is noisy but there is still singing going on. One example is the "anvil chorus" in Il Trovatore or a scene I am currently mixing from Faust where the chorus is singing while pounding their beer mugs on the stage floor. Here I need to duck the foot mics quickly and restore them. The really issue with the automation delay is that if you add or subtract some big plugins after you have gone through with you mixing automation, now all of the automation is in the WRONG place. It is unacceptable that our mix work is screwed up as a result of having to adjust you mixer set up later. I spoke with Dennis Gaines of Independent Audio and he thinks that version 7 will address many of these automation issues. I certainly hope the delay problem gets taken care of.
I seem to remember that with a previous version, when we were editing with the mixer loaded up, that the play back cursor was not in alignment with the waveforms because the audio was delay compensated. This made editing difficult so we stopped editing that way and just started using a simple mixer for editing only. Now with version build 7777 what you hear matches what you see in the timeline waveforms. GREAT, but... Merging seems to have left a little bug in there in that the cursor is delay compensated but not the automation on that timeline. If anyone else can verify this issue I would impress upon the user community to get the message to Merging so this is definitively resolved in the new version 7.
thanks for you comments,
Michael Chen
San Francisco Opera Sound Dept
Audio Recording Engineer
Re: Automation and Delay Compensation
Ok, this has been driving me crazy lately. Addressing this is a must.
Re: Automation and Delay Compensation
Michael,
I have a question about the time shifting of the automation data. If you introduce a new plugin on the output bus, does the automation shift or is it limited to the channel strips? Also, could you just enter a very long compensation delay for mixing so the compensation is always greater than needed?
Secondly, I know this isn't a fix for the automation, but I normally do that kind of automation by editing tracks within the EDL rather than counting on the automation to track accurately. I have a macro key that makes the correct in and out fades and brings up the gain adjustment fader. Being a long time editor, I actually find it faster to do these changes rather than trying to move the dots around or push the faders up and down. I'm sure YMMV.
All the best
-mark
I have a question about the time shifting of the automation data. If you introduce a new plugin on the output bus, does the automation shift or is it limited to the channel strips? Also, could you just enter a very long compensation delay for mixing so the compensation is always greater than needed?
Secondly, I know this isn't a fix for the automation, but I normally do that kind of automation by editing tracks within the EDL rather than counting on the automation to track accurately. I have a macro key that makes the correct in and out fades and brings up the gain adjustment fader. Being a long time editor, I actually find it faster to do these changes rather than trying to move the dots around or push the faders up and down. I'm sure YMMV.
All the best
-mark
*********************
Mark Donahue
Soundmirror, Inc.
Boston, MA
mark@soundmirror.com
www.soundmirror.com
*********************
Mark Donahue
Soundmirror, Inc.
Boston, MA
mark@soundmirror.com
www.soundmirror.com
*********************
Re: Automation and Delay Compensation
mpdonahue wrote:Michael,
I have a question about the time shifting of the automation data. If you introduce a new plugin on the output bus, does the automation shift or is it limited to the channel strips? Also, could you just enter a very long compensation delay for mixing so the compensation is always greater than needed?
In answer to your question, the delay time shifting of the automation happened when an Algorthymics RED EQ (Linear) was add to one of the Sub Mix Buses' Send. I adjusted the compensation delay and it made no difference. If the delay didn't shift with any mixer setting changes, I would just live with the off set, but this seems pretty odd. Is anyone else able to reproduce this phenomenon?
Re: Automation and Delay Compensation
Thanks for your comments. Merging will analyse and bring a solution in a upcoming post Pyramix 7.0 release. Bug id MT004005.
Note that since Pyramix 6.2, every automated controls are compensated. except for the faders... The main reason was because of some internal mixer loop (internal bus), the compensation cannot be done on the fader itself but have to be done separately on each "buses sends" represented by the fader.
But what I am understand here, you mainly come across compensation issue when adding a VST on the strip itself ? In that case, we could easily to compensate the processing delay of the effect on the fader because it affects every buses.
For now, when you need to modify a gain on a clip, we suggest to use the envelop curve which is not implicated in the delay compensation mechanism. I know that in some cases, this is not possible because of the gain is pre effects...
Note that since Pyramix 6.2, every automated controls are compensated. except for the faders... The main reason was because of some internal mixer loop (internal bus), the compensation cannot be done on the fader itself but have to be done separately on each "buses sends" represented by the fader.
But what I am understand here, you mainly come across compensation issue when adding a VST on the strip itself ? In that case, we could easily to compensate the processing delay of the effect on the fader because it affects every buses.
For now, when you need to modify a gain on a clip, we suggest to use the envelop curve which is not implicated in the delay compensation mechanism. I know that in some cases, this is not possible because of the gain is pre effects...
Re: Automation and Delay Compensation
florian wrote:But what I am understand here, you mainly come across compensation issue when adding a VST on the strip itself. In that case, we could easily to compensate the processing delay of the effect on the fader because it affects every buses.
To be more specific, the VST was Algorithmix RED EQ (linear eq) on one of my "sub mix" bus sends which then goes to a stereo bus return via internal busing and then is routed to the master stereo bus. After I discovered this phenomenon, I just removed the EQ and replaced it with the AS3 bus tool plugin for its EQ section in order to avoid having the automation be out of time with the audio. This is especially important because we have to duck out our sometimes loud promptor in the vocal foot mics just prior to the singers entrance or a loud foot step or someone dropping a plate on deck.
I use in my mixer buses the following VST plugins: 2 Sonnex Oxford reverbs, the RND D4, RND Finis, Solera and VB Audio's C10. When you add up all the VST plugin latency, you start to see why my mixer needs over 400 ms of delay compensation. Adding or removing some plugins will change the amount of automation delayed react time.
After meeting Dennis Gains of Independent Audio at the AES Convention in San Francisco, I was able to illustrate to him the symptoms of the automation delayed react time on the exhibit booth DAW with the new Pyramix 7 loaded on there. He is aware of the as yet unresolved issue and will get his findings back to the Merging engineers.
florian wrote:For now, when you need to modify a gain on a clip, we suggest to use the envelop curve which is not implicated in the delay compensation mechanism. I know that in some cases, this is not possible because of the gain is pre effects...
I can try to use the envelop curve but the think I may come up with another issue there. I record 24 tracks from the live opera performances and I always have them grouped together for editing between multiple performances. I believe that the envelop curve will be written to all tracks in a group until I ungroup. This can be very time consuming.
Thanks for your suggestions,
Michael Chen
Audio Record Engineer
San Francisco Opera
Re: Automation and Delay Compensation
There is a quick "shortcut" to writing envelope changes to either just one track within a track group, or several adjacent tracks within a track group. The envelope adjustment will only affect the area which is selected. Begin at the upper left corner of the area you want to select (or any corner). Left-click there but do not move the mouse, then hold Shift, then select any rectangular region. Any envelope adjustments within the selected region will not affect the non-selected areas. Same goes for changing clip gain of just one track - select a region of only one track, right-click > Gain.
Tim Martyn
Tim Martyn
Re: Automation and Delay Compensation
yes, or CTRL-Click the relevant track within the grouped tracks, and only it will be highlit. The alter the level/volume "washing line" / envelope to suit.
Of course, if you want to do it for more than one track - say two sides of a pair or two adjacent mics, then you have to perform the whole operation twice...
AVI
Of course, if you want to do it for more than one track - say two sides of a pair or two adjacent mics, then you have to perform the whole operation twice...
AVI
Re: Automation and Delay Compensation
Hi Alexander,
Actually, you don't need to perform the op twice for adjacent tracks...see my post above.
Tim
Actually, you don't need to perform the op twice for adjacent tracks...see my post above.

Tim