FluidMLPRegressor killing sound on a server

Bug Reports and Issues Toolbox2 Related Bugs
1

This is related to the feature request I just posted.

I very likely have just hit the “time to get a new computer” wall today (this old girl has done great - but it is time to put her down). When running my entire setup, I am limited to the number of MLPRegressors I can run concurrently. I am trying to run 64 split over two servers. I am only able to get 24 on one server and 16 on another. When I try to add 8 more to the second server, that server just stops making sound. No other synth can make sound on the server either. Sound is dead, though the server goes on like all is well.

Is it possible that there is some kind of a hard limit to the number of MLPRegs that the computer can run at the same time, no matter which server they are on? It seems like the number is about 40.

I have already proved this last paragraph wrong with a test where I just add MLPRegressors to one server, but it is consistent within my performance environment.

Also, once a server stops making sound, that is it. It looks like it is functioning fine, but no sound comes out of anything.

Any ideas?

2

are they fitting or just predicting? again if they are doing nothing, I don’t think they should take any cpu. if they are working then @weefuzzy will know if we have any hardcoded max, but I think it might just be a lot. what is their nn structure, including the activations? this all come to a cost… remember when we had to count the convo reverbs ?

3

This is one of the strangest things, and it took me 3 days of testing to figure this out. I least I think I have.

I think FluidMLPRegressor is stealing my audio busses. It isn’t killing sound on the server, it is just taking the busses where I am sending sounds and causing the output to be silent. I think the way you are allocating the busses inside the MLPReg is hard coded or something, rather than requesting the server for a bus. I am always getting the silence around the 38-43rd MLP regressor, which will kill my output Mixers one by one, from left to right.

What do you think?

4

Figured it out. This one is a real doosy. FluidRTDataClient was doing this:

params = params ++ [\inBus,Bus.control,\outBus,Bus.control,\inBuffer,-1,\outBuffer,-1];

which just assigns control busses starting from 0. This won’t work, especially if there are multiple servers running, where each server has its own stable of busses. Anyhow, this works:

params = params ++ [\inBus, Bus.control(server).postln,\outBus, Bus.control(server).postln,\inBuffer,-1,\outBuffer,-1];

Now the busses are all unique from those already allocated on the server.

Sam

5

Thanks for this. I reckon we can remove the postln? I’ll see if I can squeeze it in yesterday’s release.

6

Yup. That was just my debugging.