even distribution readout of a jit.path which uses spline interpolation
Hi there,
I am looking for a way to lookup 2D points of an interpolated curved path in way so that the points are NOT more dense in the curved areas than in the straight areas.
Its hard to explain in word, so I hope that the attached patcher makes it clearer.
From a creative use case the challenge looks like this : a curved path is created from some 2D vectors via jit.path (e.g.) and its spline interpolation.
Mapping a sequence of notes, a steady rhythm of drum hits, to the entire length of the path (mapping the duration of sequence into the range of 0 to 1) and visualizing each note / drum hit on the path as a circle e.g.
Using the eval message of jit.path with the note-on times (in normalized time from 0 to 1) produces an accurate projection according to the curvature of the path.
As the distance between 2 points become longer if the path between them gets more curved (vector length logic), the equally played drum hits will occur more dense in the curved areas of the path ... mathematically correct, but not visually what I want ;-).
I want to distribute the drum-hits equally on the path, even if this will result in a loss of visual accuracy regarding the curvature.
So I guess its a transformation / translation of the domain of the underlying function : from vector length point of view to "time driven view".
Changing the interpolation mode of jit.path from spline to linear could be one solution, but then I loose "source curvature" information - and I looking for a general approach, which means the interpolated points of the path could even come from other places in the patcher, so jit.path is just an example to make the challenge obvious.
Any ideas how to achieve this ... with existing Max objects or some Gen patching, which could be very efficient, even with large path data using a jit.gl.pix algorithm e.g. - as everything can be mapped into a normalized value ranges (0 to 1) and 4 planes should be enough to encode the data.
as the JavaScript file for the jsui does not seem to be included by "copy compressed" here its in a separate file
you can do this but using the evallength message https://docs.cycling74.com/reference/jit.path#method_evallength
Thanks @Rob ... easier than expected, but still a little bit "off" in the sense what I am looking for.
To be honest, I overlooked the evallength message browsing the online docs during my initial research - my eyes immediately focused evaltime and dropped evallength ... visual perception is sometimes quite strange ;-).
Using evallength is closer to what I am looking for compared to using eval, but if you look at the screenshot, you can see that the interpolated points are still not evenly distributed - this examples uses a resolution of 20 (in the attached & updated patcher).
The 2 orange "staff gauges" are exact copies and hence show that the distance between the interpolated points are smaller along the vertical edges of the rounded rectangle than on the horizontal ones.
Whereby the curvature is stronger on the vertical edge compared to the horizontal one, which points to "vector length" taking spline interpolation and hence curvature into account (jit.path algorithm) to be the reason ... hence the method maybe mathematically correct, but I am looking for a different algorithm.
My aim : let all points have the same "visual distance", even if this results in loss of "curvature information" ... let the orange "staff gauge" match between all points, whereby the length of the "staff gauge" will be different for each resolution and could be the key to solve the challenge.
In a not technical way its : you look at it and you see right away that all points are evenly spaced out.
Maybe its a balanced or weighted mixture of the vector length between 2 points : a) using linear interpolation and b) using spline interpolation ... where jit.gen or jit.gl.pix may come into play using scale or smoothstep to do the "magic".
I saw the time feature of jit.path, but I have no idea which "time value" to set in the first plane of the base points (vectors) before appending them to jit.path - although this feature is great for animation & time-stretching, but that's a different use case.
The jsui JavaScript is still the same (see above).
Even a 2 stage approach using 1) jit.path spline and its interpolation for a polygon approximation into a second jit.path (which uses linear interpolation) and 2) interpolating the linear jit.path for the even distribution of interpolated points along the path does not work as expected.
Has anyone an idea how to achieve this even distribution ? What's wrong in my approach of using jit.path ... I can't see (I got patch blinded ;-).
The attached patcher is simplified and implements the 2 stage approach, but still uses the JavaScript from above for the jsui.
It seems that it's not possible to get an even distributed amount of interpolated points with jit.path, even from a straight line, if the vectors that describe the line (points appended to the jit.path) are not evenly distributed by themselves (are evenly distributed in the first place).
This one is for a new thread, but I leave the results here to give the thread some conclusion ;-).
To see the effect use the attached patcher and :
1) chose "line-2" in the umenu, whose vectors are (0.1 0.5), (0.3 0.5) and (0.9 0.5) ... hence the 2nd vector is placed out of the middle more towards the left
2) chose "eval" or "eval-length" in the umenu ... none of them results in a even distribution of interpolated points
3) click start and see the results in the jsui
Current conclusion : jit.path only interpolates between 2 consecutive vectors ... which is hard to believe that there seems to be no way to do the interpolation across the entire path - so I guess I'm still missing something.
the JavaScript of the jsui is stell the same