SmallVec-style optimization

[Be-ing]

It would be neat if the audio buffers implemented an optimization like SmallVec where buffers with a frame sizes and channel counts <= to const generics were stored on the stack and larger buffers were stored on the heap. Often the likely maximum number of frames and channels is known at compile time, but hardcoding such limits would make the program inflexible. For example, a buffer in a realtime application taking data from arbitrary audio files will likely have <= 2 channels and <= 1024 or 512 frames.

[udoprog]

Note that wrap types accomplish some of this, with the requirement that the wrapped buffer is fully initialized.

If I'm reading this correctly you mean introducing another suite of types which uses const generics to determine their capacity (stored inline) and can work with uninitialized memory?

[Be-ing]

Note that wrap types accomplish some of this, with the requirement that the wrapped buffer is fully initialized.

Interesting, that could kinda work, but it would require hardcoding arbitrary limits on the numbers of frames and channels. My idea is to keep buffers within a hardcoded size on the stack, and only use the heap if that size is exceeded.

If I'm reading this correctly you mean introducing another suite of types which uses const generics to determine their capacity (stored inline) and can work with uninitialized memory?

I'm not trying to use uninitialized memory.

[Be-ing]

Thinking about this more, Interleaved and Sequential only use a single region of memory, so it would be more flexible to use a single const generic rather than two (channels and frames). That would allow increasing either the number of frames or channels until the hardcoded memory size is exceeded.