RingBuffer is a missing piece

[mashu]

It was the first hit i got when searching juce circular buffer.

[matkatmusic]

Does anyone have an example of a RingBuffer class that uses an array and the AbstractFifo class? You’d think this would be a juce class by now, but it’s not.

[daniel]

What kind of Array? AudioBuffer, Array or std::vector?

I think, it makes sense to leave that out, since the most interesting part is, how to push and pull items. It matters, if there is a method to move the objects (aka trivially copyable). You can lose performance on the copy step, if it doesn’t fit the data you are storing.

For AudioBuffer I created one for myself:

ffAudio/ff_buffers/blob/master/ff_buffers_AudioBufferFIFO.h#L49

[matkatmusic]

Obviously std::array because you don’t want to perform any allocation, which can happen with vector or juce::Array.

[daniel]

Sorry, that it wasn’t obvious to me.

Usually you don’t resize your fifo, so there is no allocation…?

It is set up to hold a maximum size of elements, before they wrap around.

[matkatmusic]

Right. If you know your container size at compile time, std::array is the proper container to use.

[xenakios]

No allocations happen (in the audio thread, that no doubt is the concern) if you don’t make them happen. So std::array is not at all the obvious choice, because it forces you to determine at compile time what the maximum number of elements is going to be. Using std::vector or JUCE Array as the container and allowing to resize of course then makes it necessary to remember and/or document it must not be done in real time critical threads but I would personally pay that price for the flexibility and potential memory savings.

OTOH there is the thing that if the size is locked at compile time, the compiler may be able to do some smart tricks with some of the operations…Choices, choices…