It would be great to be able to apply the
fluid.grid~ transformation on 3d datasets (or even
nd datasets really).
A good use case would be transforming a 3d (UMAP’d) dataset into a space that can be mapped onto a velocity-sensitive/MPE’d controller (e.g. XY + pressure/velocity).
fluid.plotter only shows 2d (so it seems), but the pimped out
fluid.datasetplot~ can show up to 5d, though the usability for this would be more in terms of how it interfaces with controllers and/or external input.
I was trying to think if there’s a way to “fake” it by
grid-ing XY and then YZ separately, then
merge-ing the results or something, but that starts getting a bit clunky.
Don’t know if the underlying algorithm is exclusively a 2d thing, but it would make for a great added feature!
I was thinking this yesterday. I haven’t been able to play with grid yet, but I am following…
I don’t know the algorithm in any great detail, but a quick journal dive seems to suggest that 2D is where most of the attention is, and that even then the algorithms are in cubic complexity (which is a lot), so maybe they’re just intractable in higher dimensions. I’ll see if I can do more reading at some point.
n grid-ing would obviously great, but even just a meagre 3d, a lowly 3d, a humble 3d, if you will, would be amazing.
That would align real nicely with most (available) controller paradigms. Beyond that gets quite niche I think.
If we make a 3D one next you’ll be asking for a 4D grid to project into your AR headset neuro-link. Where does the line get drawn Rodrigo? 5D? 6D?
Hey I’m a 3d kind of guy all the way. The one you have to watch out for is @spluta with his 8d joystick thing!
Lol. But I really just want the 3d because the joystick thing would finally work correctly with it.
You guys. Well, my cursory reading of e.g. https://arxiv.org/pdf/1008.0390.pdf suggests that even actual mathematicians are unsure if practical algorithms with guaranteed solutions for > 2D can be found in the general case, so that’s a definite above-my-pay-grade case. However, you could perhaps approach it as a supervised learning problem with KNN Regressor (and find some way to deal with duplicates / clashes)?
Obviously I have no idea what’s going on under the hood, but I would have thought that a pseudo-normalization + equal-distance-ification would do the trick (albeit likely not as fancily as whatever
fluid.grid~ is doing mathematically).
I’m not quite somewhere for having a use case with this, but do you mean like doing vanilla regression for taking 3d input and mapping it to a 2d output space? If so, what would be ‘duplicates’ and ‘clashes’ in that context?
I think mathematicians need to get on it and figure it out is what I think…whose with me?
Although it’s not useful for a 3d control space, an ok workaround I’m doing is using
fluid.umap~ to get down to 3d, then slicing off the first 2d to feed to
fluid.grid~ then taking the 3rd D to use to project the color space.
Still gives me a nice timbral space to work with, but also has a bit of 3d panache.