Multiple FluidStandardize instances crashes server

Bug Reports and Issues Toolbox2 Related Bugs
1

Greetings,

Running these two lines, one after the other, will crash the server. The same thing happens with FluidKDTree. So far it’s not actually getting in my way, but I may need to 2 different scalers at some point!

Thanks!

T

~scaler1 = FluidStandardize(s);
~scaler2 = FluidStandardize(s);

~tree1 = FluidKDTree(s);
~tree2 = FluidKDTree(s);

error message:

-> a FluidStandardize
-> a FluidStandardize
ERROR: ID 0is already being used by the cache
Server 'localhost' exited with exit code 0.
server 'localhost' disconnected shared memory interface
2

Ahem. Whoops. This is, unfortunately, a C++ bug resulting from the time honoured change-my-mind-in-one-place-but-not-in-another software design approach.

It affects not just FluidStandardize and FluidKDTree, but of the models: FluidKNNClassifier, FluidKNNRegressor, FluidMDS, FluidPCA, FluidNormalize, FluidKMeans :sob:

I’ll get this fixed for the next release. Not sure that there’s any language side hack that will work around it in the meantime, but if I figure one out I’ll let you know

1 Like
3

You don’t technically need more than one Standardize because it is just a process and not a pointer to a dataset, but you certainly might need more than one KDTree or KMeans, etc …in fact I am right on the edge of needing more than one right now.

4

After a ‘fit’ or a ‘fitTransform’ the stats are remembered internally allowing you to do additional 'transformPoint’s, so one might want more than one instance. This is how I encountered it!

1 Like
5

You need a trigger warning for reminding me the time I decided to prepend some variables with _ but not others :slight_smile:

6

Along these lines, it would be nice to be able to test if FluidKDTree etc has been freed. I figured out that you can look at the .synth to see if it is nil, but there has to be a better way.

(Right now I need to avoid crashing my whole program because I am accidentally making an extra KDTree, but in the future it would be good to use to avoid making rouge dangling trees.)

EDIT: I once again spoke too soon, though I do think the request stands as valid. But the solution is just to overwrite the tree rather than kill it and make a new one.

Sam

7

Is calling .free on the instance not doing it for you? Trouble is that there’s not a 1:1 relationship between the synth and the tree (otherwise it wouldn’t survive cmd-period). Calling .free will destroy the synth and the background tree instance. IAC, the multiple instances thing is fixed for the next release.

8

I think the way you are doing it is correct.

.free does not release the object. My variable will still point to a FluidKDTree. I can see that the object has been freed only by looking at the synth inside FluidKDTree and seeing if it is nil.

This isn’t inconsistent with other things in SC though:

a = Bus.control(s);
a
a.free
a

a will still point to a Bus.

The issue is with not being able to have more than one of these things, and I know you know that already.

EDIT: You know it so much you already fixed it, haha.