@Nicolas-Danet said:

QWERTY keyboard! Does it works if you add following code?

    event add <<NewObject>>                 <$mod-Key-1>
    event add <<NewMessage>>                <$mod-Key-2>
    event add <<NewAtom>>                   <$mod-Key-3>
    event add <<NewSymbol>>                 <$mod-Key-4>
    event add <<NewComment>>                <$mod-Key-5>
    event add <<NewBang>>                   <$mod-Key-6>
    event add <<NewToggle>>                 <$mod-Key-7>
    event add <<NewDial>>                   <$mod-Key-8>
    event add <<NewArray>>                  <$mod-Key-9>

There < https://github.com/Spaghettis/Spaghettis/blob/master/tcl/ui_bind.tcl#L106 >.

Yes, that worked.

Good to know, thanks.

It should work on macOS Catalina now.

PS: Note that i need help (e.g. for testing). Why does it worth the cost? The DSP is multi-threaded. It is supposed to be wait-free. It is supposed to not glitch anymore. Ok, i stop this shameful promotion.

The DSP is multi-threaded. It is supposed to be wait-free.

@Nicolas-Danet This sounds exciting! I have some questions:

1. how do you handle concurrent garray reads/writes?
2. how do you handle concurrent access to the clock list (e.g. calling clock_set in the perform routine)?
3. which API functions are safe to call in the perform routine?

I could probably find the answers by reading the source code, but maybe you could give some rough answers, so I know what I should look for

Cheers, Christof

Quickly:

1. The garray values are read/write atomically < https://github.com/Spaghettis/Spaghettis/blob/87c0639c502b461af46084ff605030f75c006737/src/m_spaghettis.h#L533 >.
2. 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 >.
3. 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!

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 >