Hi all -
I am running Plotter-4 from the Ted Moore YouTube link(https://www.youtube.com/watch?v=QvipZKrDwdU)…but I’d like to use 96khz samples.
I’m noticing that this crashes the SuperCollider server with this error:
Server 'localhost' exited with exit code 0.
server 'localhost' disconnected shared memory interface
Does FluComa work with 96kHz? Is there a different hopsize/fftSize that would impact this crash?
Thanks!
Hi @areacode,
Can you provide us a bit more info? Does it crash when doing the analysis? Or just when trying to boot the server?
t
Yes - it starts to do the analysis - and gets partially through the slicing.
In my case, it seemed to get to 100 slices (out of 2400) before it crashed, so I removed this:
if((i%100) == 99){s.sync};
This seemingly counted most of the slices…but then crashed at the next s.sync. So I removed the next s.sync and it still crashes.
Because of the language-server relationship of SC sometimes the thing we see in the language isn’t accurately representing what’s happening on the server. For example, (I’d have to go revisit the code to remember exactly) even though it says it has processed the first 100 slices in the language, all that really means is that it has sent the instructions for processing the first 100 slices to the server. So we can’t really be sure if it is even processing those 100 slices.
Removing the syncs is probably making it more likely to crash.
Change if((i%100) == 99){s.sync}; to just s.sync; so that it syncs on every slice (yes this will be slower) to see if it makes any progress then. If it gets through 2400 then maybe we can add if((i%100) == 0){s.sync}; back in and slowly increase the 100 until it crashes and maybe that’s the amount of processing the server can handle without a sync to take a pause.
It also would probably be useful to share the code so that we can eyeball it and make sure there aren’t other potential issues lurking in there that aren’t related to running at 96k.
Just to clarify, the code is exactly that of plotter-4.scd from your video - I am just loading 96khz files instead of from FluidFilesPath. I’ll reproduce it below, for completeness.
s.sync on every slice seems to cause the server to idle in “yellow” permanently.
// define this big function, then way down below, execute it
s.options.sampleRate = 96000;
s.reboot;
(
~twoD_instrument = {
arg folder, sliceThresh = 0.05;
fork{
var loader = FluidLoadFolder(folder).play(s,{"done".postln;});
var src, play_slice, analyses, normed, tree;
var indices = Buffer(s);
s.sync;
if(loader.buffer.numChannels > 1){
src = Buffer(s);
FluidBufCompose.processBlocking(s,loader.buffer,startChan:0,numChans:1,destination:src,destStartChan:0,gain:-6.dbamp);
FluidBufCompose.processBlocking(s,loader.buffer,startChan:1,numChans:1,destination:src,destStartChan:0,gain:-6.dbamp,destGain:1);
}{
src = loader.buffer
};
FluidBufOnsetSlice.processBlocking(s,src,metric:9,threshold:sliceThresh,indices:indices,action:{
"done".postln;
"average seconds per slice: %".format(src.duration / indices.numFrames).postln;
});
play_slice = {
arg index;
{
var startsamp = Index.kr(indices,index);
var stopsamp = Index.kr(indices,index+1);
var phs = Phasor.ar(0,BufRateScale.ir(src),startsamp,stopsamp);
var sig = BufRd.ar(1,src,phs);
var dursecs = (stopsamp - startsamp) / BufSampleRate.ir(src);
var env;
dursecs = min(dursecs,1);
env = EnvGen.kr(Env([0,1,1,0],[0.03,dursecs-0.06,0.03]),doneAction:2);
sig.dup * env;
}.play;
};
// analysis
analyses = FluidDataSet(s);
indices.loadToFloatArray(action:{
arg fa;
fork{
var spec = Buffer(s);
var stats = Buffer(s);
var stats2 = Buffer(s);
var loudness = Buffer(s);
var point = Buffer(s);
fa.doAdjacentPairs{
arg start, end, i;
var num = end - start;
FluidBufSpectralShape.processBlocking(s,src,start,num,features:spec,select:[\centroid]);
FluidBufStats.processBlocking(s,spec,stats:stats,select:[\mean]);
FluidBufLoudness.processBlocking(s,src,start,num,features:loudness,select:[\loudness]);
FluidBufStats.processBlocking(s,loudness,stats:stats2,select:[\mean]);
FluidBufCompose.processBlocking(s,stats,destination:point,destStartFrame:0);
FluidBufCompose.processBlocking(s,stats2,destination:point,destStartFrame:1);
analyses.addPoint(i,point);
"slice % / %".format(i,fa.size).postln;
s.sync;
};
s.sync;
analyses.print;
normed = FluidDataSet(s);
FluidNormalize(s).fitTransform(analyses,normed);
normed.print;
tree = FluidKDTree(s);
tree.fit(normed);
// plot
normed.dump({
arg dict;
var point = Buffer.alloc(s,2);
var previous = nil;
dict.postln;
defer{
FluidPlotter(dict:dict,mouseMoveAction:{
arg view, x, y;
[x,y].postln;
point.setn(0,[x,y]);
tree.kNearest(point,1,{
arg nearest;
if(nearest != previous){
nearest.postln;
view.highlight_(nearest);
play_slice.(nearest.asInteger);
previous = nearest;
}
});
});
}
});
}
});
}
};
)
~twoD_instrument.("/Users/w/Desktop/96kFiles/");
one thing to note is that you don’t actually need to run SC synth at 96k to do the analysis since processBlocking is a non-real-time process. so maybe try doing the analysis with scsynth at a lower sample rate.
also, can you print out the results of FluidBufOnsetSlice for us? (more than just the average number of slices: it would be good to know the length of all the slices!) It might be the case that there is a very long slice that is clogging things up.
I can reproduce using your code (with both 96k files and 96k server, will figure out which of these matters later). The crash is in FluidBufStats – I’ll put an issue on github.
Issue here, should you wish to follow along
Haha, my mistake. Not FluidBufStats, it’s FluidBufLoudness. I did something incredibly silly when we changed the code a couple of years back 
So, for now: Fluid[Buf]Loudness is broken at 96k and probably 88. I’ll push a fix soon, so the nightlies will work at least.