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.

[tatarize]

Okay might be working. I got the curved field and I may have the scrunching bug fixed.

However to check the scrunching but I'd need to update pyembroidery since it's located in there and if I failed to fix it, I would have commited a bad upgrade. So I've corrected the bug in a local copy of pyembroidery and launched compiled it into a windows version.

https://github.com/EmbroidePy/MaKe-stitch/releases/tag/0.2.0

That should have the attempt to fix the scrunch bug as well as correcting a wider variety of other issues. Which you'd find in the current branch of Make-stitch.

Now, I treated the curve as y^2 / 75. But, you can manipulate the divisor value so if my guess based on the amount of curving is wrong it can be fixed if you tweak it some. If you're not running windows and can't try the compiled version, I'll need you to get a local copy of pyembroidery and edit the PmvWriter.py line 96 should read:
write_width_lookup_table(f, width_range * 2)

This doubles the overall range which the table sets the half-way mark as the default. This should let you scale these up and down, while having the initial value correct. But, I need confirmation that this is correct before I go committing a new upgrade to pyembroidery that does a change to how a set format works.

I could add back in the buffer around the edge for editing if you want. Or tweak any of the UI stuff I moved around while curving the field. If you mess with the PMV_CURVE value and figure out a better value for it, I'd be happy to update that, or if you'd like an icon and care to cook one of those up for the program including that wouldn't be hard.

But, if you can confirm squish bug is squashed, I'll update pyembroidery's pmv writer and push out a precompiled version of this program here.

[tatarize]

If the linked pre-compiled exe file works without squishing I'll go ahead with all the stuff. Otherwise we'd need other things to prove this change isn't harmful.

Not that I expect many people to care about this. But, I'd be happy to flesh out the Readme and make it clearer what it's doing. So it's a lot less hidden. I'm sure there's plenty of people who would be amazed that this sort of functionality exists in any open-source project. And the exe stuff would make it all a lot easier have people care. Beyond you, me, and Mark (who did the original legwork to help me solve this).

[PlantLily]

unfortunately i use linux so i can't run exe files :( would you be able to update the source code with the compressed files?

looking good though! maybe move things a bit to the right so the numbers are visible?
Also i found it easier to see the mid line when changing it to be purple (#ff00ff), i can just change that myself though.

[tatarize]

The code for the pyembroidery version is here. I guess I could just publish it. Odds are good I could reverse the changes rather quickly if it matters and it would only matter for a basically just you. Nobody else would be using such a thing. Go ahead and try it pip uninstall pyembroidery and pip install pyembroidery might be an upgrade command. shrug

I'll give it a bit more of a side buffer and change that central line color too. But, that's local here rather than needing an update rather than needing much else.

[tatarize]

• Buffer Edge increased.
• Font increased.
• Central line color changed.

[PlantLily]

it looks amazing! thank you so much! could you upload a pic of the icon? i'd like to set up an exec for it locally.

[PlantLily]

update: it seems things come out squished the other direction, stitch on the left is with the current version, the mushrooms are made with the old version:
another feature request: direction arrow to see where the stitch is going

Edit: on second look it looks like it's all scaled down, weirdly enough when loading the mushrooms they appear to be scaled properly relative to the grid... But then exporting it it's all squished, and the width setting on my sewing machine doesn't seem to work, it's set to the max and won't change. Latest version of pyembroidery from pip3.

here's the design itself:

and here's what the machine brings up:

[tatarize]

Hm. I could restore it to how it was before. It might be hard to get that perspective done correctly. The code is told to write a length lookup table, this code is generally ignored as to the actual width used and it writes lengths that are:

write_values = [(0, 0), (10, 71), (20, 143), (40, 214), (60, 286), (80, 357),
                    (100, 429), (120, 500), (140, 571), (160, 714), (180, 786), (200, 857),
                    (250, 1000), (300, 1286), (350, 1429), (400, 1571), (450, 1786), (500, 2000)]

And from that selects item 12 which is the 13th item. (250, 1000) which should give whatever is set a length of 10mm. I am actually unsure what the other value means and I'm not sure if I solved it in any of my notes.

It then writes a width table with values between extending to 2x the current length (this used to be 1x the current length in the previous version). It writes the width half way through the table (which should be correct given the 2x the table) and writes the calculated table for that that I just reverse engineered from the files.

This means that the width should be somewhat close to correct value, but the height might well be always stuck at 1000 but permit adjustments.

I think width is the wideness of the actual pattern and length is step forward each time but I might be misremembering that. Thus the 28000 was the max movement expected of the needle within the head. It's used in calculating the width table.

---

Now it seems that maybe I'm not keeping the aspect ratio correctly. That fixing the width changing to be 2x messed it up and I more-or-less had it right before and set it to the maximum width in that already. If this also breaks the width changes as you're reporting I should likely change the range and just set the initial value to the max.

Also, there's a chance I misremembered how to write the table and I actually write it correctly before and broke it this time. And the original and still problem there is that the values are scrunched because I have the write length stuck at 1000 (10mm) when really I should prefer to set that value closer to the right value, even without giving a different table.

I might have to check my old email chains to see why it was set like that. But, it seems reasonable to think that maybe it's an aspect ratio issue with the length code not actually reflecting the correct length but basically getting locked in to 10mm or so.

[tatarize]

Okay, I took another stab at it. I think last time it was wrong in a kind of weird way. But, it should always make valid tables and valid table selections now. And it will count up the correct length values, though it still won't do anything useful with them. But, it should avoid the weirder scrunching.

Requires update of pyembroidery.

[tatarize]

Also, included the icon, but if you want you could make a better one and I'd be more than happy to toss that into the program instead. Since clearly the icon is really hard to make out, and just kinda weak.

[PlantLily]

Things work now! Back to old squish though, I think the cause of the squish bug is the units aren't 1:1, I created a simple zigzag stitch, from the drawings of the design grid we know that 14 units in the x is 5mm, but 14 units in MaKe-Stitch is 2.5 mm, I think scaling the x axis units internally to twice the size would solve this, I hope im making sense...

[tatarize]

If you adjust the length value to 500, 2000 rather than 250, 1000 does the aspect ratio match correctly?

If you make a very thin stitch along the x-axis, does it squish differently than if you made a very long across the x-axis?

I need to narrow this down a bit more before settling on a solution. 2x might correct the aspect ratio for your current stitch, but does it for most other stitches too? Can I merely use the same lookup table and select the right length?

I assume my 250,1000 setting is 2.5mm per 14 units or so. So 500,2000 setting would be 5mm. At least this is the working theory. So the length of the stitch would need to be correct set in that table to preserve the aspect ratio.

[PlantLily]

So changing it to (500,2000) seemed to set the width in the machine to 5mm, fixing the squish issue, your theory was right! Different length doesn't affect the squish. Also fixed when rexporting the previous stitches.
The only issue I can see with this solution is now the stitch is set to the max length in the machine, so it can't be stretched, and the preview when loading the stitches is still squashed, but functionally everything works!

[tatarize]

I updated pyembroidery again to simply set that initially at 500,2000. If set in the file I believe it should show up correctly initially. I think the only way to get it correct is to know what exactly those numbers mean and preset it with a knowable affine transformation. So if I know I am going to set it at 250, 2000 then I need to scrunch my view by half and give it narrower x-bands so it actually scrunches to 2.5mm correctly. I don't know what that 2000 there means, but I know this is a table.

Is 250 the display value of 2.5mm and 2000 is the real value of controlling something inside the machine?

What does scrunching this value with regard to the y-values do? If I use the full band of 28 and set it to something larger does it stab the presser foot or something weird? What exactly are these values?

Then if I have that understood then I could simply modify the Euclidean spacing in either the x or y position. Giving a field that has x-value and y-value frequency that is able to be set correctly and give a table selection range that is reasonable throughout.

This however, should be good enough with regard to aspect ratios. If you want to go further, I'll need to get a better understanding of what those numbers actually mean. I know the first one is of values on the machine, but what does that second value do? Also what about the default values that set to -- which is (8192, 1000) is that just the real default and the tables are proper modifications or something?

This should work, but working better means filling in some of the unknowns that got glossed over. And would likely mean needing a fuller explanation of those tables.

[tatarize]

mod-tables.zip

Here's some mod threads to figure out the table. In theory each of these will select the 12th item in the length table.
tat-l2-2k - Gives 2000 for every second value in the table. If the second value is the actual width rather than the display width this should make all the values regardless where you set the width be 5mm stitches all.
tat-l2-1k - Gives 10000 for every second value in the table.
tat-l1-500 - Gives 500 for every first value in the table.
tat-l1-250 - Gives 250 for every first value in the table.

[PlantLily]

So they all display the same, however l2-25 seems to be scaled correctly in the stitching menu with the default 2.5 mm length, Here's the results:
stitches.zip

[tatarize]

If they were stitched rather than viewed would it mess things up. Also, if you adjust the values up and down does it change anything. Like if the L1-250 is 250 for everything, when you move that value up and down it should always display 2.5mm but might actually sew at different amounts. And the L2-2k might display different amounts all the way but always sew the same. Depending on how that table works.

[tatarize]

So L2-2k displays the stitch differently there but does it sew differently. Clearly this means the gapping there in the second length value actually does matter for displaying that value, but is that second value actually changing the sew or is it just changing how the sewing is displayed? Since technically the L2-2k is all at 2000 for the second value regardless if you adjust the length up and down.

[tatarize]

So the L1 value absolutely gives that 2.5mm to 5mm selection. Since L1-500 and L2-250 give different values (running up and down through the table would help see if this is the same or different). So does this stuff actually affect the sewing and how? Which number affects what? Is setting that to 2.5mm actually making it 2.5 or does only the L2 value affect that. Also, if you took the L1-250 value and you change the length up and down does the distance between the W (tat-symbols) shift in the display? Like we see in the L2-2000 vs L2-1000? Since in theory changing the length there would have the same L1 value but would be able to switch the L2 values as it moved up and down.

[PlantLily]

So, testing these out, first things first, l2-2k doesn't let you change the length, the numbers change but the output and render is the same; top is default and bottom is settings changed to max length:

Same with l2-1k:

Interestingly enough, l1-500 causes a weird glitch that does let you edit the length, but the machine setting stays at 5mm

Now with l1-250 it causes the same glitch but stuck on 2.5 and not 5(only visually):

[tatarize]

Perfect! This means the second number is the actually important number with sewing and the first number is only displayed. The value given in the L1 spot is purely cosmetic. The number in the L2 spot is the important thing to consider. Locking L1 displayed the same thing but the sewing changed. Locking L2 displayed different things but the sewing remained locked.

Now, with the 250,1000 default it will say 2.5mm and scrunch to about half. Since it really needs to be 5mm. Which means that that 1000 value is the ratio of the internal units to the external values. In order to make 250,1000 correct I would need to have 2x the y-values, with half lengths between them. It also means I should be able to correctly read these positions from the file by reading the table and set value.