I managed to install TidalCycle (with Pulsar) and SuperCollider. At first, everything was working fine… But recently, when I try to activate SuperDirt, SC tells me that I don’t have enough buffers. So, I increased the buffer size, but each time I had to increase it again and again… Now, I can’t do anything anymore. ^^ It no longer takes my buffers into account.
Do you have any idea how to reset everything or improve the situation?
Why do I always have to increase the buffers in SC for Tidal? Normally, I should only have to do it once, right?
So yeah, I’m stuck. ^^
(i use SC 3.12 for osx Hight Sierra and Pulsar for Tidal)
I give you a bit of what the console says (there’s more of it) I think it comes from SuperDirt… am i right ?
Thx
=========
ERROR: No more buffer numbers – free some buffers before allocating more.
PROTECTED CALL STACK:
Server:nextBufferNumber 0x11dc8ab40
arg this = localhost
arg n = 1
var bufnum = nil
Meta_Buffer:new 0x11c2f9980
arg this = Buffer
arg server = localhost
arg numFrames = nil
arg numChannels = nil
arg bufnum = nil
Meta_Buffer:readWithInfo 0x11e026ec0
arg this = Buffer
arg server = localhost
arg path = /Users/tommyheisler/Library/Application Support/SuperCollider/downloaded-quarks/SuperDirt/classes/…/…/Dirt-Samples/tabla2/23689_loofa_bahia017.wav
arg startFrame = 0
arg numFrames = -1
arg onlyHeader = false
arg onComplete = nil
a FunctionDef 0x11d78ff80
sourceCode = “”
var buf = nil
var metaData = nil
Function:prTry 0x11d299800
arg this = a Function
var result = nil
var thread = a Routine
var next = nil
var wasInProtectedFunc = false
CALL STACK:
Exception:reportError
arg this =
ArrayedCollection:do
arg this = [*48]
arg function =
var i = 44
DirtSoundLibrary:loadSoundFilePaths
arg this =
arg filePaths = [*48]
arg name = ‘tabla2’
arg appendToExisting = false
DirtSoundLibrary:loadSoundFileFolder
arg this =
arg folderPath = “/Users/tommyheisler/Library/…”
arg name = ‘tabla2’
arg appendToExisting = false
arg sortFiles = true
var files = [*48]
ArrayedCollection:do
arg this = [*217]
arg function =
var i = 198
DirtSoundLibrary:loadSoundFiles
arg this =
arg paths = “/Users/tommyheisler/Library/…”
arg appendToExisting = false
arg namingFunction =
var folderPaths = [*217]
var memory = 0
SuperDirt:loadSoundFiles
arg this =
arg paths = nil
arg appendToExisting = false
arg namingFunction = nil
< FunctionDef in Method Meta_SuperDirt:start > (no arguments or variables)
Routine:prStart
arg this =
arg inval = 676.368195319
^^ The preceding error dump is for ERROR: No more buffer numbers – free some buffers before allocating more.
ERROR: No more buffer numbers – free some buffers before allocating more.
This seems way too high. The default is 1024 for SC which might be too low, so you can raise it but probably not to 123590000. For reference, if every buffer is 100 ms this amounts to a total playing time of 143 days (!). Also remember to free your buffers when you don’t need them anymore and/or run s.newBufferAllocators if you reinstantiate your code without rebooting the server.
I can’t even boot the server with this setting – it hangs a few seconds, then “Server ‘localhost’ exited with exit code 0.”
In the source code, numBuffers gets bumped up to the next power of 2, so it’s really 134217728. Then it’s reserving memory for that number * sizeof(SndBuf), and I’m pretty sure here’s where my server is dying.
If your server is booting successfully, then maybe it isn’t actually applying the option.
What’s the exact sequence of steps you’re taking, starting from launching the IDE?
Open SC
Boot the interpreter
Boot the server
SuperDirt.start
And then the issue appears with a lot of text and my computer starts lagging until I can manage to close the interpreter. Also, it doesn’t seem to be the same sample every time, but several different ones.
I rebooted the server after s.options.numBuffers_(2048).
Then => SuperDirt.start.
After that, it compiles the classes and samples. Everything is okay until I get this a few seconds later:
SuperDirt: listening on port 57120
exception in real time: alloc failed, increase server’s memory allocation (e.g. via ServerOptions)
exception in real time: alloc failed, increase server’s memory allocation (e.g. via ServerOptions)
exception in real time: alloc failed, increase server’s memory allocation (e.g. via ServerOptions)
exception in real time: alloc failed, increase server’s memory allocation (e.g. via ServerOptions)
exception in real time: alloc failed, increase server’s memory allocation (e.g. via ServerOptions)
exception in real time: alloc failed, increase server’s memory allocation (e.g. via ServerOptions)
exception in real time: alloc failed, increase server’s memory allocation (e.g. via ServerOptions)
Okey, I’m rebooting after s.options.numBuffers_(2048)
and s.options.memSize_(2 ** 20) and this :
no synth or sample named 'retro_synth' could be found.
module 'sound': instrument not found: retro_synth
no synth or sample named 'retro_synth' could be found.
module 'sound': instrument not found: retro_synth
....
Do you get this even without booting SuperDirt, just booting SC? Do you have something in your startup.scd file which reference ‘retro_synth’ or are you otherwise trying to play the synth right after booting? I would suggest using s.waitForBoot
s.waitForBoot{
create synthDefs....
s.sync // this tells the server to report back when everything is done
use you synths...
}
Without the s.sync you will get in trouble when trying to use a synth right after you create the synthdef.
Okey it’s good to know !
Nop i have nothing running and from begin of the Interpreter to Boot.
I get an other issue with s.sync but it’s not our topics ^^ i think.
I dug deeper and found this in try-load-extra-synths.scd:
if(\MembraneHexagon.asClass.isNil) {
"Dirt could not load some synths from default-synths.scd, because sc3plugins are necessary and missing.".warn
} {
loadRelative("../library/default-synths-extra.scd");
loadRelative("../library/default-effects-extra.scd");
};
This way, your server options will be set automatically every time the language starts (i.e. guaranteed to come before server boot).
If, after that, you still get the exception, maybe raise memSize by another power of 2.
“Exception in real-time” is almost certainly related to effect synths. I suppose SuperDirt ought to document how much real-time memory is expected to be required; I’m not sure whether it does or not.
Oh ok i will now change what you say Thanks !
I did an other Trip deep down SC etc folders:
/*
This is an example startup file.
If you want to modify it, best copy it elsewhere to keep the git repository clean.
You can then load it by calling
"path/to/my/superdirt_startup.scd".load
from the supercollider startup file
The supercollider startup file is to be found in
Platform.userAppSupportDir +/+ "startup.scd",
or via the menu File > Open startup file
*/
(
s.reboot { // server options are only updated on reboot
// configure the sound server: here you could add hardware specific options
// see http://doc.sccode.org/Classes/ServerOptions.html
s.options.numBuffers = 1024 * 256; // increase this if you need to load more samples
s.options.memSize = 8192 * 32; // increase this if you get "alloc failed" messages
s.options.numWireBufs = 2048; // increase this if you get "exceeded number of interconnect buffers" messages
s.options.maxNodes = 1024 * 32; // increase this if you are getting drop outs and the message "too many nodes"
s.options.numOutputBusChannels = 2; // set this to your hardware output channel size, if necessary
s.options.numInputBusChannels = 2; // set this to your hardware output channel size, if necessary
// boot the server and start SuperDirt
s.waitForBoot {
~dirt.stop; // stop any old ones, avoid duplicate dirt (if it is nil, this won't do anything)
~dirt = SuperDirt(2, s); // two output channels, increase if you want to pan across more channels
~dirt.loadSoundFiles; // load samples (path containing a wildcard can be passed in)
// for example: ~dirt.loadSoundFiles("/Users/myUserName/Dirt/samples/*");
// s.sync; // optionally: wait for samples to be read
~dirt.start(57120, 0 ! 12); // start listening on port 57120, create two busses each sending audio to channel 0
SuperDirt.default = ~dirt; // make this instance available in sclang (optional)
// optional, needed for convenient access from sclang:
(
~d1 = ~dirt.orbits[0]; ~d2 = ~dirt.orbits[1]; ~d3 = ~dirt.orbits[2];
~d4 = ~dirt.orbits[3]; ~d5 = ~dirt.orbits[4]; ~d6 = ~dirt.orbits[5];
~d7 = ~dirt.orbits[6]; ~d8 = ~dirt.orbits[7]; ~d9 = ~dirt.orbits[8];
~d10 = ~dirt.orbits[9]; ~d11 = ~dirt.orbits[10]; ~d12 = ~dirt.orbits[11];
);
// directly below here, in your own copy of this file, you could add further code that you want to call on startup
// this makes sure the server and ~dirt are running
// you can keep this separate and make it easier to switch between setups
// by using "path/to/my/file.scd".load and if necessary commenting out different load statements
// ...
};
s.latency = 0.3; // increase this if you get "late" messages
};
);
I use the superdirt_startup.scd to boot everything and the connection seems to work with Pulsar and Tidal.
Muss i everytime open this .scd file to play with Tidal ?
You can then load it by calling
"path/to/my/superdirt_startup.scd".load
from the supercollider startup file
The supercollider startup file is to be found in
Platform.userAppSupportDir +/+ "startup.scd",
or via the menu File > Open startup file
This is a file that the interpreter executes for you, every time sclang starts up.
So you put things into it that you want to happen every time you start up.
If you want to run the SuperDirt init automatically upon startup, then you’d save the superdirt_startup.scd file somewhere. Then, in your startup file, you’d put:
"/full/path/to/superdirt_startup.scd".load;
And then you would not need to open that file (because sc will do it for you).
okey i just overloaded the system… but also when i try s.options.numBuffers_(1024)…