Make the plugin lock-free

[madskjeldgaard]

This plugin currently isn't entirely lock-free.

This could be an issue for performance.

The plugin should be made lock-free.

The difficult thing is where the realtime processing of incoming OSC messages are done and the resulting data is used to create midi buffers. This is where the lock needs to be right now to avoid data-races, but ideally this shouldn't be the case.

[giohappy]

While exploring ways to implement an internal scheduler to support timestamped OSC bundles I stumbled upen the locking over the MidiBuffer.

I'm not an expert on this but I guess a solution based on the AbstractFifo could be investigated. This can be used to manage the read/write indexes of a generic circular buffer atomically.

The key point is to avoid allocations, so the buffer should be preallocated. This means one should estimate how much to preallocate, and be prepared for the case where there's no space left in the buffer (the number of incoming OSC messages exceed the buffer capacity).
Maybe a value of 2048 for the preallocation could fine, which is the size JUCE allocates for MidiBuffers (e.g. here where a plugin is prepared)

I'm not ready to propose a solution, but I will keep studying this problem.

[madskjeldgaard]

While exploring ways to implement an internal scheduler to support timestamped OSC bundles I stumbled upen the locking over the MidiBuffer.

I'm not an expert on this but I guess a solution based on the AbstractFifo could be investigated. This can be used to manage the read/write indexes of a generic circular buffer atomically.

The key point is to avoid allocations, so the buffer should be preallocated. This means one should estimate how much to preallocate, and be prepared for the case where there's no space left in the buffer (the number of incoming OSC messages exceed the buffer capacity). Maybe a value of 2048 for the preallocation could fine, which is the size JUCE allocates for MidiBuffers (e.g. here where a plugin is prepared)

I'm not ready to propose a solution, but I will keep studying this problem.

Sounds great. Thanks for the reasearch!

[madskjeldgaard]

And to be clear:

It's the locks in this file that are the target here:

https://github.com/madskjeldgaard/Birdhouse/blob/main/source/bridge/OSCBridgeChannel.h#L123