VST's in Host - not very responsive

I’ve just bought host and loaded up a couple of my favourite filter VSTs into it. FilterFreak and Arturia SEM.

When I send a short, snappy envelope to the cutoff frequency of both plugins I get a very sluggish response, with a long tail and no snap. Even on a 40ms decay AR envelope.

If I send the same envelope to a VCV rack native filter, it sounds great. Exactly how I expect it to.

Is there something about the VST format within host that prevents these snappy responses or is there something I can try to get it working better? Thank you.

Host does introduce some latency so probably not ideal if you are looking for a snappy filter response. Particularly if you are using the same envelope for the VCA (which would not have latency)

Might also have something to do with the CV to midi conversion I guess.

tbh a filter is probably the last kind of tool I would use in Host in this context. Great for FX like reverb though.

1 Like

Thank you for your reply. You are of course right. I just want to get CV control of everything, now I’ve got VCV rack in Ableton.

Seems to be the same for VST3’s. Bit of a shame in my opinion. It would really open up the functionality of the VST’s if they could be modulated more precisely.

If anyone knows the technical reason behind this, I’d be very interested.

I don’t know much about it - does the responsiveness change, if you change the block size in the Right-Click menu of HOST-FX?

I don’t know for a fact - but guessing that the VST parameters get converted/transfered in some sequence with the audio blocks. Only the devs of this fine closed source module knows what latencies and rates to expect.

This is one of the things that people who love host need to be aware of. If you are running a VI in there, you better take into account that there will be a delay. Luckily the VCV manual is very explicit about this:

"Block size While Rack modules process each sample one-by-one, VST plugins must process blocks of samples in bulk. Because of this, VCV Host waits until the block is filled before requesting the VST plugin to process audio. Lower block sizes result in lower latency but force the plugin to process more often, which consumes more CPU.

If you wish to change the block size, right-click on the panel of Host. The default size is 128 samples (2.9ms @ 44.1kHz), which is a reasonable balance of CPU and latency. The minimum block size is 16 (0.4ms), which consumes lots of CPU but has very small latency, and the maximum is 4096 (93ms), which is light on CPU but has very noticeable latency."

3 Likes

I think the problem here might be the smoothing that the VST itself applies. Most VSTs smoothe out parameter automations, in some you can adjust or disable the smoothing.

To check that out you could try a plugin that doesn’t have smoothing, two that come to mind are Charlatan and OB.XD, last time I checked they didn’t have any smoothing and could be automated very snappy.

2 Likes

Thank you so much for all these replies. In addition to wanting this to work, I find this to be a super interesting topic.

The default block size seems to be 128 samples. Reducing it seems to make a very small audible difference. Increasing it to maximum makes a big difference, so it clearly has some effect.

I think the VST parameter smoothing is the cause. I had not heard of this before. Seems like it’s implemented to prevent midi dropouts when parameters are routed to external physical controls. When automating controls inside the DAW, it’s actually counterproductive, as the control signal is continuous and the automation could be more accurate.

The option to turn this off would be an excellent feature in plugins, now we’ve entered the era of internal CV control. Thank you @Schabbes I will try those plugins you mentioned and report back with my findings.

1 Like

Just checked again myself… with Charlatan on the smallest buffer size it seems to work best.

But I’m surprised that the buffer size has a huge effect as well - I thought the buffer just get’s filled up and passed on, but it seems that automation is only read once per buffer.

1 Like

I know that VST2 did not allow for automation to be spread out through the buffer. VST3 allows it by time-stamping the automation data, but I think it’s up to individual plugins if they respect that or not. I’m not sure about that.

In my mind, in a straight DAW workflow you wouldn’t tend to patch fast stuff through the modulation. But of course in VCV you expect to do that kind of thing all the time.

So… Interesting question?

1 Like

That is correct; VST2 automation comes without timestamps. Up to the plugin. Most assume the value given is either a start of block or an end of block and smooth value.

VST3 and CLAP and (I think but am not sure, in some configuraitons LV2) allow automation to be sample accurate. But those sample still live within a block and since rack isn’t block based even if it used sample accurate VST3 automation (and I don’t know if it does) you would have a block worth of latency. In a DAW where you calculate entire blocks at a time and have latency compensation in the API this isn’t a problem, but then of course you don’t get all the fun feedback you can make in rack. The bigger frameworks - especially JUCE - don’t pass along this sample accurate VST3 automation though and many plugins don’t both to implement it, especially with the complexity of the VST3 api. CLAP is easier in this regard. Of course hosts have to send sample accurate automation also. Many do not.

For something like a filter sweep, using a VST with a block worth of delay would be really noticeable. For an instrument starting the sound chain you are probably OK if you set your block size low and don’t do super detailed external automation. A tightly timed delay would be tricky also - those 128 samples can really change the delay time.

Of course, module developers grapple with this too. You can’t do everything every step in every case so there’s strategies for rack also.

Hope that helps.

1 Like

Well, we grapple with like a 4, 8, or 16 sample latency. Rarely more. I always processed modulation at fs/4. I think most ppl process everything at sample rate. Andrew was horrified that my demo VCO repo processed CV at fs/4.

Unless the VST applied parameter smoothing (low pass filter)? Do you know if that is commonly done, or if Host does it?

To answer your questions: All good VSTs have a smoothing strategy over the block of some form, yes.

But that’s not the relevant question in the comment you highlighted. There’s two things

  1. sample accuracy and smoothing
  2. latency

the thing you get in rack is both; it has to fill up a block before it processes then it spools the block out later and that’s what would hurt you more, no matter how much you smooth.

So compare what a DAW does (upstream fills a block; then filter calculates the block, then that’s the block) with what Rack has to do (upstream fills a block with filter doing nothing; then hands that block to filter and gets the output) and you can see what you get is both an in-block inaccuracy of the parameter and an uncompensated latency due to the block-vs-sample. (This is why we did so much work to make surge run at block size 8 rather than 32 internally for the rack modules).

In DAW land your plugin can advertise a latency so if, say, you need a 64 buffer look ahead you say so and the daw compensates and keeps everything in line (unless you are playing live). Rack has no such option.

I’m not criticizing the rack choice - it’s why we can do all the lovely feedback tricks we do for instance, if you know how to compensate for the single sample delays - but it does make it a pretty chunky mismatch with block based effects.

2 Likes

Sure, obviously I get that. But why does that mean a filter sweep won’t work?

Sure it will be a buffer late, just like everything is a buffer late. That can cause a lot of issues, I don’t deny. I know how plugin latency compensation works in DAWs, and that it can’t work for host.

Sure. If you think your filter sweep being 128 samples late isn’t a problem, then you are correct, there isn’t a problem.

Three milliseconds? sounds like it might be ok. On my setup I also tend to use smaller block sizes. But, in any case, certainly agree you need to be aware of this issue, and some things won’t work at all.

I used to use this delay argument as one reason ppl might want to use my native SFZ Player, rather than using Spitfire in Host.

yeah for a slow sweep it would be as long as you don’t re-mix the original signal and are doing super careful phase stuff, but i figure with the one sample delays everywhere folks don’t really do that in rack land anyway.

for doing something like a snappy attack shaping or a tempo synced pulse it would be more annoying no doubt, especially if the VST uses the control as the end of the block.

but basically: if you use host you need to think about this, and if you have, like, 4 vst fx in a row you have to think about it early.

1 Like