I’ve been slowly building out a GUI that aids in quickly and easily processing svgs for plotting. It uses Vpype to actually do the processing, but wraps many Vpype functions up in easy to use GUIs.

Why?

The main reason I created this is because I typically use a lot of the same Vpype commmands for every file, and I have defaults set so that I usually don’t have to do much of anything except to hit the “Confirm” button.

Why else?

The other reasons that have become clear over time are that Vpype is difficult to craft complex recipes by hand, and having a script that creates the code is a lot simpler in the long haul. Doing things like adding in dipping patterns becomes trivial when presented with a few simple checkbox/dropdown options.

Where?

The code can be found at my github repo. I’m still in the process of updating and improving it, and I plan to do separate blog posts for the different utilities. So keep an eye out.

In most of my digital designs (done in p5.js), I use the random function to assign colors for lines. I have a palette of pre-defined colors that I know work well together, and simply pick from that. Occasionally, I’ll use noise values based on the X,Y coordinates of a given line/shape to determine it’s color, this results in clumps of color that vary with the underlying noise values.

While plotting one of my Flow Fields, I realized on the last layer, that I really liked how it was looking with only partially coverage. The line sorting algorithm had picked out these big chunks of the deisgn, and resulted in some beautiful art!

Recoloring a multicolor design

This gave me an idea of how to color or re-color my designs, using Vpype’s linesort algorithm as it’s base. Here’s the steps I came up with to try and recreate what had accidentally occured.

1. Post process the file with linesort
2. Take one color layer and split it into chunks (three in this example)

   ...
   splitdist 20in \
   forlayer \
   lmove %_lid% "%_i%%3+1%" \
   end \
   ...
   

Playing around with the number of layers and the split distance can give varying results, but the important thing is the lines are now grouped into layers based not on some random value, but by how close the start/end of the lines are

Recoloring a single color design

Here’s an example of using the above code to recolor a single-color flow field design into pleasing clumps of color.

Base design:

Design if there to use random CMY colors:

Design after using linesort and splitdist:

While both look nice, I like the grouping provided by the linesort/splitdist a little more, I think it looks more organic and adds to the flowy nature of the design.

Flow fields are two dimensional Perlin Noise fields, and to my mind, often considered passé in the generative art community. Perhaps because of that reason, I’ve been avoiding them for some time. A while back I played with the flow field code from The Coding Train, but I never did much with it.

With all the work I’ve been doing with Perlin Noise generally, something clicked with me and I understood how to make a flow field using my own code, and not with the templates I’d previously seen. It always makes more sense when you do it for yourself.

My flow field code is simply rows/columnns of points, and then per point, a number of iterations move in the direction of the angle given from the noise field. These iterations are the vertices in each line. I experimented with random point placement, but enjoy the coverage of the grids/rows, and I could always offest those by a random displacment to make it less regular looking.

Here’s the first one I plotted, using Lyra Aqua Brush Duo watercolor markers on smooth bristol.

As per usual, you can find my code on my github.

I have used Saxi for a long time to control my AxiDraw pen plotter. I’ve found Saxi’s user interface to be easy to use, its allowed me to stay away from Inkscape (yay!), and you can easily select layers or colors to plot individually. Additionally, I have it running on a Raspberry Pi, so it’s not tethered to my desktop computer!

The Problem

But, there are some files which are too large, and simply fail to start plotting. For me that seems to happen around plot times of 2 hours. Looking at the output from Saxi, I see:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory Aborted

Likely this is a Raspberry Pi memory issue, and not a Saxi issue, as I haven’t heard anyone else complain that it fails on longer plots.

But I think we can develop a workaround! Using Vpype, I will split a single color file into equal n layers. This is an operation I could do in the design within p5.js if desired, but seems like a good general purpose solution when I run into this particular problem.

The Recipe

Let’s try and hard code a small and easy demo to use with Vpype.

vpype \
eval "%num_layers=int(input('Number of Layers: '))%" \
read -a d -a points --no-crop 'Demo.svg' \
forlayer \
lmove %_lid% "%_lid%%num_layers+1%" \
end \
linesort \
show

Let’s step thru this code and explain it piece by piece:

1. eval…
   1. Using the python input function, we ask the user for the number of layers to split the design into, and store that variable for future use.
2. read -a d…
   1. Here we are reading in our file and sorting into layers based on attribute “d” which is the SVG attribute for path information; and “points” which is the standard attribute generated by Vpype. I’m not sure these attributes are exhaustive, but it’s done a good job with the files I’ve tried so far. As long as we don’t have any duplicate paths, each path will get it’s own layer.
3. forlayer
   1. A Block Processor command, this loops through every layer in the design we just read in. It needs an end command to mark the end of the for loop.
4. lmove
   1. This command moves the current layer to a new layer.
   2. Normally, the percent sign is used in expression substitution in Vpype. But in addition to the outer %s for expression substitution, we are also using the percent sign as the modulo operator by using two percent signs in succession, one escaping the other. Lastly, we are adding one to the result of the modulo operation, as Vpype does not accept layer ids equal to zero.
   3. In this example, we expect to see _lid = 1,2,3,4,5,6… and the new layer id to be 2,3,4,1,2,3… in response. It only irks me slightly that we don’t start on layer 1, but it doesn’t really matter.
5. linesort
   1. We’re sorting the lines here, as any previous optimization is likely no longer as effective.

Imperfections

The only real issue with this workaround is the need to manually start each new layer. Ideally one would be able to press play on a four hour plot, rather than need to press play on 4x one hour plots. Likely a more robust solution is needed, especially if I transition to a larger plotter. Another issue is that the plot time increases by a decent amount since I can’t optimize across the whole design.

For a long time now, I’ve used a custom scale factor which, applied to certain parameters, allows me to easily scale up/down a design to a desired resolution. But this always was under the assumption that the aspect ratio of the design (ratio of canvas width and height) would remain about the same.

For the most part, I’ve created square designs, and in doing so haven’t always been great at differentiating between the width and height because it was always the same!

Recently I introduced new parameters to my p5.js framework:

smaller_base and larger_base: the unscaled pixel value of the smaller/larger canvas dimension

This requires a fundamental rethinking of how I design my sketches. For example, if I was to create a square centered in the canvas, I might say:

  rectMode(CENTER);
  translate(width/2, height/2);
  square(0,0, width/2);

You might say this is good enough! It changes when the design width changes, and always stays centered. But what if the aspect ratio goes from 1:1 to 4:1?

Hmm, not really what we want out of this sketch, we wanted to see a square centered, and while that’s technically still what’s happening, the square is getting cut off.

Let’s add our new variables for smaller and larger base values in our setup function and assign them programmatically.

let smaller_base, larger_base;
function setup() {
  const base_x = 400;
  const base_y = 100;
  createCanvas(base_x, base_y); 
  smaller_base = base_x;
  larger_base = base_y;
  if(smaller_base > larger_base){
    smaller_base = base_y;
    larger_base = base_x;
  }
}

Now how does that handle our 4:1 ratio?

Much better, what about a 1:4 ratio?

Perfect!

For me, this is going to require rewriting some of my earlier code, but it will be worth it when I want to generate a phone wallpaper from a square design, and not have to write code for specific size or ratio based corner cases.

See and edit the code used for this example here.

I ran into an issue when implementing the Grid command in Vpype. When pulling in multiple files, it would often place them onto the same layers, thereby overwriting whatever color was assigned to that layer. In multi-color plots, this was a problem!

Grid Recipe

Here’s my solution for maintaining colors in a multi-color svg file when laying out on a grid. The gist of it is to place every layer of the incoming files on their own layers, so nothing gets combined or overwritten.

vpype \
eval "%layer_count=1%" \
eval "files=[r'Demo1.svg', r'Demo2.svg']" \
grid -o 4.25in 5.5in 2 1 \
	read -a stroke %files[_i]% \
	forlayer \
		lmove %_lid% %layer_count% \
		eval "%layer_count=layer_count+1%" \
	end \
end \
layout -l 8.5x11in \
show

Recipe Breakdown

So let’s walk through what’s happening here, step by step.

1. eval “%layer_count=1%”
   1. layer_count is our loop variable, and since layer id values (lid) begin at 1, we’ll start this at 1 as well.
2. eval “files…
   1. This describes the paths to our files. I typically use a python script to populate this line.
3. grid…
   1. We’re using the -o offset flag to specify the size of each cell of the grid followed by the number of columns and rows. So in this case it’s two columns, one row, with each grid is 4.25x5.5 inches. The total size, of the design is 8.5x11.
   2. The grid command is a type of Block Processor meaning it automatically creates a loop and associated loop variables.
4. read…
   1. We’re reading each file by accessing our files variable, at the index “_i”, which is the loop variable created by the grid command. We’re parsing this incoming file based on it’s stroke attribute using the -a flag.
5. forLayer…
   1. Another Block Processor command, this loops through every layer in the design we just read in.
6. lmove
   1. Here’s where the magic happens. We move layer _lid onto layer layer_count (our loop variable from above). This puts each layer read in on it’s own separate layer.
7. eval “%layer_count=layer_count+1%”
   1. Increment the counter
8. layout
   1. Center the design created by the grid command on a 8.5x11” page