• SONAR
  • A free plugin to show PDC Info (the delay that each plugin introduces) (p.2)
2016/05/05 09:20:16
Chregg
its crashing sonar with me
2016/05/05 15:19:56
SilkTone
Thanks for the feedback! I'll try to answer the points that were brought up...
 
bluzdog
Awesome! Thanks. There's a Sonar Resources and utilities sticky in the software forum: http://forum.cakewalk.com/Sonar-Resources-and-Utilities-m3392713.aspx that would give this the exposure it deserves.
 
Rocky

 
Thanks Rocky, I'll post details about the plugin in that thread.
 
mettelus
Just installed and tested this, very nice. I have been toying around "straddling" plugins (i.e. an insert before and after), just to look at numbers.
 
A couple quick questions/comments:
  1. For a specific plugin being straddled, the PDC of that plugin would be the difference of the "Output" values, correct? Reason I ask this is the example below - better stated, the "output" number is the difference of the PDCInfo to what?

 
The PDC Info plugin itself doesn't add any delay, so the value at its output should be the same as at its input. If we look at the VST3 spec, then my understanding is that the "Output" value is supposed to be the delay that is seen from that plugin's output until the audio is sent to the speakers. The point here is that the plugin is supposed to use this info so that it can sync its display to what the user hears. So for instance a VU meter should use this info to delay its graphics by that amount of samples so that it looks like it is in sync with what you hear.
 
However the spec also says this should include the delay that the driver reports to the host, which is another place where SONAR isn't doing the right thing it seems. When I put PDC Info as the very last plugin in my main bus, it shows 0.0 ms. This is wrong since there is still the delay between SONAR and the speakers that the driver itself introduces. SONAR knows what this delay is since it shows it to us in the Driver settings, however it doesn't add it to the delay it reports to the plugins when it should.
 
Regardless, when you look at just the difference between two instances of the PDC Info plugins, that should be the amount of new delay that just those sandwiched plugins introduce.
 
 
2. Realizing how different the guts' processing would affect the PDC, I am wondering if SONAR users could contribute to a listing of these "offenders."

 
That could be helpful.
 

Specific chain I am looking at:
   1. PDCInfo
   2. iZotope Nectar 2 Breath Control
   3. PDCInfo
   4. iZotope Nectar 2
   5. PDCInfo
 
Values with all 5 online -
   1. Output = 626.9ms
   3. Output = 2.7ms
   5. Output = 23.2ms
 
Now, I toggle off #2 in the SONAR Track FX bin (only Breath control), new values are -
   1. Output = 626.9ms (same)
   3. Output = 606.4ms (spiked dramatically, but still lower than #1?)
   5. Output = 626.9ms  (also spiked, now identical to #1?)
 
Basically, I am confused "why" and possibly not using this properly (nothing new there).

 
In theory the earlier outputs should be higher than the later outputs. I don't know why it isn't always the case. This is where some insights from someone from CW would be great! Seems we uncovered some mysteries once we took a look under the hood...
 

Quick Edit: I realized I had installed the new Saffire MixControl the other day, which defaulted to 512 sample buffer on me. I dropped it down to 96 and the above numbers are very similar (pretty much 2ms less across the board for both tests). Another interesting point is that PDC is identical for 32, 48, and 96 sample buffers, but spikes up .7ms at the 64 sample setting.... this may also have use to tweak buffer settings, since I found that odd, but consistent.



Yea it's hard to know what some plugins are doing, or why they are doing it. For instance I found out that LP-64 EQ adds exactly 100.0 ms delay. That sounds a bit coincidental. So my guess is that the actual delay it requires depends on its settings. So instead of telling the host a different delay each time you change its settings (and hence causing glitches), it just gives itself some headroom so that it presents a consistent 100 ms delay regardless of its settings (and adds some extra delay internally to get to exactly 100 ms overall). I won't be surprised if many plugins do something similar.
 
As for 32, 48, 96 buffer sizes... I would think the plugins have their own internal buffering so the input buffer sizes don't affect the actual delay they introduce. For instance a linear phase EQ requires a certain amount of samples to be present for its algorithm to work properly. So it can't rely on the input buffers being large enough and hence buffers it into larger sliding window buffers internally.
 
Chregg
its crashing sonar with me



Chris, sorry to hear that. I just took a VST3 sample plugin and made the least possible changes to display the PDC info, so I'm not sure why it is crashing for you. Does it crash the instant you add it, or at some other point?
2016/05/06 07:52:21
Chregg
the instance i add it, appear in fx bin then crash
2016/05/06 09:54:32
ChristopherM
Interesting. It's not obvious to me why on a chain such as PDC Info - LP MB - PDC Info, the Out readings on both instances of PDC Info change if LP MB is enabled or disabled (albeit the first changes only slightly).
 
Edit - I think I mean "later" when I say "first".
2016/05/06 09:58:39
ChristopherM
For those experiencing crashes, I assumed PDC Info was 64-bit and so I put in in \Program Files\Common Files\VST3\ although I did initially think about putting it in \Program Files (x86)\Common Files\VST3\ in case it was 32-bit. Where have you put it?
 
2016/05/06 10:05:35
LJB
Sadly, most of the Izotope plugs introduce insane amounts of delay. I disable them whenever I need to program or track anything. Cake's LP-Multiband  (previous version) is also a bit naughty..
2016/05/06 10:41:55
Keith Albright [Cakewalk]
SilkTone
  1. There is a bug in SONAR where it doesn't tell the plugin the input latency, only the output latency. AFAICT, the VST3 spec requires the host to tell the plugin both input and output latency, but unfortunately it looks like SONAR isn't implementing this correctly. Because of the missing input PDC value, things will look a bit backwards. So a PDC Info plugin at the start of an FX chain will show a higher PDC value than the instance at the end of the FX chain. This "output" PDC value is the time remaining until you will actually hear the signal (including the output driver's delay). 
Steven,
 
Useful utility.
Thanks for the report, we'll look into it.  
 
Keith
2016/05/06 11:06:47
garrigus
Nice. I'll pass this along to DigiFreq readers.
 
Scott

--
Scott R. Garrigus - http://www.garrigus.com
* Cakewalk SONAR Video Tutorials: https://www.youtube.com/u...gus?sub_confirmation=1
* Author of the Cakewalk Sonar and Sony Sound Forge Power book series: http://garrigus.com/?PowerBooks
* Publisher of the DigiFreq music recording newsletter: http://www.digifreq.com/
* Publisher of the NewTechReview consumer tech newsletter: http://www.newtechreview.com/
2016/05/06 11:23:22
bitflipper
I'm thinking SONAR applies PDC even for bypassed plugins, which is why you can (usually) enable and disable them on the fly without glitching. That could explain why the numbers don't change as you might expect them to when plugins are disabled.
2016/05/06 12:18:47
ChristopherM
Bitflipper - Rather, I think Sonar only recalculates PDC when you start the transport. If you enable or disable a plug whilst transport is running, there is no immediate re-calc (as you can see from the counters on PDC Info) but you do hear glitches occasionally, which is presumably to do with the change in DSP load or something.
 
Clarification - I therefore do not think that Sonar allows PDC for plugs that are disabled when the transport is started. (It's the end of a long week!)
 
© 2024 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account