So the @history attribute is only for the realtime version as it takes a certain amount of frames in the past and averages them (10 in your case). This is similar to what is happening with the overlapping hop/window frames above where the hop to window ratio and @padding mode determine how many frames are in your “history”.
It’s also different in that it’s zero padded whereas the realtime version is always a rolling window.
It’s worth mentioning that for something like classification/matching like you’re talking about in the other thread a rolling window isn’t ideal as an attack or transient can fall anywhere in the rolling window and/or be over or under represented in the @history. There’s not really anything you can do to make sure that’s accurate/tight, which will impact accuracy with whatever descriptors/stats/whatever you are interested in.
Hence my use of the buffer-based versions, even for realtime use (I just query at a fixed interval).
But in general, there is some massaging to go from realtime to buffer-based but still realtime, to fully offline approach, as the interface and settings/considerations for each is a bit different.