stitches come out upside down

[PlantLily]

wonderful program! works fantastically, but unfortunately the output is upside down, they appear to be mirrored along the x axis. image is attached.
Also, would it be possible to colour the lines a black and a lighter gray alternating? And have a red center one, would make it easier to not get lost.
and maybe numbers for the rows/columns?
thanks!

[tatarize]

I finished the main changes to the interface. The upside-down bit might be an error in the formatting. Specifically the code for the y-level might actually need to be inverted. I dragged a few traditional embroidery objects into the MaKe and the loaded up with the correct side up. Which means it's likely any saving is the result of the pmv writer error. I seem to recall when going over this with MK originally it might have been raised at that time. And just forgotten in the intervening two years. I'll make double check based on some old original pmv files I might have as to which direction they should load and save.

Check if the currently requested UI changes are as you intended. I made a different branch for them.
https://github.com/EmbroidePy/MaKe-stitch/tree/dev-0.1.0

[tatarize]

• And numbers for the rows.

So I only really saw a lot of geometric stuff here.

This might rather be flipped x-axis.

Yeah, this seems like it is. I'll double-check a few things before y-flipping the reader and writer.

[tatarize]

Okay I updated the pyembroidery version and flipped the read and write output to match the typical coordinate data types for the rest of the system. I hadn't noticed that they were flipped since I didn't do much beyond getting Mark to confirm it was working.

You'll need to update your pyembroidery version to greater 1.4.22+ to correct the flipped issue.

[tatarize]

Okay, check the functionality in the new branch. And if you think it meets your issue. I'll merge the data and produce a version and an .exe (I've gotten more able to make things over the last few years).

I doubt the market for this program is more than like 5 people right now. So I'm not going to turn the whole interface into a properly zooming one etc. I would however be happy to make a pre-compiled windows version of it since like 4/5 people likely couldn't launch the python code.

[tatarize]

https://github.com/EmbroidePy/MaKe-stitch/tree/dev-0.1.0

[PlantLily]

This is wonderful! Than you! Maybe only have multiples of 5 on the horizontal scale? It might get a bit crammed. May be a small market but this is greatly appreciated!

[tatarize]

Okay, less crowded along the horizontal.

[PlantLily]

Amazing! Thank you so much!

[PlantLily]

so, since i couldn't find a copy of brother's design template, i made my own! here you go! CC0 so anyone can use this as they wish :) linky

also I found out the scale is off, should've mentioned it in the op, but it seems that the designs they were squished length wise, by a factor of 2, i made my templates to accommodate that. but do you think it'd be possible to have a switch to scale it to be the proper length? granted i do like the extra y detail

[tatarize]

I think this is selectable by the machine itself. There's a series of numbers at the end of the file that selects the width and length a bit, like these get adjusted as needed. I think the ranges get scaled up and down accordingly to make them properly fit. For whatever reason this is selected (250, 1000) which might be 10 mm and 2.5 mm or some other unknown number. I'm not sure that this couldn't be tuned in a bit better but I think it might be whatever the width is it gets scrunched to the same length. But I'm honestly not sure. I write the length lookup table that I thought would work. In theory you can adjust this in the machine.

Also, this sheared pincushion effect for the graph paper might matter. I didn't see this happen in any of the given sewouts I saw so I couldn't confirm that the extents in the various direction needs a forward amount to draw the straight line. In theory it would take moving the actual locations of the points but I could map it to the pincushioned data. My guess was that as the feed dog went forward moving the needle out took some time so you'd end up with this sort of bend, and the coordinate system was an attempt to counter-act that effect.

I should be able to toss in an x-scaling factor to use but this wouldn't be written into the file itself. As I think it tends to just uses (250, 1000) and provide the other options. I do not actually know precisely what this does. But, it should be adjustable in the machine. So going forward to (300,1286) or down to (200, 857) I think the second number is 10th mm.

[PlantLily]

It is selectable by the machine, but because the default is 2.5, scaling it to the max(5) yields the results you draw up, would be nice to have it scalable as well as seeing the results you expect without doing anything.

The pincushion definitely has a real effect on things, I think it's caused by the needle movement horizontally, if you look at the decorative foot the opening is also curved the same way, might have to do with the mechanics of how the machine moves the needle.

The (250, 1000) is the length scaling of the stitch, when selecting the stitch it lets you change that as well as the width, which unfortunately is capped by the machine. If you need help figuring things out I'm more than happy to test things out for you

[tatarize]

Yeah, trying to adjust this stuff to properly curve. I think I may have identified the scrunching bug, but it'd take another change to the reader I think and I'm reviewing my old notes to see why everything's getting multiplied by 2.5 it might actually just be 2.54 to convert it into English units or something. I'm pretty sure it was a conversion from native into non-native units for pyembroidery but it's making a lot of the math weird.