Description
SuperDirt.start
(the class method) sets some server options before calling waitForBoot
. But if the server is already running, these options are ignored until it's rebooted (that's how scsynth works). So:
s.waitForBoot { SuperDirt.start }
Can start scsynth with too little memory for global effects, causing a server crash. The crash by the way is ugly: it just says "server disconnected shared memory interface..." and so on, without mentioning any "memory allocation fail". This is because sc3-plugins don't fail gracefully yet in this cases.
All of the startup
examples call s.reboot
and I think SuperDirt.start
should do it as well:
diff --git a/classes/extSuperDirtStartup.sc b/classes/extSuperDirtStartup.sc
index ece2d75..f7014a3 100644
--- a/classes/extSuperDirtStartup.sc
+++ b/classes/extSuperDirtStartup.sc
@@ -8,6 +8,7 @@
*start { |numChannels = 2, server, numOrbits = 12, port = 57120, senderAddr, path|
~dirt.free;
server = server ? Server.default;
+ server.reboot{
server.options.numBuffers = 1024 * 256;
server.options.memSize = 8192 * 16;
server.options.maxNodes = 1024 * 32;
@@ -18,6 +19,7 @@
server.sync;
~dirt.start(port, 0 ! numOrbits, senderAddr);
};
+ }
server.latency = 0.3;
}
I encountered this while working on other SuperCollider issues (supercollider/supercollider#6992).
SC 3.14 has a new command for checking free realtime memory, so we were discussing with @telephon if SuperDirt should check how much free memory is available before starting.
I measured on my system, that SuperDirt needs at least 34MB of realtime memory (supercollider's default is 8), but this can vary depening on setup/sampleRate. If SuperDirt wanted to ensure there are at least 50MB of free memory before starting, it could do it like so:
s.rtMemoryStatus { |freeBytes|
// note that this function runs async after a server reply
var freeKilobytes = freeBytes / 1024;
if (freeKilobytes < (50 * 1024)) {
Error("SuperDirt: not enough free memory to start. Set s.options.memSize to at least 50 * 1024").throw
}
}