That would be great if they were intrinsic to datasets. They can be ignored for “long flat generic all numbers” matching, but if you’re wanting to know and/or thin things out, it would be unimaginably game changing.
For the descriptor-based stuff, either the ability to choose what you want so it’s less of an issue in the first place (@output centroid → @output mean, so you have one number and that’s that) or perhaps a dump output/message that lets you know what’s what. This becomes more useful/significant when you get to multichannel audio and/or the stats/flattening stages.
Don’t threaten me with a good time!
I guess what I’m saying is at the moment this stuff is being kept track of anyways. It’s just via channels and indices, which are unpleasant for (most) humans to parse. It’s not like each of these processes (descriptors->stats->select->flatten) are putting numbers in random orders (which would still work in an ML context). The order/position/orientation are all known. I guess I’m craving a way to know what that is that doesn’t require counting indices.
A lot of the interface problems emerge from the fact that buffers (and datasets) can only contain numbers, so the interface “problems” have to work around that (initial) interface decision. Otherwise it would be (potentially) part of the native data structure.
That being said, this can be something that is offered as a flag or as part of an initial dataset creation (and perhaps ignored for buf-based processes, unless you use a dump message as I suggest above, which can just not do for realtime use).