Frame Out

[wwderw]

Some commercial software packages have the ability to set what they call a "frame out". Essentially it's a stop point (used in conjunction with stop codes) that is away from where the stitch that has the stop code in it. Mainly used for applique, but I could see other uses like for putting in puff etc.

Only on machines that aren't calibrated to hoops, because it would be possible to set the custom stop point outside the boundary of the hoop.

It would essentially be a series of empty jump stitches (not to be stitched) from where the "stop after" is placed. I think we could approach it like we did for the custom design origin. Used X,Y guide lines labeled say "stop here" (it could be anything really, that's just me being "creative"). It would supersede the location where all "stop after" are used (doesn't matter if it's 1 stop or 4+ stops).

Thoughts?

[lexelby]

Totally doable. I like the idea of using guides for this.

[tatarize]

@wwderw I'm finishing up work on pyembroidery got the main five embroidery formats working. Can you give an example of a file with a stop that isn't a color change. When I got to testing and added a stop command to the mix, everything when fubar and the nifty Wilcom TruSizer thing I use for some examples might work if I had some example of a non-colorchange stop in some format.

In some formats, I'm sure it's going to be the same as colorchange, but if there's actual non-colorchange stops in either pes, jef, vp3, dst, or exp I'm kinda at a loss. I likely could get one made through EO by my brother's out of town.

[wwderw]

I should be able to come up with a simple example later on today.

DST is the only format that I have had success with this out of those 5, so that's the one I'll use.

[wwderw]

See about this one.

A simple circle applique shape with the custom stop above the main embroidery object and does this custom stop after each underlay for the applique.

Custom Stop.zip

[tatarize]

Binary analysis shows that it utilizes 11000011 which is identical to color change. I know when I need a stop in my SWF machine I need to tell it to, at that point, switch from one needle to the same needle again. I won't, however, be able to tell this command stop from a non-color-change. Except, perhaps, by context. If you jumped somewhere else and color changed then didn't stitch then jumped back to somewhere else that's likely a stop. "jump, jump, color change, jump, jump" would by definition be "jump, jump, stop, jump, jump."

[wwderw]

Location. Have to go by the location of where it does all those jumps to the color change as well.

If you are using TruSizer and you have functions turned on, should see the dotted lines (trims) that show it goes for the stop.

[tatarize]

I have the free version circa E3. It doesn't seem to have the features you describe. Mostly use it to view things and convert them. Helps a lot with consistency checking. That and a bunch of stock embroidery to try and convert around. For this project a lossy load seems kind of fine. All loads of embroidery are lossy. It's why everybody makes their own format. So they can save their work, even though you can't exchange that work between programs (a good svg namespace would be a first here though). Some context awareness seems pretty reasonable, but I'll likely have to kick the can down the road a little on that. -- Saving out with the contexts already known however, that's pretty straight forward.

And it might get hinky if some program did a trim and color_change and interpreted that as jump, jump, jump, color_change, jump, jump, jump, it would certainly need to pay attention that those first jumps were +2+2, -4-4, +2+2 and went nowhere and the other jumps were a straight line, to quickly determine that is different that jump, jump, jump that displaces like 100 units, then jump, jump, jump that goes back the other way.

At least here I can just provide a few different tools for making sense of the raw-stitch data and leave it be. Notably if you loaded just the stitch blocks (the set of stitches without the surrounding cruft in absolute positions) you'd totally lose that frame-out thing happening. It would pay attention that there's a new location, track that you apparently wanted a new thread color give the next set of points with a new thread object.

[wwderw]

I have the free version circa E3. It doesn't seem to have the features you describe. Mostly use it to view things and convert them.

I have the E3 version as well (also the free one) and it does have those features.

See attached:

[tatarize]

You're right. It certainly does load the trimmed moves to the top of the screen. It still only uses a color change as best as I can tell. But, again, I can catch that with context.

Gotta finish up the API and then hammer out some of these format issues later. Apparently Vp3 has internal multidesign blocks and some thread color values nobody had managed to solve. And there's a suggestion they have stops that aren't color changes but it might be VP4 format in there.

[wwderw]

You're right. It certainly does load the trimmed moves to the top of the screen. It still only uses a color change as best as I can tell. But, again, I can catch that with context.

Yes, stops are really just quick color changes that on the machine end (at least with Barudan) you set to C0 (which in my mind roughly translates to use same color, but stop at the end).

The key thing is coming up with something that can apply jumps to a user specified location on the fly and do that quick color change, so the user can input a stop. You don't want it to stitch out to that location, so that's why it needs to be all stops.

[lexelby]

Huh... is this a duplicate of #124?

[wwderw]

I think the other time that this was mentioned was in terms of applique as that is the biggest part of how it's used. I got to thinking about it, if we had added a module for applique, even though that's the biggest use case for this functionality, there is at least one other use case for it (puff), so I created it separately to actually try to divorce this from applique support in case it's needed on it's on sans applique.

[lexelby]

Okay, cool. I'm going to close this in favor of #124, and I'll make a note there to ensure that we handle all of the use cases for frame out when we implement it.