Add `move_to` method for Path

[charlesneimog]

Hi @agraef and @timothyschoen , happy end of 2024! 😄

I'm working on developing a library for handling simple scores using pdlua. https://github.com/charlesneimog/pd-score

I’m rendering music glyphs using the Bravura font and the d attribute for SVG path data (you can check out more details here: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d).

It works well, but I’m missing the move_to function on pdlua api. It’s essentially meant to move the cursor to a new position without drawing anything. I’ve tried implementing it myself using c, but I don't know anything about Tk, plugdata or PurrData.

For now, I’m using line_to, which almost works on low resolution but not or higher.

Here’s an example of what I’m seeing:

Pure Data

PurrData

Plug Data

Obs.: Create a new Path() does not work because the fill becomes wrong!

I believe this would be amazing not just for score, but would be possible to draw anything from svg.

[ben-wes]

@charlesneimog cool project! and would certainly be great to make svg drawing simpler that way (i tried to do that in a more complicated way by translating the svg paths to pdlua paths in https://github.com/ben-wes/pd-dualsense/blob/main/dsshow-shapes.lua )!

just adding this probably not surprising findings:

• these glyphs are drawn by drawing paths inside other paths - so svg is doing an implicit boolean subtraction in that case if there's an overlap? anyway ... quite nice that this basically works already for all flavors!
  

@agraef : i just realized that https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html doesn't mention the path drawing at all yet. i could make a draft for at least mentioning these methods briefly? or should this stay part of the help files only?

also, @charlesneimog's code made me realize that currently, pdlua's help mentions close_path() instead of close(), which is wrong.

[porres]

wow, this would be really cool :) time to make a CAC tool for Pd like Open Music!

@timothyschoen can you tackle that for the next update?

[timothyschoen]

I wonder: if you're only drawing the path instead of filling it, couldn't you just create a new Path instead of move_to?

The difficulty with a move_to function is that it would need to function correctly for drawing and filling. And filling a path with a hole in it might not be simple

[charlesneimog]

I don't thing so @timothyschoen, mainly because of the subtraction that @ben-wes was talking about (I think).

This is the result for when I try to create a new Path

--x, y = params[1] * scaling, params[2] * scaling
--p:line_to(x, y) -- NOTE: Should be move_to
x, y = params[1] * scaling, params[2] * scaling
p = Path(x, y)

The comment lines are the current implementation!

[ben-wes]

@charlesneimog that's what i meant, yes. svg's default is the nonzero fill-rule which will create a "hole" if the inner shape is described in the opposite direction; and there is evenodd, where the direction doesn't matter and it depends on the amount of layered shapes:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/fill-rule

move_to itself might not be the critical feature here if the same behaviour could also be achieved by closing the current path and subtracting another one from it. not sure how complex that would be though.

[charlesneimog]

@umlaeute, sorry the mention, but you can think in some solution for Pd? For now, pd-lua creates a polygon in Pd, this works, but there is these lines when using line_to instead of move_to.

Here's how polygons are drawed now.

pd-lua/pdlua_gfx.h

Lines 1397 to 1406 in 4301f74

	#ifndef PURR_DATA
	pdgui_vmess(0, "crr iiii ri rs rS", cnv, "create", "polygon", 0, 0, 0, 0, "-width", 0, "-fill", gfx->current_color, "-tags", 3, tags);
	sys_vgui(".x%lx.c coords %s", cnv, tags[1]);
	for (int i = 0; i < path->num_path_segments; i++) {
	float x = path->path_segments[i * 2], y = path->path_segments[i * 2 + 1];
	transform_point_float(gfx, &x, &y);
	sys_vgui(" %f %f", (x * canvas_zoom) + obj_x, (y * canvas_zoom) + obj_y);
	}
	sys_vgui("\n");

[umlaeute]

i'm not entirely sure what you would like to achieve.
how would a filled path with a "broken line" (afaiu, the suggested move_to would allow for a single path to be broken into independent segments) look like?

---

as a sidenote: you should really try to get rid of all sys_vgui() calls for the Pd-backend, and something like this instead:

t_float transformed_path_segments[path->num_path_segments*2];
for (int i = 0; i < path->num_path_segments; i++) {
    float x = path->path_segments[i * 2 + 0], y = path->path_segments[i * 2 + 1]; 
    transform_point_float(gfx, &x, &y); 
    transformed_path_segments[i * 2 + 0] = x;
    transformed_path_segments[i * 2 + 1] = y;
}
pdgui_vmess(0, "crs F", cnv, tags[1], path->num_path_segments*2, transformed_path_segments);

(the code is probably not portable, but you get the idea)

[timothyschoen]

as a sidenote: you should really try to get rid of all sys_vgui() calls for the Pd-backend, and something like this instead:

t_float transformed_path_segments[path->num_path_segments2];
for (int i = 0; i < path->num_path_segments; i++) {
float x = path->path_segments[i * 2 + 0], y = path->path_segments[i * 2 + 1];
transform_point_float(gfx, &x, &y);
transformed_path_segments[i * 2 + 0] = x;
transformed_path_segments[i * 2 + 1] = y;
}
pdgui_vmess(0, "crs F", cnv, tags[1], path->num_path_segments2, transformed_path_segments);

(the code is probably not portable, but you get the idea)

I was unaware that capital F allows you to pass in a list of floats directly! That's very convenient, I'll start working on moving to pdgui_vmess.

I tried using pdgui_vmess in the past, but without knowing about "F", I formatted all the float coordinates myself with snprintf, and that ended up being very slow (allocation, overhead of calling it many times, etc.).

[timothyschoen]

On topic: I've looked into it a bit, and I think it might be easier to create a "drawSVG" function that could take either svg as text, or a file path. I just tried implementing move_to and fill rules myself, and it's not going very well.

If we add svg rendering capability that way, we can just use nanosvg to convert svg into a bunch of bezier curves. That way, we can (hopefully) let nanosvg handle the fill rules for us, and you'll still be able to draw notes.

[timothyschoen]

SVG rendering with pdlua in pure-data!

Turns out path intersections are gonna be too difficult to figure out in tcl/tk in the end.

The way svg rendering right now is a bit of a hassle, but it does work:

• First parse and rasterize the svg with nanosvg
• Convert the bitmap data to png using spng
• Encode png data as base64
• Send it over with pdgui_vmess

I also create a hash of the svg text, so we can check if we've already sent the image over, and make sure we only send it once. For purr-data and plugdata there are probably easier ways to do this, so I figured I'd start with pure-data.

Right now, you can draw svg like this:

local svg_icon = "<svg width=\"64\" height=\"64\" fill=\"none\" viewBox=\"0 0 24 24\" xmlns=\"http://www.w3.org/2000/svg\"><path d=\"M12 1.998a2.5 2.5 0 1 0 0 5 2.5 2.5 0 0 0 0-5Zm8.344 4.518a2.01 2.01 0 0 0-2.612-1.255l-1.607.6a.75.75 0 0 0-.415.381 4.086 4.086 0 0 1-7.386.01.75.75 0 0 0-.415-.38l-1.63-.608A2.007 2.007 0 0 0 4.816 9L8 10.31v3.148l-1.971 5.713a1.956 1.956 0 0 0 3.682 1.321l1.31-3.519a6.505 6.505 0 0 1 4.979-5.8v-.861l3.195-1.307a2.01 2.01 0 0 0 1.149-2.489ZM23 17.5a5.5 5.5 0 1 1-11 0 5.5 5.5 0 0 1 11 0Zm-2.146-2.354a.5.5 0 0 0-.708 0L16.5 18.793l-1.646-1.647a.5.5 0 0 0-.708.708l2 2a.5.5 0 0 0 .708 0l4-4a.5.5 0 0 0 0-.708Z\" fill=\"#212121\"/></svg>"

g:draw_svg(svg_icon, 32, 32)

[charlesneimog]

@timothyschoen had you pushed this somewhere?

[timothyschoen]

Just pushed it here: https://github.com/timothyschoen/pd-lua/tree/render_svg. Only tested on macOS so far though!

[umlaeute]

as a sidenote, it seems that TclTk-9 (well, 8.7 really, but I don't think this makes much of a difference) supports SVG rendering natively (afaict also via nanosvg).

i don't we could expect Pd to switch to Tcl9.0 soon, but that shouldn't keep you from using it if it is available :-)

[porres]

i don't we could expect Pd to switch to Tcl9.0 soon

you what? :) You don't "think"?