Rendering of VST instruments

[Pollo]

Hi all,

I started using Reaper about half a year ago and so far I am quite enthusiastic about it. I invested quite some time in setting it up, made my own theme, programmed my own plugin to communicate with hardware controllers. Now it is time to start using it. I am working on a few projects already and the workflow is really good.

However, I did some tests the other day and the results got me a bit worried. I hope it's some user error and a simple setting in the preferences will resolve it.

What I did was create a track with one MIDI item of about 60 bars long. At the beginning of each bar I put one MIDI note, exactly on the first beat of the bar. Next I loaded a VST instrument on this track, in this case Stephen Slate Drum Sampler 4.0. The idea was to have that MIDI note trigger a percussive sound, with a clear attack. In this case I chose a HiHat sound which obeyed that requirement perfectly.
Next I rendered this track using the 'Render tracks to mono stem tracks (and mute originals)' option.

Then I zoomed in the stem track horizontally and vertically so I could see exactly where the rendered hits started. That's where I got worried because the hits don't line up where they should be. They move around in such a way that it looks as if they are always aligned with the beginning of the buffer. In fact, when I increased the ASIO buffer size to 1024 and rendered again I could clearly see that the position error increased with an equal amount. That means a hit could be as much as 1024 samples off from the position where it should be. At a sample rate of 44.1 KHz that's 23 milliseconds.

Surely I have misconfigured something and without a doubt Reaper is capable of sample acurate rendering of VST instruments, right? I mean, lesser DAW's seem to do this without a problem. It's not rocket science.
So can anybody point me in the right direction?

[famous beagle]

I'm interested in this because it sounds interesting. However, I must say, I've rendered VSTs probably hundreds and times and never noticed any audible issues whatsoever.

[Pollo]

If you usually work at low buffer settings then you will probably not notice it immediately. If you're a drummer you might.

But for me sample accurate rendering is such a basic and essential DAW pre-requisite that I can't believe Reaper doesn't provide it. So I'm still hoping I am overlooking something. But the silence is not reassuring.
Anybody?

[Pollo]

I realized there was a simple test I could do to see what was going on, namely to run Reaper in a debugger. It looks like Reaper is doing everything right.

So now I'm suspecting SSD itself. Not a happy customer of mister Slate right now, although I doubt he ever sets foot in these quarters to read this.

But I tested with a few other plugins as well, with the same results. Some big name plugins too.
So I'm still in doubt.

[Tod]

Originally Posted by Pollo

I realized there was a simple test I could do to see what was going on, namely to run Reaper in a debugger. It looks like Reaper is doing everything right.

So now I'm suspecting SSD itself. Not a happy customer of mister Slate right now, although I doubt he ever sets foot in these quarters to read this.

But I tested with a few other plugins as well, with the same results. Some big name plugins too.
So I'm still in doubt.

Hi Pollo, I've not seen this either, and I think I'd be aware of it if it had happened.

Maybe it's because the only way I render midi is in real time. Why don't you try that and see what happens.

And yes, if your using samples for a test like this you need to be very intimate with them, I've seen them well off the mark.

For a test like this it's best to just make a short sine wave sample at 1Khrz and then cut it in the front, right at the zero crossing. Of course you'll need to use a different VSTi player to play it back.

[Tod]

Originally Posted by Tod

For a test like this it's best to just make a short sine wave sample at 1Khrz and then cut it in the front, right at the zero crossing. Of course you'll need to use a different VSTi player to play it back.

Okay, you got my curiosity up so I thought I'd check it out.

I used a 1K sample like I mention above and loaded it into both Kontakt 5 and ReaSamplOmatic to test with.

I tested with both buffer settings of 256 and 1024.

I rendered in real time recording to the outputs of the samplers and in all rendered tests, the audio ended up absolutely perfectly aligned with the midi notes.

[msmucr]

I can also report, I haven't experienced any problem with time accuracy of rendered VST instruments. Although I use percussion virtual instruments very sparingly and usually just as raw rhythmic tracks without extra fiddling. I can definitely tell, that Rayzoon Jamstix, ReaSamplOmatic5000, free MT Power Drums and previously also Toontrack EZDrummer 1 are all fine. Same applies to melodic instruments, which will has to use same principle.
No shifts regardless of buffer size.
Are you sure that there isn't any built-in humanization (its calculated parameters can somehow interact with processing block size) isn't turned on in your Slate VSTi? (just thought, i've never use it)

Michal

[Pollo]

Originally Posted by Tod

Okay, you got my curiosity up so I thought I'd check it out.

I used a 1K sample like I mention above and loaded it into both Kontakt 5 and ReaSamplOmatic to test with.

I tested with both buffer settings of 256 and 1024.

I rendered in real time recording to the outputs of the samplers and in all rendered tests, the audio ended up absolutely perfectly aligned with the midi notes.

Maybe needless to say but you have to zoom in really deep to see these differences. What I do is I set the timeline to samples and then zoom in until the difference between two adjacent marks is exactly the number of samples of one buffer (I mean the marks that actually show the number of samples, not the ticks in between).

Furthermore I also tested with ReaSynDr and it alligns sample accurate. But since that is not a VST plugin I wasn't sure whether the problem was maybe something specific to the VST format.

I agree that it is not always easy to see where a sample starts. That's why I used a percussive sound. But given the fact that the error occurs in a completely regular, cyclic pattern, I concluded that it was related to the buffer size. Which was further confirmed by the fact the error increased when I increased the buffer size, again in a completely predictible way.

[Pollo]

Originally Posted by msmucr

I can also report, I haven't experienced any problem with time accuracy of rendered VST instruments. Although I use percussion virtual instruments very sparingly and usually just as raw rhythmic tracks without extra fiddling. I can definitely tell, that Rayzoon Jamstix, ReaSamplOmatic5000, free MT Power Drums and previously also Toontrack EZDrummer 1 are all fine. Same applies to melodic instruments, which will has to use same principle.
No shifts regardless of buffer size.
Are you sure that there isn't any built-in humanization (its calculated parameters can somehow interact with processing block size) isn't turned on in your Slate VSTi? (just thought, i've never use it)

Michal

Definitely no humanization. The plugin doesn't have that.

I also tested with a few melodic instruments which all of them showed the same problem. One of them was Pianoteq, of which I absolutely would not expect this. I have to test it further. Will report back.

[The Telenator]

If you are only SEEING an apparent misalignment and not actually HEARING it, then I suggest to you that it is not happening -- that is, it's only the graphics and not an actual mis-render.

DAWs are not all that accurate in the graphics department. They just came out of the Stone Age as far as GUIs are concerned.


So ... I would ask: Anybody actual hearing the track(s) off by X samples or can make it show up on a scope zoomed in? 'Cause if nobody hears it, it ain't there.


Had to ask, because all the posts I'm reading here are all about "I see this" and "I see that", nothing about, "Man, this sounds messed up!"

[famous beagle]

Originally Posted by The Telenator

If you are only SEEING an apparent misalignment and not actually HEARING it, then I suggest to you that it is not happening -- that is, it's only the graphics and not an actual mis-render.

DAWs are not all that accurate in the graphics department. They just came out of the Stone Age as far as GUIs are concerned.


So ... I would ask: Anybody actual hearing the track(s) off by X samples or can make it show up on a scope zoomed in? 'Cause if nobody hears it, it ain't there.


Had to ask, because all the posts I'm reading here are all about "I see this" and "I see that", nothing about, "Man, this sounds messed up!"

Exactly what I was thinking. I've rendered tons of MIDI instruments in Reaper and never noticed anything. I don't know whether I'd notice 26 ms or not, though. I dunno.

[Tod]

Originally Posted by Pollo

Maybe needless to say but you have to zoom in really deep to see these differences.

Humm, not sure what your after here Pollo, this is as deep as it gets whether you've got the time line set to samples or not.



Maybe there's something else going on with your system?

[Pollo]

Originally Posted by The Telenator

If you are only SEEING an apparent misalignment and not actually HEARING it, then I suggest to you that it is not happening -- that is, it's only the graphics and not an actual mis-render.

DAWs are not all that accurate in the graphics department. They just came out of the Stone Age as far as GUIs are concerned.


So ... I would ask: Anybody actual hearing the track(s) off by X samples or can make it show up on a scope zoomed in? 'Cause if nobody hears it, it ain't there.


Had to ask, because all the posts I'm reading here are all about "I see this" and "I see that", nothing about, "Man, this sounds messed up!"

Well, this is going to be difficult to explain but I think the nature of the problem might not be always hearable, but all the while still be there.
At this moment in my timezone it is too late to go into that now. I will explain tomorrow.

I don't believe it's a graphic glitch. But to make sure I will examine the rendered file in another tool. Tomorrow.
BTW, if it's a graphics problem then ReaSynDr would not allign perfectly, would it?

[Time Waster]

Originally Posted by Pollo

Hi all,

.... in this case Stephen Slate Drum Sampler 4.0.

Have you tried with another VSTi as a double check? I have found that some VSTi's don't render properly.

[KevinW]

Assuming we're doing this with a VST that doesn't change the sample randomly, should the rendered audio null with the midi/vst output if you invert the polarity on one channel?

I tried it with Addictive drums and SampleTank 2.5 (no round robin), and it did not null.

However, when I rendered at different buffer sizes, then inverted the polarity of one of those tracks, AD did not null, but ST did.

So, it seems to me that playback of the VSTi does not directly align with the rendered output, but the rendered output does not change with buffer size.

I also played around with the "preserve PDC monitoring..." setting (something that has always confused me) but that seemed to have no effect on this experiment.

I would be interested to know from some of the folks who believe the rendered output matches the midi file - if you invert the polarity of the midi track, does it null with the rendered track?

[somebodyelseuk]

Does the sample file have X ms of nothing at the front?
... how long is the 'build up' to the hit peak? Guessing you want the peak to line up, right.

[Pollo]

Originally Posted by Tod

Humm, not sure what your after here Pollo, this is as deep as it gets whether you've got the time line set to samples or not.



Maybe there's something else going on with your system?

That's deep enough alright .

But, in case you're checking something that is NOT rendered correctly, this would be TOO deep, because you will need a lot of scrolling to find where the actual sample starts!

[Joaquins Void]

It sounds like the VSTi is not responding to the delta time property of vst midi events, IE where in the current buffer the event should occur.

Reaper could be mangling the deltas too, but I think I would have noticed... But you never know, other hosts have screwed this up without anyone noticing for a long time.

Anyway. The definitive test is to setup a usually reliable instrument with a short noiseburst or hihat, and have it play a line of 64:th notes. Set a large ASIO buffer. Then gradually increase the tempo. If the sound impulses are not evenly spaced you'll hear it easily. If all is well, they'll form a steady tone at high tempos.
I'll do this when I get home.

[Joaquins Void]

OK, did some testing. Reaper seems to be generating delta times just fine, which indicates that the OPs VSTi doesn't handle them right.

[Banned]

Originally Posted by Joaquins Void

It sounds like the VSTi is not responding to the delta time property of vst midi events, IE where in the current buffer the event should occur.

^ This. Report as bug / FR to plug-in developer.

PS: @OP: de groeten aan Mokum! Drink nu een lekker bakkie koffie uit "Los Pollos Hermanos" mok.

[KevinW]

Could someone please comment on the null test, as I mentioned in post 15 above?

[Pollo]

Originally Posted by Joaquins Void

OK, did some testing. Reaper seems to be generating delta times just fine, which indicates that the OPs VSTi doesn't handle them right.

Well, that's what I thought initially as well. Did some more testing today and I'm not so sure anymore.
I was plaaning to write a long post about how VSTi's render MIDI data and delta frames and such, but since you seem to know about that already I will just share my findings with you.

As I mentioned in my earlier post I ran Reaper in a debugger and verified that delta frames were indeed reported to the plugin. I wrote a few VST plugins in the past and I just used one of them to be able to do source code debugging.
Today I did the same experiment again, this time to verify that the reported delta frames were actually correct. They don't seem to be.

To explain why I think that, I need a bit of calculation. I hope you don't mind.

My project tempo is set at 120 BPM. Samplerate is 44.1 KHz. Buffer size is 1024 samples. At 120 BPM we have 2 beats per second. 1 Second is 44100 samples so the time between two beats should be 22050 samples.
My MIDI notes are exactly on the beat so I expect them to be 22050 samples apart. 22050 samples divided by 1024 samples of one buffer gives us 21 full buffers plus a remainder of 546 samples.
So what I would expect is the delta frame of the second MIDI note to be 546 samples more than the first, modulo 1024.
If you don't agree with this calculation, please let me know. We all make mistakes and I'm no exception.

Running the first 6 notes in the debugger I get the following delta frames: 0, 68, 136, 204, 272, 340. As you can see they are 68 samples apart. Not what I expected. Something is not right here.

I went back to my renderings of the SSD output and counted the error in the position. Lo and behold, the rendered output shifts to the left by exactly 68 samples each beat, until the error becomes more than one buffer and then it snaps back.

Now I haven't thought this through completely but my intuition says that this indicates that the problem is with Reaper and not with SSD.
Please let me know what you think of it.

[Pollo]

Originally Posted by Banned

Drink nu een lekker bakkie koffie uit "Los Pollos Hermanos" mok.

I tried but they keep breaking badly.

[Joaquins Void]

Originally Posted by Pollo

Well, that's what I thought initially as well. Did some more testing today and I'm not so sure anymore...

Well, the math should work out, like you did it.
But one thing that comes to mind is that the host is allowed to subdivide buffers arbitrarily, so in order to be certain we'd need some kind of logging of buffer sizes to compare against.

Either way, the 64th test is pretty definitive. I've repeated it a few times now and examined the output and as far as I can tell it's perfect.

But your numbers look odd, I'll give you that. There should be some kind off logging VST out there, so we can take a look at the buffer sizes.

[Tod]

Originally Posted by KevinW

Assuming we're doing this with a VST that doesn't change the sample randomly, should the rendered audio null with the midi/vst output if you invert the polarity on one channel?

I tried it with Addictive drums and SampleTank 2.5 (no round robin), and it did not null.

However, when I rendered at different buffer sizes, then inverted the polarity of one of those tracks, AD did not null, but ST did.

So, it seems to me that playback of the VSTi does not directly align with the rendered output, but the rendered output does not change with buffer size.

I also played around with the "preserve PDC monitoring..." setting (something that has always confused me) but that seemed to have no effect on this experiment.

I would be interested to know from some of the folks who believe the rendered output matches the midi file - if you invert the polarity of the midi track, does it null with the rendered track?

Hi Kevin, I'll see if I can find some time today to do this.

I tried it with Addictive drums and SampleTank 2.5 (no round robin), and it did not null.

However, when I rendered at different buffer sizes, then inverted the polarity of one of those tracks, AD did not null, but ST did.

I'm a little dubious about using a commercial drum library to do this because it's almost impossible to know exactly whats under the hood.

If I loaded one sample of a Hi-Hat into RS5K or Kontakt and played it for 16 bars at 120BPM, would that work for your experiment? How exactly would you like me to make this test?

[Pollo]

Originally Posted by Joaquins Void

Well, the math should work out, like you did it.
But one thing that comes to mind is that the host is allowed to subdivide buffers arbitrarily, so in order to be certain we'd need some kind of logging of buffer sizes to compare against.

Either way, the 64th test is pretty definitive. I've repeated it a few times now and examined the output and as far as I can tell it's perfect.

But your numbers look odd, I'll give you that. There should be some kind off logging VST out there, so we can take a look at the buffer sizes.

Which is VST instrument did you use for your test?
Like I said before, ReaSynDr alligns perfectly.

Good point about the buffer subdivision. I will check that right now.

[Pollo]

Ok. My bad. I made a stupid mistake. I thought I had put a MIDI note on each beat in my test project. Turns out out it's every two beats.
So then it works out just fine. That's twice 546 samples = 1092. Modulo 1024 leaves 68.
Phew! Reaper is doing everything right. So then it can only be the VSTi's themselves.

At least now I know where to complain.

[whiteaxxxe]

Originally Posted by Pollo

I tried but they keep breaking badly.

report that mug/bug to the complaints-department in Albuquerque. Saul Goodman handles such things. but he will tell you that that is the natural result of Heisenbergs uncertainty principle.

[Joaquins Void]

I have tested Korg Wavestation, Dune CM, ReaSamplomatic5000 and MT-Powerdrumkit that I discovered here the other day. Dune CM was the most suspect, but I think it may have some subtle randomization going on.

There could be something off about the BPM setting though. If so, the 64th notes at 200 BPM would still be steady, but figuring out the buffer alignments would be impossible. I'll render something at 120 and have a look. (Wavosaur is great for this kind of thing if you set the ruler to samples rather than seconds.)

Edit >
Nope. The BPM is perfect too.

[Pollo]

Originally Posted by whiteaxxxe

report that mug/bug to the complaints-department in Albuquerque. Saul Goodman handles such things. but he will tell you that that is the natural result of Heisenbergs uncertainty principle.

Not Now. I'm playing dice with Albert and he's losing.

[Pollo]

Originally Posted by KevinW

Could someone please comment on the null test, as I mentioned in post 15 above?

I think there is no difference between a plugin being rendered and a plugin that plays back (non-realtime) MIDI. So yes, the two should null if one is inverted, on the condition that the plugin always plays the sound in exactly the same way.
That is not always the case. A sampler might alternate between different versions of a sample (or is that what you mean by round-robin?). In that case obviously they won't null.

[Tod]

Originally Posted by KevinW

Could someone please comment on the null test, as I mentioned in post 15 above?

Okay, I loaded one Hi-Hat_tight sample into both Kontakt 5 and RS5K. My NUL tests were between the VSTi output track and the rendered midi audio tracks.

I tried a lot of different settings rendering the midi but the best I could get for the NUL test is -144db. That was with both Kontakt and RS5K set at 0% Velocity Intensity.

Something else I found a little strange is that I only got -144db if I started playback at the exact position I started the rendering. If I moved the cursor back even just a little bit, the test would be more like -109db to -107db.

Heh heh, on the other hand, if I NUL tested two of the rendered audio tracks, it NULed perfectly.

[Pollo]

Originally Posted by Tod

Okay, I loaded one Hi-Hat_tight sample into both Kontakt 5 and RS5K. My NUL tests were between the VSTi output track and the rendered midi audio tracks.

I tried a lot of different settings rendering the midi but the best I could get for the NUL test is -144db. That was with both Kontakt and RS5K set at 0% Velocity Intensity.

Something else I found a little strange is that I only got -144db if I started playback at the exact position I started the rendering. If I moved the cursor back even just a little bit, the test would be more like -109db to -107db.

Heh heh, on the other hand, if I NUL tested two of the rendered audio tracks, it NULed perfectly.

Hm. Don't fully understand your results. But -144 dB is exactly 24 bit resolution. Maybe there is dithering going on in those plugins?

[Tod]

Originally Posted by Pollo

Hm. Don't fully understand your results. But -144 dB is exactly 24 bit resolution. Maybe there is dithering going on in those plugins?

Hi Pollo, it seems you have some knowledge of all this so maybe you can explain why -144db is exactly 24 bit resolution? Or is that the lowest it will go before it hits -INF?

As far as dithering in Kontakt or RS5K, I'd say it's so unlikely that we can safely say no.

As far as the tests I made, I varied the velocity of the Hat hits from 127, down to near 1 and then back up again. I did this about 3 or 4 times over the course of 8 measures at 120BPM using 16th notes. This was to see if Velocity Intensity would have anything to do with it, and indeed it does, because with Velocity Intensity set to 60% in Kontakt, the NUL test yielded -107db. As soon as I set the Velocity Intensity to 0% it went to -144db.

Actually -107db is still not too bad. It's obvious we're probably all perfectionist here, me included, but sometimes that can get in the way of practicality. I know for myself that's true.

[KevinW]

Originally Posted by Tod

Okay, I loaded one Hi-Hat_tight sample into both Kontakt 5 and RS5K. My NUL tests were between the VSTi output track and the rendered midi audio tracks.

I tried a lot of different settings rendering the midi but the best I could get for the NUL test is -144db. That was with both Kontakt and RS5K set at 0% Velocity Intensity.

Something else I found a little strange is that I only got -144db if I started playback at the exact position I started the rendering. If I moved the cursor back even just a little bit, the test would be more like -109db to -107db.

Heh heh, on the other hand, if I NUL tested two of the rendered audio tracks, it NULed perfectly.

That's interesting, and much different from what I got. Playing the rendered audio along with the inverted midi gave me an obvious, phasey, out of alignment sound. Playing the two rendered audio tracks (rendered at different buffer sizes) nulled to nothing as far as I can tell.
I'll play around a little more this weekend. I'm not overly concerned about it, but it is something for me to be aware of.

[Tod]

Originally Posted by KevinW

That's interesting, and much different from what I got. Playing the rendered audio along with the inverted midi gave me an obvious, phasey, out of alignment sound.

Yeah, that didn't happen with me and at -107db I'm not going to turn up my studio monitors so I can hear it.

And yes, the rendered audio tracks seemed to NUL perfectly.

[Banned]

Originally Posted by Tod

Hi Pollo, it seems you have some knowledge of all this so maybe you can explain why -144db is exactly 24 bit resolution? Or is that the lowest it will go before it hits -INF? [...]

Each bit is a binary (0 or 1) representation of "no" or "yes". In this case the bits stand for the successive answers to a series of successive questions: should I halve the value (volume, amplitude) one more time, or not? Half of the maximal volume = -6dBFS. Half of that is -12dBFS. Half of that is -18dB, and so on.

For 24 bits, you can do that 24 times, and 24 times 6 is 144. So the lowest possible value is -144dBFS.

Does that make sense?

[Tod]

Originally Posted by Banned

Each bit is a binary (0 or 1) representation of "no" or "yes". In this case the bits stand for the successive answers to a series of successive questions: should I halve the value (volume, amplitude) one more time, or not? Half of the maximal volume = -6dBFS. Half of that is -12dBFS. Half of that is -18dB, and so on.

For 24 bits, you can do that 24 times, and 24 times 6 is 144. So the lowest possible value is -144dBFS.

Does that make sense?

Okay, thanks Banned, yes it does.