Delaying the Audio Signal in Audio Samples
-
@aaronventure Thank you - what do those samples correspond to, though? If I have 48kHz samples, but the system is running at 44.1kHz (which I have no control over), then what is the duration of a (say) 4000 sample delay? (Is the context audio samples, or sample-rate?)
Also, isn't there a lot of unnecessary overhead in using Faust just to fill a buffer?
-
@clevername27 Whatever you want, I thought you didn't want ms? I think your audio samples in the sampler get resampled to the current system sampling rate. So if that's what you're delaying for, use the delay node with ms. It takes in a double, but it only displays one decimal (the issue I talked about before).
-
@aaronventure Thanks, man! That seems to be it, with the clutch being, "…your audio samples in the sampler get resampled to the current system sampling rate". (@Christoph-Hart, could pls verify? Then, we'll have it all on record in one tidy forum post!) Cheers, mates.
-
I highly suspect that this conversion is true.
The rest of hise and scriptnode is compensating for sample rate I have no reason to suspect that this would be different -
@griffinboy also that's how all other samplers work
-
@griffinboy @aaronventure So…let's say I want to delay the playback of a 48K sample precisely—let's say it's a specific zero-crossing point. If the plugin is running at 44.1 kHz (based on the DAW), will the sample still begin at the same (zero-crossing) point?
- If I pass the raw sample offset into HISE's API?
- If I pass the sample offset into ScriptNode's (or HISEScript's) conversion node/function?
It sounds like the answer is yes…?
Thanks, guys.
-
Okay now that depends on how the resampler works.
In general the zero crossing point will stay where it is. But resamplers that work based on smoothing / interpolating can definitely change the value and position of samples. I'd recommend doing tests to see how Hise deals with sample rate conversion: my guess is that it uses linear interpolation and will indeed change the zero crossings. Usually vsts recalculate from scratch if the program needs to know the positions of particular samples or points of interest. Zero crossing detection is pretty straightforward. Fancy sample rate conversion libraries would be needed to get a clean job straight off the bat, IDK if Hise uses them in their samplers. -
@griffinboy Makes sense. So if I'm using the delay to the sample's phase, the result will be very close, but not quite perfect?
-
Likely but I recommend testing this. Should be easy to test if you can render the audio files and analyse in an audio editor
-
@clevername27 sample offset works on the sampling rate of the file, otherwise it makes no sense.
The playback gets delayed by the sample offset in the original sampling rate, and then it gets resampled to the current engine/host sampling rate.
But you need to be controlling that offset in the sampler.
-
C clevername27 marked this topic as a question
-
C clevername27 has marked this topic as solved
-
@aaronventure @griffinboy Thanks, mates!
-
Ahh he is right! That is a detail I missed sorry. So yes, the sample number will always correspond to the original zero crossing sample. But there is a chance this sample will not be an exact zero crossing anymore if sample playback doesn't start from this exact sample.
