Another stuff is required to understand the changes.

When the DSP chain need to be rebuilt, it is a temporary one that is constructed. The old one is still running! Once done they are swapped. To do that, some ressources are owned by the DSP chain and freed with it later. Consequently note that the dsp method can be called concurrently with the perform method

DSP objects commented here:

< https://github.com/Spaghettis/Hello/blob/master/src/helloSpace~.c >
< https://github.com/Spaghettis/Hello/blob/master/src/helloData~.c >
< https://github.com/Spaghettis/Hello/blob/master/src/helloBiquad~.c >

Thanks for your reply! Clever stuff, I definitely want to study it when I have a bit more time.

For Arch Linux explorers < https://aur.archlinux.org/packages/spaghettis-git >.

Note that multithreading the DSP implies that determinism is broken (related to control messages). Thus all the DSP stuff should stay in DSP chain as far as possible. It certainly will require to add new DSP objects for that. It implies also that time consuming operations can still bloat the main thread and delay control messages in a not reasonable manner.

DISCLAIMER: I i strongly consider to remove the GOP feature in order to totally rewrite the GUI (with JUCE or Qt or whatever). I guess that nobody really uses my fork for now (and for ever), but in case, be aware that it could change deeply. Note that the only valuable reason to have started that fork was the opportunity to change things radically!

For instance after many years < https://forum.pdpatchrepo.info/topic/9529/do-you-often-use-the-struct-objects > i still think that introducing scalars (into a data flow paradigm software) was wrong. It is rather unusable. It makes things really messy for users and devs < https://lists.puredata.info/pipermail/pd-dev/2020-01/022252.html >. A big GUI rewrite could be the time to drop them!

< https://forum.pdpatchrepo.info/topic/12588/the-future-of-spaghettis >