FluidDataSeries....in SC

Been playing a bit with these new toys: New Object Early Community Build #3 and 4-5-6: FluidDataSeries, and DTW-based classification and regression - NOW IN SC TOO and I thought it might make sense to start a thread for the examples, helpfiles, whatever.

The first thought I had was regarding accessing frames with .getFrame - it seems that the identifier arg needs to be a string (consistent with accessing values via .dump while the time argument needs to be an integer?

This, for example will pull out values from ~series:

// assuming ~series is a populated FluidDataSeries, let's say from "2-classifier-example.scd"
(
b = Buffer(s);

fork{
    20.do({ |i|
        0.1.wait;
        ~series.getFrame("199", i ,b,{ b.getn(0,2,{|m| m.postln}) });
    })
}
)

…whereas my first assumption was to use "t%".format(i) instead of i to match the entries revealed by ~series.print. I guess if it’s properly documented, it’s not a dealbreaker, just thinking out loud!

…I could also imagine a .getnFrames method being useful, but this is of course easy enough to add myself if I desperately need it.

Could it be that FluidDataSeries.print is also a bit funky? If I draw two gestures in the “2-classifier-example.scd” FluidPlotter and then call ~series.print I get the following:

DataSeries 22: 
series: 2
cols: 2
18:
         t0:    0.24619   0.11675
         t1:    0.24619   0.11675
         t2:    0.24619   0.11675
       ...
         t7: 9.8813e-3244.9407e-324
         t8:    0.24619   0.11675
         t9:    0.24619   0.11675
36:
         t0:    0.20305   0.76142
         t1:    0.20305   0.76142
         t2:    0.20305   0.76142
       ...
         t9:          1         0
         t10:    0.20305   0.76142
         t11:    0.20305   0.76142

But if I run my .getFrame routine from above, I get the following values:

// identifier: 18
[ 0.24619288742542, 0.11675126850605 ]
[ 0.24619288742542, 0.11675126850605 ]
[ 0.24619288742542, 0.11675126850605 ]
[ 0.24619288742542, 0.11675126850605 ]
[ 0.26395937800407, 0.17512691020966 ]
[ 0.39340102672577, 0.37055838108063 ]
[ 0.78172588348389, 0.75126904249191 ]
[ 0.99746191501617, 0.93147206306458 ]
[ 1.0, 1.0 ]
[ 1.0, 1.0 ]

// identifier: 36
[ 0.20304568111897, 0.76142132282257 ]
[ 0.20304568111897, 0.76142132282257 ]
[ 0.20304568111897, 0.76142132282257 ]
[ 0.20304568111897, 0.76142132282257 ]
[ 0.20304568111897, 0.76142132282257 ]
[ 0.21827411651611, 0.75380712747574 ]
[ 0.43908628821373, 0.62436550855637 ]
[ 0.68781727552414, 0.4340101480484 ]
[ 0.99746191501617, 0.18020305037498 ]
[ 1.0, 0.06091370433569 ]
[ 1.0, 0.012690355069935 ]
[ 1.0, 0.0 ]

I guess the duplicated values are from me moving my mouse too slowly, but are the .print values wrapping somewhere? Or have I misunderstood how to read the labels given by .print?

At the risk of being a nag @tremblap, I wonder if you have any thoughts about these observations? Or if you can even reproduce them?

It’s on my radar - other fires are sadly bigger now but I’m coming

1 Like

All good! Just wanted to make sure this didn’t get swallowed by the void…good luck with the firefighting :fire_engine: :fire_extinguisher:

1 Like