Yes, 16 buffer size is within ioStation24C settings - when running inside Studio One, there's also a 'native zero latency' mode, which claws back a lot of latency.

Maybe not all hardware external audio units offer it - but I like this combination of Presonus Studio One and the Presonus ioStation24C.. really good combinations of sample rates and latency etc. without getting into extra expensive hardware.

The EQ is Eventide "SplitEQ" (*which is a beast, separating processing of transients and body - and allowing 'panning' of transients and body across 6 bands (8 incl. the 2 L/R shelves) - effective - but it carries a lot of latency.

But, I've found I get right to my desired latency for playing Piano by enabling the ioStation24C's fastest settings, plus its native 'zero latency' mode at the master bus (Studio One and ioStation24C are Presonus products, so this latency killer is a proprietary hook-up - probably breaking some norms).

Normally, I like a bit of latency when playing Pianoteq in standalone mode - enough to 'feel' like a real piano (setting higher buffer etc. 'to feel').

But with ways to claw back latency with a good external audio unit, plus something like the DAW Studio One's native zero latency mode, you can add various plugins (or sometimes just 1 heavy latency one like that actually pretty wonderful Eventide EQ).

Somehow, 16 is faster in this setup!?

(higher seems to get back to 'too much latency with this EQ') in the above setup here - but as a rule, probably without other proprietary zero-mode things involved maybe?, 32 or 64 likely behaves as expected - esp. if not trying to nullify a heavy plugin latency effect.

On that note.. I thought, surely setting to 44.1kHz would improve latency also.. however, with the above setup, (probably again, hardware + DAW having that proprietary zero latency loop), it's faster using 48kHz but with 64bit precision (rather than 32 or 24 - go figure!?).

But, if latency is a problem, certainly consider an external unit like ioStation24C which has some interesting capabilities, and the native features which may be available when that hardware is hooked up for the DAW - very useful. Presonus stuff kind of surprises me every so often in this way.

Maybe others here have low latency hardware/software combos which kind of help zero out concerns with latency too.

(I fussed to get the lowest latency with that EQ - and, had to bust through a lot of long-held conceptions about 'what the numbers should do' - and I'm glad I tried higher sample rates, and crazy low buffer etc.. the zero latency mode in Studio One with their native hardware.. killer stuff.)

Having read up a bit on this (https://www.soundonsound.com/techniques...ow-latency), it seems some of the claims made are a little misleading. E.g. hardware monitoring for ultimate low latency performance is available on most interfaces with a dedicated DSP but has no bearing on playing soft synths. Also, it appears Studio One uses double buffering and merely setting the "block size" results in different cumulative latency values from what you'd expect in many other DAWs. Fortunately, it displays the total (post midi input and pre speaker output) latency in the bottom right corner of the "processes" audio driver settings screen. This shows a significant difference/increase over the mere block size.

There are also significant limitations on which plugins you can use on "live" channels; they can't add more than 3ms latency (132 samples at 44.1KHz).

Altogether I think this is just different labeling and results in values similar to other DAWs with decent audio interfaces. Most DAWs these days have a "low latency" mode for live channels too.

Maybe not all hardware external audio units offer it - but I like this combination of Presonus Studio One and the Presonus ioStation24C.. really good combinations of sample rates and latency etc. without getting into extra expensive hardware.

The EQ is Eventide "SplitEQ" (*which is a beast, separating processing of transients and body - and allowing 'panning' of transients and body across 6 bands (8 incl. the 2 L/R shelves) - effective - but it carries a lot of latency.

But, I've found I get right to my desired latency for playing Piano by enabling the ioStation24C's fastest settings, plus its native 'zero latency' mode at the master bus (Studio One and ioStation24C are Presonus products, so this latency killer is a proprietary hook-up - probably breaking some norms).

Normally, I like a bit of latency when playing Pianoteq in standalone mode - enough to 'feel' like a real piano (setting higher buffer etc. 'to feel').

But with ways to claw back latency with a good external audio unit, plus something like the DAW Studio One's native zero latency mode, you can add various plugins (or sometimes just 1 heavy latency one like that actually pretty wonderful Eventide EQ).

Somehow, 16 is faster in this setup!?

(higher seems to get back to 'too much latency with this EQ') in the above setup here - but as a rule, probably without other proprietary zero-mode things involved maybe?, 32 or 64 likely behaves as expected - esp. if not trying to nullify a heavy plugin latency effect.

On that note.. I thought, surely setting to 44.1kHz would improve latency also.. however, with the above setup, (probably again, hardware + DAW having that proprietary zero latency loop), it's faster using 48kHz but with 64bit precision (rather than 32 or 24 - go figure!?).

But, if latency is a problem, certainly consider an external unit like ioStation24C which has some interesting capabilities, and the native features which may be available when that hardware is hooked up for the DAW - very useful. Presonus stuff kind of surprises me every so often in this way.

Maybe others here have low latency hardware/software combos which kind of help zero out concerns with latency too.

(I fussed to get the lowest latency with that EQ - and, had to bust through a lot of long-held conceptions about 'what the numbers should do' - and I'm glad I tried higher sample rates, and crazy low buffer etc.. the zero latency mode in Studio One with their native hardware.. killer stuff.)

Currently have a DAW project going with an EQ with high latency, and making my buffer 16 (in the past, maybe even 32 or 64 might not have been quick enough) makes the latency feel normal to play without having to turn off the EQ which is doing something specifically I'd like to hear while playing.

Non-linear-phase EQs should not require a look-ahead buffer for processing and induce no additional latency. A linear-phase EQ will typically add something on the order of 4096 samples of latency at a minimum (can easily be 4-8 times that, depending on the precision/quality setting if it has one). The difference between a 64-sample ASIO (device) buffer and a 32-sample buffer (or even 16) is going to be undetectable in that context (48/4096 = 1.2%). Your MIDI transmission time plus  hardware/firmware latencies probably already render that difference pretty negligable.

Sanderxpander wrote:

sensitive to latency but I don't understand the need to go to 32 samples. Is this just a theoretical exercise?

One good reason for attaining the tiniest latency round-trip possible, would be when using Pianoteq in a DAW with a plugin(s) which might add some latency to things.

Normally, for just playing, I like a little more latency. It's possible on my system to achieve quite low latency - but that feels like a synth, not a nice real piano, so I set buffers a little higher 'to feel'.

Currently have a DAW project going with an EQ with high latency, and making my buffer 16 (in the past, maybe even 32 or 64 might not have been quick enough) makes the latency feel normal to play without having to turn off the EQ which is doing something specifically I'd like to hear while playing.

Noting also about confusion I've encountered about buffer size in DAWs..

some DAWs may break up the display of buffers into separate things:

Device block size - which you set with your audio unit/card or ASIO interface.

and

Process block size - internal DAW processing, which can be a different size. (I guess, some DAWs can calculate smaller 'software' blocks within the 'hardware' device block? Maybe others knowing more about this exact thing could say for sure how these 2 things actually work, beyond my basic guesses).

You can set up your DAW projects each to have their own settings. A DAW may just have default settings, which you can set to different ones for any future projects you begin with.

But, sometimes, a DAW may display somewhere its process block size, which can be mistaken for the settings you made in your audio tool (device block size).

In some DAWs, device and process block sizes might be on different 'tabs' or at least nearby - look for DAW settings like "Audio device" and "Processing" - maybe if not a 'main' settings section, these could reside in some advanced DAW settings somewhere.

In some DAWs, you can set your audio device's Device block size like you normally do, and somewhere in the normal DAW project interface, you may be able to access something like "Song Settings/Options" and choose "Dropout Protection".. which may alter the DAW's 'Processing block size', but leave unaltered the normal 'Device block size'.

A little confusing at first - but once you know these 2 things are possible in some DAWs, it may explain why some numbers seem mismatched, when there may be a reason.

I've never heard of a 16 sample buffer size. That's less than half a millisecond even at 44.1. There can't be many drivers that accept that. What setup do you use and what samplerate do you run at?

sensitive to latency but I don't understand the need to go to 32 samples. Is this just a theoretical exercise?

One good reason for attaining the tiniest latency round-trip possible, would be when using Pianoteq in a DAW with a plugin(s) which might add some latency to things.

Normally, for just playing, I like a little more latency. It's possible on my system to achieve quite low latency - but that feels like a synth, not a nice real piano, so I set buffers a little higher 'to feel'.

Currently have a DAW project going with an EQ with high latency, and making my buffer 16 (in the past, maybe even 32 or 64 might not have been quick enough) makes the latency feel normal to play without having to turn off the EQ which is doing something specifically I'd like to hear while playing.

Noting also about confusion I've encountered about buffer size in DAWs..

some DAWs may break up the display of buffers into separate things:

Device block size - which you set with your audio unit/card or ASIO interface.

and

Process block size - internal DAW processing, which can be a different size. (I guess, some DAWs can calculate smaller 'software' blocks within the 'hardware' device block? Maybe others knowing more about this exact thing could say for sure how these 2 things actually work, beyond my basic guesses).

You can set up your DAW projects each to have their own settings. A DAW may just have default settings, which you can set to different ones for any future projects you begin with.

But, sometimes, a DAW may display somewhere its process block size, which can be mistaken for the settings you made in your audio tool (device block size).

In some DAWs, device and process block sizes might be on different 'tabs' or at least nearby - look for DAW settings like "Audio device" and "Processing" - maybe if not a 'main' settings section, these could reside in some advanced DAW settings somewhere.

In some DAWs, you can set your audio device's Device block size like you normally do, and somewhere in the normal DAW project interface, you may be able to access something like "Song Settings/Options" and choose "Dropout Protection".. which may alter the DAW's 'Processing block size', but leave unaltered the normal 'Device block size'.

A little confusing at first - but once you know these 2 things are possible in some DAWs, it may explain why some numbers seem mismatched, when there may be a reason.

theinvisibleman wrote:

when will we get an update to solve the buffer size issue on VST version of pianoteq.

clearly the VST is stuck at a minimum limit of 64 buffer size.

The VST cannot choose the buffer size, it is the host which sets it. In this case, Live seems to be using a buffer size of 64 even if you have requested a buffer of 32 in its audio preferences panel. You should get in touch with Ableton support if the 32 samples buffer size is really important to you. However I would not recommend to use Pianoteq with buffer sizes smaller than 64 as the computations of the engine are optimized for buffer sizes >= 64.

As an extra hint, you can look at the 'output latency' value displayed below the buffer size combo box in the 'Audio' preferences of Live: the latency is the same '5.58ms' for buffer sizes of 32 and 64 samples.

A 64 sample buffer size is like 1.5ms of audio processing latency even at 44.1KHz, the bulk of the 5.58 won't be affected by going any lower. I'm sensitive to latency but I don't understand the need to go to 32 samples. Is this just a theoretical exercise?

when will we get an update to solve the buffer size issue on VST version of pianoteq.

clearly the VST is stuck at a minimum limit of 64 buffer size.

The VST cannot choose the buffer size, it is the host which sets it. In this case, Live seems to be using a buffer size of 64 even if you have requested a buffer of 32 in its audio preferences panel. You should get in touch with Ableton support if the 32 samples buffer size is really important to you. However I would not recommend to use Pianoteq with buffer sizes smaller than 64 as the computations of the engine are optimized for buffer sizes >= 64.

As an extra hint, you can look at the 'output latency' value displayed below the buffer size combo box in the 'Audio' preferences of Live: the latency is the same '5.58ms' for buffer sizes of 32 and 64 samples.

clearly the VST is stuck at a minimum limit of 64 buffer size.

I find using a DAW really difficult as I don’t play strictly in time. I love rubato too much!

Not to hijack the thread further but I'm also a fan of free/rubato timing and record almost everything without a click. If I need the timeline to match in order to be able to convert to notation, massage the timing or add other instruments, I use CbB's Set Measure/Beat At Now feature to tell it where the bar lines should fall and it creates appropriate tempo changes to make that happen without altering the original performance timing. An indispensible feature.

The original question was about buffer size, not sample rate. So I don't think this is relevant, but happy to see another CbB user on the forum. ;^)

I didn’t specifically specify that both the Buffer Size and Rate were picked up from the host - though they both are. I was just wondering if the available sub-sample rate was affecting the VST?

On the question of CbB, I bought Sonar after Cubase SX 3 and have made little use of it. I prefer to play live and as Pianoteq records, it’s easy to save a performance from there. I find using a DAW really difficult as I don’t play strictly in time. I love rubato too much!

As you can see P8 is aware of the host application's setting (CbB*) and gives an option to change the internal sample rate to a multiple of the host's...

The original question was about buffer size, not sample rate. So I don't think this is relevant, but happy to see another CbB user on the forum. ;^)

As you can see P8 is aware of the host application's setting (CbB*) and gives an option to change the internal sample rate to a multiple of the host's...

1 : 2/3 : 1/5 : 1/3 : 1/4

* Cakewalk by Bandlab

Steinberg's VST Live App on my M1 Mac does not even see v8 in the available vst instrument list.
Only v7.

You should start a new thread for that issue, and the Steinberg forum might be a better place to start. That said, the first step would be to verify the VST2 .DLL and/or .VST3 files are saved in the same place VST Live is scanning. I don't speak Mac, but in Windows the former will be in C:\Program Files\Steinberg\VstPlugins and the latter will be in C:\Program Files\Common Files\VST3 by default.

Jeff

pianoteq 8 VST doesn't run at same sample buffer size as DAW

FWIW I'm not seeing this in Cakewalk by Bandlab using native ASIO drivers with either the Roland Duo-Capture EX USB interface on my laptop or MOTU PCIe 424 in my dekstop DAW. The VSTi follows the ASIO buffer setting of the interface driver which is read by CbB on launch but can be changed by opening the driver's control panel from within CbB.