FluidDataSeries....in SC

Development and Maintenance
1

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.

2

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!

3

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

4

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?

5

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?

6

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

1 Like
7

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
8

Hey @mccrmck thanks for this thorough interface poking. I think we should keep it within the other since the questions you ask are not SC but more DataSeries ones (across all CCEs)

in all cases, they are very useful so thanks.

ok maybe we should have called it getPoint - in effect it took me a few look at the code to remember how it goes. It is like DataSet getPoint, but needs the extra argument of knowing when in time it needs to happen. I will most probably change the name now to getPoint, which makes me reply to:

which could be implemented there, although the output would now be the same as get series but with a start and numframes… so I wonder if it is not better to keep it non-existant and use the (amazing) fluidbufcompose to truncate what we need?

9

this is a valid assumption. but maybe we should just remove the t in the printout…

it is - you found a bug!

ok I’ll sort that one.

10

fixed in a new version. thanks!

1 Like
11

Yeah, no need to clutter up the method list if we already have great tools! :wink:

12

Where is this new version? Are these tools on a branch on GH?

13

they are in a PR - I’ll make the interface change discussed elsewhere and I’ll compile new stuff for people

1 Like
14

I can pull the PR. I’m guessing there’s one on core and sc?

15

and one in docs, yes

I’ll change the printing and format and all what we discussed in the other thread later this weekend

1 Like
16

I see now this might be spread out over multiple PRs, so I will indeed wait for your compile…

17

it is a single PR for each feature indeed… but they all have a similar core.

18

Are these compiled yet!? Excited to get my hands on them!

19

they are, and 2 out of 3 classes done

20

but without examples they are not super useful :smiley: