Delay compensation?

[AudioAstronomer]

Is plugin delay compensation planned natively for sawstudio? I know it does decrease the response of the mixer, thereby defeating a good portion of sawstudio's use. But it is invaluable at times. For now It seems the JMS product is quite satisfactory :) I can imagine a few potential buyers being set back though, as many who have considered, ugh, protools, have been because of the severe lack of delay compensation in their software. And their software is in sore of need of it! (le)

[mghtx]

Well, it would be nice but I don't want it to "hurt" Saw's feel and action.

[Bob L]

I've been looking at delay compensation concepts... have not settled on one yet.

Many things come into play when deciding to throw away data.

When using plugins that cause delay, like some of the dsp based plugs... one solution is to slide the track back on the timeline the number of delay samples needed... this gives a perfect result without throwing away data... but is not necessarily the perfect solution.

I have stopped using plugs that cause delay and found other plugs to substitute.

If these plugs were written in the SAWStudio native API, SAWStudio automatically re-syncs everything... it allows samples to be eaten and not returned, and the engine stays perfectly synced.

This design is what allows Jon's compensator to work...

If only the plug manufacturer's would understand how freeing this is for their design algorithms... oh well. :rolleyes:

But I do have some ideas for a future update, possibly an internal factor stored for each FX Choice that gets automatically applied... but there are issues with this type of solution that I am still working on... for instance, building mixes within marked areas can now get confused, along with other internal bus routing problems...

This issue gets a little more involved than meets the eye, especially with the intense console routing ability of the virtual console and all its patch breakout points... but I am working on it. :)

Bob L

[AudioAstronomer]

Well... Im now working in saw with ONLY native FX (woohoo, my dream) and Im quite happy. Nothing special I need for the work I do (basic recording, live reinforcement/recording and some mastering)...

but for the benefit of others.. how's it going?

[Alan Lastufka]

So an instance of SIR on one channel will throw that one channel off from everything else? Guess I'll have to look into the Studio Reverb plug. :)

[AudioAstronomer]

So an instance of SIR on one channel will throw that one channel off from everything else? Guess I'll have to look into the Studio Reverb plug. :)
www.jms-audioware.com

delay compensator!


Personally I love the saw reverb :)

[Bob L]

Well Robert... built-in delay compensation is on the list... we'll see whether it makes it into 4.0.

Bob L

[Sebastian Eskildsen]

The DX plugins seems to be delay compensated in SS also,
am I missing some thing ?

Sebastian

[brent]

Is plugin delay compensation planned natively for sawstudio? I know it does decrease the response of the mixer, thereby defeating a good portion of sawstudio's use. But it is invaluable at times. For now It seems the JMS product is quite satisfactory :) I can imagine a few potential buyers being set back though, as many who have considered, ugh, protools, have been because of the severe lack of delay compensation in their software. And their software is in sore of need of it! (le)

Non PT LE systems have had it for some time. Nuendo has had it as well.

There are still issues with it. It is not exact. It is averaged in many cases. I do not depend on it always.

It is good for me to hear people admit that there are delay issues and a need for delay comp. I brought it up before here and got crapped on. It is an issue for every DAW. When people said that SAW automatically accounted for the delay of the plugs, I went reading the documentation of the newer releases trying to find mention of it. I never found it. Good to know that I haven't lost my vision.

[AudioAstronomer]

Non PT LE systems have had it for some time. Nuendo has had it as well.

There are still issues with it. It is not exact. It is averaged in many cases. I do not depend on it always.

It is good for me to hear people admit that there are delay issues and a need for delay comp. I brought it up before here and got crapped on. It is an issue for every DAW. When people said that SAW automatically accounted for the delay of the plugs, I went reading the documentation of the newer releases trying to find mention of it. I never found it. Good to know that I haven't lost my vision.
You had before ... not all plugins create delay. Only a small percentage... a very small percentage. And saw does compensate for DX and native plugins that do. Normal VST's, in any system rarely cause any delay. No need to compensate. In PTHD systems though... welll hahaha :)

This thread was also started a year ago :)

[Bob L]

For DX and Native plugs there is no need for separate delay compensation in the SAWStudio environment.

The engine is designed to allow plugins to withhold data and SAWStudio will automatically put things back in sync as the data is finially released... and it is sample exact...

The native plugs that cause delay must program this feature... otherwise the delay will still be present... but the fact is that the SAWStudio native API does have built-in provisions for the plugs to alter the buffer sizes at each buffer process call...

VST does not allow this... which is why the apps have had to add in some method of guessing or forcing a certain amount of track shifting.

The delay compensators you reference in other DAWS are still extremely kludgy and not the same, as they are fixed for every buffer call... the SAWStudio engine allows the buffer sizes to be altered on the fly... a much more powerful method for handling special plugin needs.

I still say there should never have been a need for a fixed compensator list of sample delays for different plugins... but unfortunately the rest of the industry creates these problems and then stammers to complicate matters with jimmy-rigged solutions.

Bob L

[Dave Labrecque]

No problems here using the DirectX auto delay compensation via the UAD-1 plugs. And for SIR, the JMS compensator is not a big deal to load and set.

[Dave Labrecque]

Alan,

Patching the JMS compensator in before or after SIR and setting it to 8960 samples does the trick.

[Dave Labrecque]

And saw does compensate for DX and native plugins that do.
I it's more accurate to say that DX plugs do their own compensation and native plugs don't need any. :)

[Dave Labrecque]

No, you've got it right. DX plugs do their own compensation regardless of the host app, as I understand it.

[Bob L]

The DX protocol allowed buffers to be altered at each processing call... it was then up to the host application to be able to allow that... the old SAW32 could not... SAWPro could... SAWStudio also does.

The same idea was designed into the SAWStudio Native protocol but it is ip to the plugin to report back the proper buffer size change at each process call... if it does... then SAWStudio will make extra loops or skip loops through the processing calls until enough data from that track is available to match the data from the other tracks in order to fill a complete buffer and send the data to the soundcard.

You can imagine that it gets very complex with plugins patched PRE against PST against Input, Return and Output Tracks.

VST simply does not allow buffer size changes at all... at least as far as I know... and therefore plugins that required a few buffers of pre-data in order to process their algorithm simply had to retain data and send back blank buffers of the original size... then the processed data was sent back late... therefore host applications that relied on VST heavily created the delay compensation idea to throw away x amount of samples (blank data) before lining up the new data which is coming late.

The idea sounds simple enough but there are many other issues that aren't apparent at first thoughts... and add to the complexity of performing sample accrate operations under varying conditions.

For instance... if you build a mix of an exact number of samples (marked area), then when you throw away the first 3 buffers of blank data from a plugin that causes latency, what do you do at the end 3 buffers of data... the loop is done and the plugin is still holding 3 buffers worth of data that has not yet been sent back... now you need special loop considerations on just the tracks with latency plugins... you also need special commands to force a flush of the rest of the data, or you must stop sending data to the other tracks and send three more blank fake buffers to the latency plugin... etc... it gets ugly... it is a less than perfect design solution to use delay compensation by throwing away blank buffers... at least in my opinion... which is why I have not done it in SAWStudio without more research into a more elegant solution... if one exists.

The other problem is that changing settings on a plugin can sometimes change the delay latency and it gets pretty nuts to try to keep track of all that for each plugin with how many variations of settings and so forth... and even if a good latency report was included in the protocol it gets very difficult to track these changes and adjust as controls are automated to change live along the timeline.

In the end... it seems much easier, if you must use these types of plugins, to simply patch them... build a mix to a hottrack and slide the processed track into position, and adjust by splitting regions along the way if needed.

For my taste, there simply has not been a latency creating plugin I have needed so bad that I have agreed to overlook and work around the latency issues. :)

Bob L

[razor]

The other problem is that changing settings on a plugin ... and even if a good latency report was included in the protocol it gets very difficult to track these changes and adjust as controls are automated to change live along the timeline.
Bob L

Great explaination Bob
now I will let go of wanting vst plugin automation.

Its amazing how much work you can get done when you don't have certain "wouldn't it be great" techniques to play around with.

Give me rock solid performance anyday

Thanks

Phil

[Tim Miskimon]

The DX protocol allowed buffers to be altered at each processing call... it was then up to the host application to be able to allow that... the old SAW32 could not... SAWPro could... SAWStudio also does.

The same idea was designed into the SAWStudio Native protocol but it is ip to the plugin to report back the proper buffer size change at each process call... if it does... then SAWStudio will make extra loops or skip loops through the processing calls until enough data from that track is available to match the data from the other tracks in order to fill a complete buffer and send the data to the soundcard.

You can imagine that it gets very complex with plugins patched PRE against PST against Input, Return and Output Tracks.

VST simply does not allow buffer size changes at all... at least as far as I know... and therefore plugins that required a few buffers of pre-data in order to process their algorithm simply had to retain data and send back blank buffers of the original size... then the processed data was sent back late... therefore host applications that relied on VST heavily created the delay compensation idea to throw away x amount of samples (blank data) before lining up the new data which is coming late.

The idea sounds simple enough but there are many other issues that aren't apparent at first thoughts... and add to the complexity of performing sample accrate operations under varying conditions.

For instance... if you build a mix of an exact number of samples (marked area), then when you throw away the first 3 buffers of blank data from a plugin that causes latency, what do you do at the end 3 buffers of data... the loop is done and the plugin is still holding 3 buffers worth of data that has not yet been sent back... now you need special loop considerations on just the tracks with latency plugins... you also need special commands to force a flush of the rest of the data, or you must stop sending data to the other tracks and send three more blank fake buffers to the latency plugin... etc... it gets ugly... it is a less than perfect design solution to use delay compensation by throwing away blank buffers... at least in my opinion... which is why I have not done it in SAWStudio without more research into a more elegant solution... if one exists.

The other problem is that changing settings on a plugin can sometimes change the delay latency and it gets pretty nuts to try to keep track of all that for each plugin with how many variations of settings and so forth... and even if a good latency report was included in the protocol it gets very difficult to track these changes and adjust as controls are automated to change live along the timeline.

In the end... it seems much easier, if you must use these types of plugins, to simply patch them... build a mix to a hottrack and slide the processed track into position, and adjust by splitting regions along the way if needed.

For my taste, there simply has not been a latency creating plugin I have needed so bad that I have agreed to overlook and work around the latency issues. :)

Bob L


Bob,
How is all this accomplised when one uses several plug ins from different companies? What goes on in this case?
The UAD 1 does not like to be used at the same patch point with say the Saw Levelizer or some other plug in like the Time Works EQ - how come? I love the UAD 1 but most of the time I use it exclusively in fear of crashing. My work around is to apply it to the track & save it to a new file. I think that is the better approch - that way if I have to take the project to another studio - I don't have to worry if they have the same plug ins - What do you think?
Best regards,
Tim

[Bob L]

The UA stuff is quite finnickey... but many feel they can't live without it... that's fair... but you will have to bow down to its every whim... none for me thanks. :)

Bob L

[Naturally Digital]

Bob,

Thank you for your insight on this topic. Very interesting reading.

[TotalSonic]

Hi Bob -
After witnessing the plethora of bugs introduced into Samplitude & Nuendo that took them a few versions to work out when automatic delay compensation was introduced into them - here's a vote NOT to add it into SAW!! I think the JMS Latency Compensator offers a very easy and painless remedy to the one area where I think there is compelling reason to have delay compensation (i.e. getting a nice freeware convolution reverb plugin going in real time) - and I really don't want to see SAW's performance compromised even for a little bit just so that people can run every plugin known to mankind since so many fantastic and great sounding plugins for pretty much every function you can think of are already working extremely well in SAW.

Best regards,
Steve Berson

[Bob L]

It would be nice if more people felt that way... we'll see what happens...

You do know me... if the performance is going to suffer, I will opt to leave out the feature.

Bob L

[bit]

I also vote against auto compensation, but it would be nice to KNOW approximately how delayed the tracks were at the end of the channel. It could be a little green light that turned yellow at 6ms delay and red at 40 or something. And if you clicked it you would get the estimated delay. Thinking about it, the light should only be lit if the control of the latency went out of Saws hands. So off,green,yellow,RED. Just a thought.

Bjorn

[omaru]

I vote for NO plugin delay compensation.

Thanks

omaru

[AudioAstronomer]

I also vote against auto compensation, but it would be nice to KNOW approximately how delayed the tracks were at the end of the channel. It could be a little green light that turned yellow at 6ms delay and red at 40 or something. And if you clicked it you would get the estimated delay. Thinking about it, the light should only be lit if the control of the latency went out of Saws hands. So off,green,yellow,RED. Just a thought.

Bjorn
Wow, that is really a good idea!

[Shawn]

I'm doing just fine here without PDC, count me in for not wanting to "compromise" the real-time feel of SAW.

:)

[Tree Leopard]

Using the JMS / SIR combo has been one of the highlights of the week! :D

Bob - your arguments to keep delay compensation out of SAW make a lot of sense. One of the beauties of SAW is its incredible efficiency. You can still make good use of a machine with an older processor. :cool:

Bjorn's idea of a function that calculates plugin delay could be useful indeed!

Andre

[Tim Miskimon]

Hi Bob -
After witnessing the plethora of bugs introduced into Samplitude & Nuendo that took them a few versions to work out when automatic delay compensation was introduced into them - here's a vote NOT to add it into SAW!! I think the JMS Latency Compensator offers a very easy and painless remedy to the one area where I think there is compelling reason to have delay compensation (i.e. getting a nice freeware convolution reverb plugin going in real time) - and I really don't want to see SAW's performance compromised even for a little bit just so that people can run every plugin known to mankind since so many fantastic and great sounding plugins for pretty much every function you can think of are already working extremely well in SAW.

Best regards,
Steve Berson

Couldn't we have the choice of automatic delay compensation by checking it in the preference menu?
That way those of us who might want the option would have it and those who didn't could just uncheck it.
There are lots of options in SS that I choose not to use most of the time like zero crossing but it's nice that it's there & defeatable.
just a thought -I guess only Bob knows how complicated it would be to impliment the feature.
Tim

[Naturally Digital]

It would be nice if more people felt that way... we'll see what happens...FWIW, I feel that way.


You do know me... if the performance is going to suffer, I will opt to leave out the feature.Hey Bob, don't go chang'in!