Open walpoletim opened 2 years ago
I confirm the behavior.
But this is unfortunately a machine-specific (and program specific) case of scheduling that is not taken care of by the current implementation. The Knit Sketching project was initially targeted at whole garment knitting and thus mostly tubular structures (in most of my cases, ribs were through half-gauge knitting).
In tubular mode, purls are safer to knit if they go back to their original side, because when you knit one part of a tubular structure, having the other side sit across its original bed can lead to the yarn catching the other side (especially if using multiple ends that can separate from static charges).
Thus my base implementation of purl done as a three-part program per stitch. See either the Visual Knitting Programming paper or the implementation related to the stitch layer there.
To make it work, you'd need to have logic that knows whether the sample is tubular or flat to choose between a variant of purl (in Shima, there are different behaviors for link processing, one of which leading to what you describe -- keeping the stitch on its side -- and another moving it between each change of side). You'd also need to check the value of the stitch in the later stage of the program which makes it quite complicated in practice. This is beyond what you'd likely want to try to do.
Instead, a simpler fix is to program the pattern with the Program
tab. For example, see an example that uses purls for radial ribs on a tubular structure from the sweater (and other links-links patterns using purls):
http://w-x.ch/knitsketching/index.html?loadPath=sketches/sweater/sweater.json&init=sketch-mode:schedule,sketch-scale:4mm/5px,click:show-trace
On a flat rectangle, a minimal 2x2 ribs example would be:
const purl = Action.register({
pre: ({ k, n, rn }) => k.xfer(n, rn),
main: ({ k, d, rn, cs }) => k.knit(d, rn, cs),
post: ({ k, rn, n }) => k.xfer(rn, n),
splitBySide: true
});
const ribs = prog.strToGrid(`
kkpp
`);
const height = 1000
prog.filter(s => s.countPrevWales() === 0).waleGrid(0:end, height).tileMap(ribs, {
k: Action.Knit,
p: purl
});
Unfortunately, as you realized, the basic purl implementation gives you a back and forth transfer sequence:
x-stitch-number 0 ;shaping
x-stitch-number 6 ;action
xfer f118 b118
xfer f116 b116
xfer f110 b110
xfer f108 b108
...
xfer f14 b14
xfer f12 b12
xfer f6 b6
xfer f4 b4
knit - f122 1 ;$meta=186
knit - f120 1 ;$meta=187
knit - b118 1 ;$meta=188
knit - b116 1 ;$meta=189
knit - f114 1 ;$meta=190
knit - f112 1 ;$meta=191
...
knit - b6 1 ;$meta=244
knit - b4 1 ;$meta=245
knit - f2 1 ;$meta=246
knit - f0 1 ;$meta=247
xfer b118 f118
xfer b116 f116
xfer b110 f110
xfer b108 f108
...
xfer b14 f14
xfer b12 f12
xfer b6 f6
xfer b4 f4
The simplest solution for your specific case is to register three types of actions through the Action
:
Then you apply the first action in the initial row, the second in the intermediary rows and the last one in the last row:
const startPurl = Action.register({
pre: ({ k, n, rn }) => k.xfer(n, rn),
main: ({ k, d, rn, cs }) => k.knit(d, rn, cs),
});
const purl = Action.register({
main: ({ k, d, rn, cs }) => k.knit(d, rn, cs),
});
const endPurl = Action.register({
main: ({ k, d, rn, cs }) => k.knit(d, rn, cs),
post: ({ k, n, rn }) => k.xfer(rn, n),
});
const ribsPat = prog.strToGrid(`
kkpp
`);
const ribsMap = (purl) => ({
k: Action.Knit,
p: purl,
})
const height = 1000; // sufficient high to cover the whole height
// main ribs
prog.filter(s => s.countPrevWales() === 0).waleGrid(0:end, height).tileMap(ribsPat, ribsMap(purl))
// pre-ribs
prog.filter(s => s.countPrevWales() === 0).waleGrid(0:end, 1).tileMap(ribsPat, ribsMap(startPurl))
// post-ribs
prog.filter(s => s.countNextWales() === 0).waleGrid(0:end, -2).tileMap(ribsPat, ribsMap(endPurl))
// note: the last row at -1 does not trigger proper actions as it is normalized for the bindoff
// => back-to-front transfers must happen on the row before
It looks mostly similar:
But there are two additional program colors (one at the first row and one at the top visible row). And the output Knitout only does transfers as you'd expect. So it's doable, but it's obviously not as user-friendly.
Amazing - That makes perfect sense - Had not got my head around the Program section, but will look at this now in more details..
Some output showing ribbed bottom into a shaped jacquard, and knitted out on a Kniterate Mach9ne - Not perfect but work in progress .
Tim
Hi
Not sure if you are still monitoring your repo but if you are would be great to get a fix...
Knit is setup for Stitch Layer - Knit / Purl.
Write out to knitout causes every row to transfer the back stitches back to the front, and then back to the back. This causes unnecessary transfers and on a kniterate causes dropped stitches due to the constant transfer...
Knitout Visualisation
Knitout Knitout.k.txt
KnitSketching File KnitSketching.json.txt