[SOLVED] Minute glitches in Predator x64 arpeggio when rendering to 88

[Edit: It seems that when raising my korg zero 4 samplerate to 96KHz the same glitch appears through realtime playback so it’s the Reaper in itself that doesn’t respond all that well to higher frequency rates like suggested by vV]

During my latest project noticed a glitch in how the Pretator VSTi plays an arpeggio line when rendered in high samplerate.
It’s pretty subtle and is kind of a hiccup in the first trigger of the first note of an 8step arpeggio that repeats for 7 bars.

When I play it back through ASIO it behaves normally but as soon as i render it in a song or the track soloed i hear the hiccup.

I usually render at 48KHz but I read a thread here on mastering and to finish off my project I tried for the 88.2 approach and subsequently ran into problems as the glitch is very evident during a quiet part before a drop in a Drum and Bass tune.

My solution for this has been to render it down to 44.1KHz which turned out to be flawless but I’m left wondering about that double samplerate. So I’m not really expecting a magic solution to the VSTi glitch as I have tried almost every option available to try and remedy it to no avail. But I’m left wondering if double the samplerate is really worth it in terms of the quality of the final product or if I can just “master” my tracks directly from Renoise in 44.1 with some VST’s on the main bus for “bedroom” mastering purpouses. 32 bits depth is what i consistently use and that has no detrimental effect on the resulting wav.

It depends on whether the vsti plug or the VST effect you pull its audio through can handle the 88Khz rate. Loads of plugs don’t go beyond the 48Khz frequency limit. There are plugins that support 96Khz, perhaps even more than 88Khz, but the majority of plugins supporting those frequency ranges i suspect are very rare. And as said, even if the instrument plugin supports it, you might be using an effect plugin on top of it that doesn’t support the frequency range, this also gives you artifacts.
Therefore output frequency must always be maximum frequency of lowest rate plugin.

Thanks for the answer and while i don’t suspect it to be the culprit here it is definitely something I need to be aware of in future productions.

I’m not saying I’m certain that it’s not the case here but the Trash2 VST that I’m using for the Predator is working fine with another synth in the same song. Also there is another instance of Predator that plays another arpeggio on the same channel as the one that glitches and is routed through the same Trash2 VST which is rendered without hiccup or glitch. But browsing of the manuals of the Predator and Trash2 and google hasn’t given me any definite information about supported samplerates.

It would be worth to note that the hiccup/artifact/glitch sounds like a quick dip in the volume(envelope?) of the first note being played without any other noticeable effect in the sound of the VST’s. I suspect it’s an undefinable ghost in the machine that is causing the annoyance.

Is there any way other than the software documentation of a VST to find out what samplerates they support?
And does it really matter if I don’t go any higher that 48KHz to render tracks for distribution?

Simply try it out by setting the frequency rate in the audiopreferences. If it sounds okay in realtime, i would expect it should sound okay when rendered.
If it doesn’t sound alright, you can try to isolate the culprit better as well because you can tinker with settings and setups in realtime.

Chances are at least big that whatever you render in a different frequency than what you use in realtime, will cause output differences. Doesn’t necessarily even need to be a bug, but audio is getting a different character because with the different frequency, stuff is either left out (when rendering lower frequency) or stuff is being put in (interpolated or otherwise added value from the VST plug).

I’ll tinker around a bit with that in mind and see what I can get out of it, thanks for the pointers and help.