interpolation with jit.path for 2D paths
This started off in another thread, but I want to give this a fresh start to get the point : what can we expect from jit.path interpolation when it comes to 2D coordinates of a 2D path.
The docs points out : it is useful for creating user interfaces for parameter morphing, but I try to use it for 2D vector interpolation in the "visual domain", especially an even distribution of 2D points (location vectors) of a path.
My current finding : jit.path always calculates its interpolated values from 2 consecutive vectors of its internal state (the 2D vectors you have added via the append message) and there seems to be no way to get it work across the entire path, which is essential when you want useful results in the visual domain.
The screenshots (made with the attached patcher) shows the problem : if the 2D vectors appended to jit.path are not even distributed by themselves (line-2) you cannot get any even distribution out of it, even if its a straight line, regardless of the evaluation mode you use (eval vs. evallength).
So the questions is - do I miss something ... or are the other Max objects or Gen techniques to interpolate a path of 2D points into an even distribution of 2D points, as you can see for "line-1 & eval" above (but for complex path with curvatures) ?
and the JavaScript file for the jsui as this is missing in the compressed copy
(and for reference - this is the forum thread it started off)
hmm, It looks like evallength only functions with spline type paths (@intermode spline). Are you able to make use of that instead?
@Rob : not really, as spline would disturb the shape of the path.
I think there are 2 cases to look at. What could work is to use a patch embedded jsui based drawing tool (or show it stand alone in a popup window), but then I am limited to the way the "automatic" spline works - which is nice for some use cases (as it is easy to approach), but you cannot get really creative with designing a shape from some points.
The second approach would be to use an external vector graphic and process its point in the Max patcher, but then spline is a no go ... and that's the approach I am aiming for in the end.
So e.g. using a SVG and interpolate its path into an even distributed amount of points (2D location vectors) and from there use jit.path and its linear interpolation to get any location vector in between.
But the challenge is then : how to interpolate the SVG path into an even distributed amount of points.
Well there is a way, but its cumbersome ;-). A while ago I did a "hack around" in a web-browser to get an array of interpolated 2D points from a SVG path.
In a nutshell : load the SVG into the DOM and use the build in browser APIs getTotalLength and getPointAtLength to create the array of points.
So a jweb solution would be possible, but it means a lot of web coding. There are other npm Packages around, but none of them worked the way I expected : svg-path-interpolator was the closest, but you have to code a hack around to use it in a node.script as its made for the browser and uses a Web-Assembly for the SVG parser (although there is also cli version one could start off from), and internally it uses open-source code from WebKit by the way.
On the other hand ... as C74 has put their hands on Chromium ... what about extracting the C++ code of these APIs into a new Max object (jit.svgpath) or extend jit.path with a loadSvg and interpolate message (feature)?
in theory we could load svg-path-interpolator in a jweb script. haven't tried it but probably worth a quick peak. I'll see if I have time, but that shouldn't stop you from your own investigations.
This sounds great @Rob and I would really appreciate if you find some time - and as I saw some requests for SVG processing in the forum, others might be happy as well ;-).
And maybe its even easier to take the node.script route, as the embedded CLI version seems to works fine.
The point is : I have no experience in using Web-Assembly, but they are natively supported by NodeJS, and "CLI version" is executable with node (I tried it with success) - so the "CLI version" is not a binary build.
What seems to be the only difference between the web browser & the NodeJS version, is how the .wasm file is loaded.
The web browser version uses the web browser only fetch API, see line 4.
The CLI NodeJS version uses the fs package of node, see line 26
So once loaded, its transparent in its usage and as Web Assembly seems to be supported since earlier versions of NodeJS, this should also be fine for Max 8.
The nice part of this would be : if C74 gets this port to node.script done and is able to diagnosis that the Web Assembly driven NodeJS script runs stable, it would also open doors for other workloads & coding techniques in Max ...
... as their some interesting Web Assembly solution out there, like e.g. Microsoft has developed a Web Assembly driven .NET runtime, which means we could use / integrate C# code in the future without taken the jweb route (why using a web browser when we need no UI, but just want to execute some algorithm that does stuff for us).
Not that I am aiming for that, but shows the potential.
+++
For sure, my own investigations go own ;-) ... I am still trying to figure out an approach to start things off from modulating a hand full 2D location vectors and create a "path connection" logic for them - creating a sort of organic flow of "interpolated points" between the given & modulated base points.