Is CEAMMC properly connected into the JACK patchbay? IIRC Pd-vanilla is autoconnected at DSP start but it could be not the case there (note that i never used that fork for now). Oops, i read again your post, and since JACK is not shown in the settings i guess my response is stupid and something else happens.
No, it is not I guess you are talking about < https://en.wikipedia.org/wiki/Flying_Spaghetti_Monster >.
TBH i didn't know about it before to name my stuff (and to google it).
It is more a tribute to < https://cdm.link/app/uploads/2012/10/servando_patch21.jpg >.
I started to rewrite the GUI of my fork Spaghettis < https://github.com/Spaghettis/Spaghettis >.
I'll probably use JUCE instead of Tk (in order to make the application embeddable later).
It will be a time consumming task. But all the next improvements depend of that.
Thus i'll only fix the bugs in the current master branch (probably for the next year).
In the upcoming version i finally decided to remove scalars and GOP.
I think it is necessary in order to split at most the core from the GUI.
The core manages property values and the GUI how to render them.
It will be also easier in the future to make all that scriptable.
Instead of GOP i'll implement a kind of "remote" view.
In that view all the GUI you want will be organized in a single dashboard.
One view for a patch and its subpatches.
A management of presets will be automatically handled in such view.
The idea is to make that view usable also as the interface for a plugin case.
That view could be handy for Raspberry Pi (and others) situations.
All that really smells vaporware. I don't plan much how i'll do that!
But since it is the beginning, it is the moment to have dreams.
If you have any ideas for great features that could be added, just tell me.
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!
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.
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 >
- The garray values are read/write atomically < https://github.com/Spaghettis/Spaghettis/blob/87c0639c502b461af46084ff605030f75c006737/src/m_spaghettis.h#L533 >.
- Clocks are handled by a clock manager (supposed) thread-safe and wait-free < https://github.com/Spaghettis/Spaghettis/blob/master/src/core/m_clocks.c >.
- Only clock_delay (and ringbuffer machinery) is safe in the perform method < https://github.com/Spaghettis/Spaghettis/blob/87c0639c502b461af46084ff605030f75c006737/src/m_spaghettis.h#L955 >.
Of course it is lock-free (wait-free) until somebody will catch an issue!