Create FluidDataSet on NRT server

New Ideas Pre-Release Toolbox2 New Ideas
1

Greetings,

Is there a way I can create a FluidDataSet on a NRT server in SuperCollider (via an osc message used in a Score)? What could that osc message be? Also, can I write it to a json that way also?

Thanks!

T

2

Never tried, but s_new should do it. Perhaps easiest to capture the OSC you need with s.dumpOSC(1) on a normal sever.

1 Like
3

Thanks for this. I am closer to getting this to work. I find that if I use the Score.recordNRT method I am able to both create a FluidDataSet and write it to json using osc messages (as Score requires). So that’s great!

However, If I do somethings in between there, such as try to FluidDataSetWr it’ll break. In fact I pinned it down to any FluidBuf*.kr type of activity that I try to run on the NRT server will make it so that the FluidDataSet.write osc message at the end of analyzing won’t work (won’t create a json).

Any idea about why this might be the case? Because the FluidBuf*.kr stuff spawns a new thread and maybe that’s a no-no in the SuperCollider NRT functionality?

I know that the FluidProcessSlices runs in NRT, so I could use that––but i’m thinking this would be useful if it’s not audio I want to analyze for a database, but a synth that I could analyze various parameter combinations of (stepping around in a large dimensional space and storing the descriptors of the resulting sounds). I know I could render those combinations to audio and then analyze that, but I did some math and that audio file would be pushing 1 gig, so maybe it’s better to not do that.

Alternatively, I could avoid using the FluidBuf stuff and just use the real-time tools (such as FluidMFCC.kr), but it would be nice to have the Buf tools to also get at the derivatives. Also, I wouldn’t be using the FluidDataSet then, so I’d have to create that from a buffer in another step.

Thanks for your help. Any observations and suggestions are appreciated!

4

Yeah, I suspect the threading messes with the NRT server’s ideas of causality quite badly.

Now, the *kr methods for the Buf* classes don’t expose the argument needed to turn threading off, but it is there in *new1 and, by extension, *multiNew, after the trigger. So, in your SynthDef if instead of doing

FluidBufThingy.kr(<args>)

you did

FluidBufThingy.multiNew(\control,<args>,1)

this should give you the same UGen, but without threading.

1 Like
5

I don’t totally follow what you are doing, but I’m not sure why the 1 gig audio file is a turn-off. I say go down that road.

I was doing something similar in the spring (I think) and it did take for damn near ever, so I understand the desire for NRT.

Sam

6

Cool thanks @weefuzzy , I’ll see what happens.

And, yeah, @spluta you might be right. I’ll try a few of these and see what turns up as being the best option.

Thanks all.