`scprintf` from within scsynth does not work when running `sclang` about supercollider HOT 4 CLOSED

This affects the .poll method

from supercollider.

Funny fact:
running scsynth, scprintf() will work fine.
Running sclang, the scprintf() of the spawned process will not work fine.

Even more: if you start sclang and then kill -2 \pgrep scsynth`(orkill -2the pid of the audio thread), it will dump all thescprintfmessages you printed earlier and were not actually printed . However, if you ctrl-csclang` it will die immediately without dumping those messages. Still, the PRU will stop correctly (which somehow means that the signal handler (see #11) is getting called, but the messages are not dumped.).

As suggested by @apmcpherson, this can totally be an issue of buffering of the stdout of scsynth when started by sclang. However, I tried to make sclang start scsynth with stdbuf -i 0 -o 0 -e 0 scsynth (which should prevent buffering of stdout/in/err) instead of exec scsynth and this does not yield any improvement. example patch:

diff --git a/SCClassLibrary/Platform/linux/LinuxPlatform.sc b/SCClassLibrary/Platform/linux/LinuxPlatform.sc
index 19566f1..c2724ad 100644
--- a/SCClassLibrary/Platform/linux/LinuxPlatform.sc
+++ b/SCClassLibrary/Platform/linux/LinuxPlatform.sc
@@ -10,7 +10,7 @@ LinuxPlatform : UnixPlatform {
                helpDir = this.systemAppSupportDir++"/Help";

                // Server setup
-               Server.program = "exec scsynth";
+               Server.program = "stdbuf -o0 -i0 -e0 scsynth";

                // Score setup
                Score.program = Server.program;

note that if I run exec stdbuf -o0 -i0 -e0 scsynth it just fails (scsynth process becomes defunct).

from supercollider.

so I have a fix for this, but then if I use poll() in SC, the console gets flooded with messages. @sensestage do you know how poll() is implemented (e.g.: in something like:

        var rate = AnalogIn.ar(0).exprange(0.3, 20);
        rate.poll(100);

) ? Where is this poll() implemented?

This is the patch which flushes the rt_printf buffers from a separate thread and outlines the issue above:

diff --git a/server/scsynth/SC_Bela.cpp b/server/scsynth/SC_Bela.cpp
index 8e34305..ee91360 100644
--- a/server/scsynth/SC_Bela.cpp
+++ b/server/scsynth/SC_Bela.cpp
@@ -327,6 +327,7 @@ void SC_BelaDriver::staticMAudioSyncSignal(void*){
        // ... but mode switches are still happening here, in a lower priority thread.
        // FIXME: this triggers a mode switch in Xenomai.
        staticMAudioSync->Signal();
+       rt_print_flush_buffers();
        rt_task_suspend(rt_task_self());
 }

from supercollider.

Right, my fix is fine. The "flooding" I experienced above is related to another issue.

Merge PR #60 to fix this.

from supercollider.