x-speed-number should accept a value of 0
eyeco opened this issue · comments
imo, the extension x-speed-number should accept a value of 0 here (and maybe also undefined, which would be also mapped to 0, for convenience sake?) since this will end up as Black in the DAT format, which is absolutely reasonable: it seems to be used usually as the machine default. Otherwise, I am not sure how I could ever return to default after setting the indices once. Disclaimer: non-Shima-expert here, did I miss something?
EDIT: this answer is the result of misreading x-speed-number as x-stitch-value 🤦
Looking at the help for knitpaint, I see that on SWGN2 a stitch value of 0 means "5 (knit course), 1 (empty course)" -- so I could see an argument for "0" being a useful value if it turns out the backend ever actually outputs an "empty course" (transfer course?). Otherwise x-stitch-value 5 would be equivalent. Though, also, for what it's worth, the backend maintains separate stitch values for transfer passes anyway (hmm, which appears to be 0 by default).
This range/value check is definitely a problem on kniterate, where we use the extension for a raw stitch size value (a single hex digit, 0-9A-F). Admittedly, maybe we shouldn't use the extension for this purpose on kniterate given that it isn't a table entry (stitch might be better, though kniterate doesn't seem to have a concept of "leading" cam set).
Okay, now I see. Indices on the machine are 0 to 15. Values on L5/L6 are either 0 (mapped to machine-index 0) or 11 to 25 (mapped to machine-indices 1 to 15). With x-stitch-value you have to specify the number that's supposed to end up in L5/L6 in KnitPaint, instead of the actual index. So, your "workaround" using value 5 make sense. But: wouldn't it be much more intuitive to being able to specify the actual machine-index in knitout? This is at least what I first thought I'd have to do, e.g. x-stitch-value 7 for machine-index 7 (L5/L6 set to 17).
Oh I totally read speed-number as stitch-value also. Not the best day for github issues use huh?
Yeah, I think x-speed-number does, in actuality, work exactly as you say (see backend code below):
options.L5 = (pass.speed == 0 ? 0 : pass.speed + 10);
options.L6 = (pass.speed == 0 ? 0 : pass.speed + 10);
So this check is just wrong and there isn't anything to debate about it. (Heck, on kniterate, the valid range also includes 0.)
Oh! Okay!
Not the best day for github issues use huh?
That's a definite "no" from my end. ^^
Should be fixed in 70c099c -- now to remember out how to push an update to npm.
As a work-around for this or similar issues, addRawOperation("whatever text you want") can be used as an "escape hatch" to write a line of text into the knitout instruction stream.
Changes published to npm.