Don't use mutexes on the DSP thread

[exa04]

Mutexes are discouraged on the Plugin thread - they can lead to lock-ups, glitches, and general performance issues.

Currently, many of Cyma's visualizers synchronize with audio data through some Arc<Mutex<impl VisualizerBuffer>>. The Mutex needs to be locked every time a new chunk of audio gets enqueued or everything gets read out. This can introduce glitches when many plug-ins are used.

A better solution would be a data structure that the plugin processor can continuously write to - whenever it feels like it - without any sort of locking or waiting. I think locking or waiting would probably be fine on the editor thread, though it should definitely perform well at good frame rates. The editor also, in the case of circular buffers, always needs to read out the buffer starting at the correct index.

Possible solutions include:

• Intermediate queues for new samples
• Atomics
• Multiple-buffering (like we did in the Spectrum visualizer)

This is going to be a pretty big change. It should be well though-out. Here's a rough outline of what needs to be done:

• Extensively test the possible alternatives before banking on them
• Introduce as few breaking changes to Cyma's API as possible
• Settle on some new data structures and re-write the previous ones
• Update docs and book to reflect the changes
• Update the examples

[exa04]

Update: My current plan is having some sort of channel system where you can define an audio Inlet in your Plugin, which, at some point in the process() function, takes in the current audio buffer to send it to the editor, where multiple visualizers may read from the same Outlet. Will have a prototype soon on some test- branch.

[exa04]

I'll be working on this system over on the test-channel-buffers branch.

[magnetophon]

Thanks a ton for taking this on!

Extensively test the possible alternatives before banking on them

I can help testing, if you want.
Just tell me what to do.

Introduce as few breaking changes to Cyma's API as possible

Personally, I'd be more than happy to adapt my plugin to any API changes, if that makes it easier for you.
Having a lock free architecture would be more than worth it!

[exa04]

I can help testing, if you want.
Just tell me what to do.

I appreciate the offer! I'll open a PR when I've made enough progress so that you can test the new system :)

Personally, I'd be more than happy to adapt my plugin to any API changes, if that makes it easier for you.

For sure! I'm definitely not against introducing major breaking changes to Cyma, per se. After all, it is still in 0.1.0. But I do however want to only do it when breaking changes would be sensible (e.g. for performance reasons or ease of use.)