FluidMFCC and FluidMelBands on NRT Server

Greetings,

I was trying to run a bunch of analysis on the SuperCollider NRT server and discovered that for some reason the server would crash if I tried to run an instance of FluidMFCC.kr and FluidMelBands.kr at the same time. Is there some reason why this might be the case. Some back end collision?

Thanks,

T

UPDATE.

I think this might be an SC thing because I found to be having the same problem with Chromagram.kr.

I was able to make it all work as long as I had FluidMFCC.kr, FluidMelBands.kr, and Chromagram.kr all in different SynthDefs.

Do you get the same issue with the official TB1 compile for these objects?

It would certainly be good to invetsigate this, but I’ll need some code to reproduce because it’s not happening for me with my simplest possible interpretation:

{
	var in = In.ar; 	
	FluidMelBands.kr(in); 
	FluidMFCC.kr(in); 
}.play(s)

If this is a subtle hint at wanting a Chromagram in the fluid stuff…I definitely agree with that.

1 Like

you should put that in the right thread :wink:

1 Like

I am pretty sure I don’t have the TB1 compile close at hand. Perhaps you can try with the code below? However, I’m pretty sure it’s not a Fluid bug!

Here’s what I was up to. I think I’ve narrowed it down and I think it’s not a Fluid tools thing, but a problem with the `Logger.kr’ UGen in SC.

The problem I was experiencing only arises If I take the mfcc analysis and the melbands analysis and concatenate them into one array and try to write it to a buffer using Logger.kr. However it doesn’t crash at all if I use RecordBuf.kr instead. It also doesn’t crash if the vector is still concatenated but shorter.

It seems to be that Logger.kr as a max vector size it can take and if one provides a vector that is too long it crashes.

Sorry for jumping the gun and enlisting you guys!

(
Task({
	var osc_actions;
	var analysis_buf_path;

	SynthDef(\test_nrt,{
		arg analysis_buf, t_log;
		var sig = WhiteNoise.ar;
		var mfcc = FluidMFCC.kr(sig,40);
		var melbands = FluidMelBands.kr(sig,maxNumBands:40);

		// this will make it crash in NRT but runs fine on a server in real-time:
		var vector = mfcc ++ melbands;
		// but swap it out for either of these and it won't crash
		//var vector = melbands;
		//var vector = mfcc;

		vector.size.poll;
		Logger.kr(vector,t_log,analysis_buf);
	}).writeDefFile;

	0.5.wait;

	osc_actions = [
		[0,[\b_alloc,0,1000,80]], // buf num, n frames, n channels
		[1,[\s_new, \test_nrt, 1000, 0, 0, // name, id, addAction, addTarget
			\analysis_buf,0
		]],
	];

	osc_actions = osc_actions ++ 1000.collect({
		arg i;
		var time = i + 2;
		[time,[\n_set,1000,\t_log,1]];
	});

	analysis_buf_path = "%%_analysis_buf.wav".format(PathName(thisProcess.nowExecutingPath).pathOnly,Date.localtime.stamp);

	osc_actions = osc_actions ++ [
		[1002,[\b_write,0,analysis_buf_path, "WAV", "float"]],
		[1003,[\c_set, 0, 0]]
	];

	Score.recordNRT(
		osc_actions,
		outputFilePath:"/dev/null",
		options:ServerOptions.new.numOutputBusChannels_(1),
		action:{
			s.options.device_("Scarlett 6i6 USB");
			s.waitForBoot({
				Buffer.read(s,analysis_buf_path,action:{
					arg buf;
					defer{buf.plot};
				});
			});
		}
	);

},AppClock).play;
)

This code works for me. I did a test with Logger and it barfs at 100 inputs. That must be hard coded or something. Which version of SC are you on?

Sam

3.10.0

Works for me on 3.11. Maybe they fixed something?

1 Like