View Single Post
Old 06-25-2015, 04:27 PM   #30
Human being with feelings
Tale's Avatar
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,057

Alright then, I will give it one more try.

Originally Posted by mviljamaa View Post

What causes this? Like what's the reasoning behind having it work that way and not based on now many nFrames got in.
In most hosts, after you add your plug-in to a track, the host immediately starts calling your ProcessDoubleReplacing(), and will keep on doing so until you remove your plug-in again. If the track is empty, or if you are currently not playing back anything, then the input will be all zeros (silence), but your plug-in will nevertheless be processing it.

When you start playback, or when you render/freeze a track, then your plug-in will most likely already have processed a couple of hundreds or more sample blocks. Most host will likely start playback at the beginnng of an audio buffer, but because the host doesn't know that your plug-in is rebuffering, let alone what your internal buffer size is, it is unlikely that it begins playback exactly at the beginnng of your block size.

However, if you make sure you start playback at the beginning of your audio item, and you reset your queues when playback starts, then playback will start at the beginnng of your block size. "Problem" solved!

Originally Posted by mviljamaa View Post
It's odd why this happens and it may cause problems at same later time. Is it a feature of the VST SDK then? If I'd want the Hamming process to align precisely, then how'd I do it. I wouldn't do it?
I guess you would have to track the input waveform somehow, and e.g. reset your queues at the first zero-crossing or whatever. But this can be troublesome when your audio input isn't a pure sine wave...

Anyhow, have I already mentioned that exact alignment doesn't matter for FFT and alike?
Tale is offline   Reply With Quote