# Changing buffer size (and audio options) inside a plugin

**URL:** <https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208>\
**Category:** Audio Plugins\
**Created:** [February 13, 2025, 11:33am UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208 "2025-02-13T11:33:33Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![newjucer19](https://avatars.discourse-cdn.com/v4/letter/n/e56c9b/32.png) [@newjucer19](https://forum.juce.com/u/newjucer19)\
**Post date:** [February 13, 2025, 11:33am UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208/1 "2025-02-13T11:33:33Z")

</div>

Hello everyone,

I began to use Juce a few weeks ago, still learning. Not so savy in C++ either, so thanks in advance for your patience.

I work on a plugin which requires runtime changes to the buffer size (samples per block) by user choice, from a combo box. I manage to pass related parameter fine from GUI, however the standalone version I test the plugin apparently overrides the change. Only the related choice from its default Options button (menu bar left side) apply at runtime. Since I can only test the plugin as standalone version for now, not sure the plugin version will perform differently.

So far I tried the following from AudioProcessor unit:

Changing size inside “processBlock” (buffer.setSize) each time by this parameter value. This works but leads to a loss of audio input relation it seems. The observation is based on mic audio input. It’s as if the resized buffer is no more processed, although resizing comes first in the processBlock cycle. I would not need indefinite size change calls anyway, I’d prefer a proper one time change from a suitable function. But which one and how, if this is still to be a runtime choice?

I also tried “setPlayConfigDetails” and “setRateAndBufferSizeDetails” provided by audioprocessor class, under “parameterChanged” function after adding a listener for related parameter. These work and parameter is passed fine again, but no change is applied to buffer size by the use of above. I also tried “updateHostDisplay()” where I feel a bit lost (ChangeDetails?). I considered the standalone executable acts as this host perhaps?

More generally, I wonder if one can implement audio options found under Options button of standalone version, or customized sections from it in a plugin, for runtime choices from inside that plugin. Thanks for possible help.

---

<div class="post-metadata">

**Author:** ![ibisum](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ibisum/32/21288_2.png) [@ibisum](https://forum.juce.com/u/ibisum)\
**Post date:** [February 13, 2025, 11:49am UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208/2 "2025-02-13T11:49:01Z")

</div>

Generally, the responsibility for the processBlock buffersize is held by the users DAW - this is set as per their preferences, according to the DAW environment. This is so that the DAW (or user) can determine which buffer size works best for their system, as not all systems are the equivalent - it depends heavily on the processing power and I/O available in the DAW and Audio interface configuration.

The best approach to your situation is to get yourself a DAW for testing - REAPER works very well for this, and will provide you with a proper environment for adjusting buffer sizes. You can also use pluginval or auval.

The standalone executable target is not so much of a plugin host - more of a wrapper around plugin code that provides a minimal environment to instantiate the code for the UI and establish a rudimentary environment for testing. Really though, the best approach is to use a DAW early in the development process …

---

<div class="post-metadata">

**Author:** ![kerfuffle](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kerfuffle/32/11805_2.png) [@kerfuffle](https://forum.juce.com/u/kerfuffle)\
**Post date:** [February 13, 2025, 12:09pm UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208/3 "2025-02-13T12:09:25Z")

</div>

> [@newjucer19](#):
>
> I work on a plugin which requires runtime changes to the buffer size (samples per block) by user choice, from a combo box.

Why do you need to do that? This might be an X/Y-problem where you are asking about the solution but not telling us the actual problem you’re trying to solve.

---

<div class="post-metadata">

**Author:** ![newjucer19](https://avatars.discourse-cdn.com/v4/letter/n/e56c9b/32.png) [@newjucer19](https://forum.juce.com/u/newjucer19)\
**Post date:** [February 13, 2025, 12:19pm UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208/4 "2025-02-13T12:19:27Z")

</div>

I understand the DAW dependency of a plugin in this manner, but the particular plugin I wish to develop is somewhat different from typical ones (no effect or synth).

It is to detect audio characteristics from mic input, to generate midi data. Buffer size can impact performance directly and the user might really prefer runtime changes. Hence I hoped to make at least buffer resizing option available in the plugin, for user convenience. Instead of them looking for the option each time in their particular DAW. At least technically then, is there no way to do this within JUCE’s plugin scope? Or would this be considered a bad design idea? Thanks for your prompt reply by the way, really appreciated.

---

<div class="post-metadata">

**Author:** ![newjucer19](https://avatars.discourse-cdn.com/v4/letter/n/e56c9b/32.png) [@newjucer19](https://forum.juce.com/u/newjucer19)\
**Post date:** [February 13, 2025, 12:28pm UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208/5 "2025-02-13T12:28:30Z")

</div>

Briefly stated, this plugin is to detect audio characteristics from mic input, to generate midi data. So buffer size can impact algorithm performance and the user might really need buffer size changes at runtime, in addition to some other algorithm parameters.

Hence for user convenience, I thought of including such resizing option available inside the plugin. But I understand the DAW oriented control and access for typical plugins. So perhaps it’s not a good idea, not sure. Still, I do wonder if such access can be possible using JUCE plugin template though, at least technically.

---

<div class="post-metadata">

**Author:** ![zsliu98](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/zsliu98/32/22502_2.png) [@zsliu98](https://forum.juce.com/u/zsliu98)\
**Post date:** [February 13, 2025, 2:27pm UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208/6 "2025-02-13T14:27:17Z")

</div>

You could use a FIFO to collect input audio samples. And once you get enough samples (i.e., the buffer size you want), you can process them at once. However, you can see that it will introduce latency (which is identical to the buffer size (or -1) you want).

---

<div class="post-metadata">

**Author:** ![kerfuffle](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kerfuffle/32/11805_2.png) [@kerfuffle](https://forum.juce.com/u/kerfuffle)\
**Post date:** [February 13, 2025, 2:43pm UTC](https://forum.juce.com/t/changing-buffer-size-and-audio-options-inside-a-plugin/65208/7 "2025-02-13T14:43:48Z")

</div>

If this is for use while tracking / recording, then the user won’t have any option but to lower the buffer size in their DAW. Which hopefully they already set to the lowest possible on their system, since it also affects how they hear themselves etc (depending on how fancy their equipment is).

In any case, it’s best to leave this to the DAW since that is optimized for making the right decisions (your plug-in doesn’t know what else is going on in the session, while the DAW does know that and will take this into consideration).
