From the original SynthMaker forum (2004–2014), with its members’ names and dates.
aliasant ·
If I load my plug (in reaper) and it has a 10ms look ahead and then rendfer a track with that setting the new track will be aligned with the old one but if I change the look ahead to something else, lets say 0 ms the new rendered track will end up 10ms ahead of the original track.
It seems to me that the Delay Comp only reports the delay in samples when the plugin loads.
Can anyone confirm?
TomC ·
aliasant wrote: If I load my plug (in reaper) and it has a 10ms look ahead and then rendfer a track with that setting the new track will be aligned with the old one but if I change the look ahead to something else, lets say 0 ms the new rendered track will end up 10ms ahead of the original track.
It seems to me that the Delay Comp only reports the delay in samples when the plugin loads.
Can anyone confirm?
That's how the VST-API is designed, the delay time gets only reported to the host on start-up (of the plug-in).
Annoyed me to death, but that's how it is.
Tom
aliasant ·
Crap !
That is really bad. Thanx for the info though.
TomC ·
aliasant wrote: Crap !
That is really bad. Thanx for the info though.
Yep. But if your plug-in doesn't have toooooo long delay times just report the longest possible time to the host and adjust your internal delaying accordingly (means if the longest possible delay is 20ms, and you just need 10ms to do your computing, add another 10ms), so you'll be always on the save side.
Tom
aliasant ·
I think the problem is when the user starts bouncing/rendering tracks If my plug on channel 1 is saved with preset 4 that has a 4 ms look ahead and the user makes a change to it before bounce that track will go offset to all the other tracks. Shit Im bad at explaining. Hope you understand what i mean. He might get phase problems and what nots. It will be very hard for the user to understand why.
TomC ·
aliasant wrote: I think the problem is when the user starts bouncing/rendering tracks If my plug on channel 1 is saved with preset 4 that has a 4 ms look ahead and the user makes a change to it before bounce that track will go offset to all the other tracks. Shit Im bad at explaining. Hope you understand what i mean. He might get phase problems and what nots. It will be very hard for the user to understand why.
No problem: let's say your plug-in can do look-ahead from 0 to 10 ms, that means it introduces a delay of 0-10 ms.
For ease of understanding lets assume one ms would be 1 sample (of course you have to compute the number of samples according to your current sample rate).
Build a chain of 10 of the 1-sample-delay primitives. Build a kind of routing matrix with selectors or so.
- report always a delay of 10 to the host program - if your plug-in is set to 10 ms, by-pass the delays-chain - if it's set to 9, route the signal to 1 of the delay primitives - if it's set to 8, route it through 2 of the delay primitives ... ... - if it's set to 0, route it through all 10 of the delay primitives
This way, you always get the exact same delay which you can report to the host, so different settings doesn't change anything outside your plug-in.
Tom
Andrew J ·
...or use a delay by n samples and send it the appropriate value of n. This will depend on the sampling rate of course.
I've found with one of my works-in-progress that catering for 192kHz would mean that I'd have to report a PDC of ~22000 samples. That means that anyone running at 44.1kHz would have a half second latency. Even though the plugs are targetted at mix-down, that's way too long for my liking 😠
My options are to:
A) ignore PDC when it doesn't matter too much B) produce different versions of the plugin for 44.1/48, 96 & 192kHz C) provide a separate plugin to do the PDC if the user really wants it D) find another algorithm which doesn't need so many samples to do it's work
A bit of a thorny problem that's meant I haven't made much progress on that plug in over a year (must finish it off!).
TomC ·
Andrew J wrote: ...or use a delay by n samples and send it the appropriate value of n. This will depend on the sampling rate of course.
Yeah, forgot that this one does exist 😊
I've found with one of my works-in-progress that catering for 192kHz would mean that I'd have to report a PDC of ~22000 samples. That means that anyone running at 44.1kHz would have a half second latency. Even though the plugs are targetted at mix-down, that's way too long for my liking 😠
Huh? If you need 22000@192kHz 5500@48kHz should do the same job. Or do you really need all those 22000 samples independent of the sample rate? If so see below.
My options are to:
A) ignore PDC when it doesn't matter too much B) produce different versions of the plugin for 44.1/48, 96 & 192kHz C) provide a separate plugin to do the PDC if the user really wants it D) find another algorithm which doesn't need so many samples to do it's work
A bit of a thorny problem that's meant I haven't made much progress on that plug in over a year (must finish it off!).
B) is done by some people, so it's not unusual for the user. But it's not a elegant solution, though.
D) is always an option 🙂
E) in some cases it's not THAT important to offer a constant delay in time, e.g. I've build a compressor which always does 0 to 4410 samples look-ahead. In a 44.1 kHz environment that's 100 ms, at higher samples rates less. Of course if you transfer an existing project to a different sample rate you'd have to adjust the look-ahead settings, but in most cases that's no problem at all. I've never change the sample rate DURING a project, only before or after.
Tom
Andrew J ·
TomC wrote: Huh? If you need 22000@192kHz 5500@48kHz should do the same job. Or do you really need all those 22000 samples independent of the sample rate?
No, less samples are needed at the higher sample rates. But the PDC has to compensate for the longest possible delay that the plugin could experience. So if I want it to cater for use at 192kHz, then I have to be able to compensate for 22000 even if I'm running at 48kHz and only need 5500.
Wait a sec, you're probably thinking just calculate the required PDC dependent on sample rate at load time. Duh, I forgot about that option! The only issue with that is if user happens to change the sample rate in their project. But it should be OK next time the project is loaded anyway. Probably a much smaller problem than all the others.
Geez my thinking can get stale sometimes!
Andrew J ·
Just while I think of it, the other issue with catering for higher sample rates is keeping delay buffers etc. in code big enough (these can't be set at load time).
aliasant ·
I did change my algos so instead of needing 10 ms it now needs 3 ms and I can live with that. Maybe I just fix it a 3 ms. Not sure yet.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker