Ideas for sharing pattern parameters #91
Comments
|
That is a really good idea. It would be nice if it was easily readable, and I think keeping the params at the top of the gcode would also be good, but having them as part of the .jpeg is neat. I like it. The one problem with these ad hoc parameters is that it is hard to maintain backwards compatability. I suppose I will usually add features, not remove them, but if I added or changed the interpretation of a parameter, it will be hard to be able to open it in the future website. Especially since there is no easy way for people to just keep the version they like. But the jpeg might just be good enough to justify that. |
|
Presumably, over time the number of parameters is going to expand as more features get added to sandify. Maybe the parameters could be reserved so that they occur in a specific sequence and future versions that add more parameters will add to the list. Maybe the first parameter line in the header would provide the number of parameters that follow, which would make it easy for the parser because it would know how many parameters to read. Or some sort of "end of parameters" code in the last line so the parser would know when to stop. |
|
Wouldn't it be better to just list the parameters as pairs? Name;value. Then they could be stored in any order and ones that have been removed could just be ignored.
Bill
Sent from my Verizon, Samsung Galaxy smartphone
…-------- Original message --------
From: Mark Rehorst <notifications@github.com>
Date: 1/16/20 12:49 PM (GMT-08:00)
To: jeffeb3/sandify <sandify@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [jeffeb3/sandify] Ideas for sharing pattern parameters (#91)
Presumably, over time the number of parameters is going to expand as more features get added to sandify. Maybe the parameters could be reserved so that they occur in a specific sequence and future versions that add more parameters will add to the list. Maybe the first parameter line in the header would provide the number of parameters that follow, which would make it easy for the parser because it would know how many parameters to read. Or some sort of "end of parameters" code in the last line so the parser would know when to stop.
-
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#91?email_source=notifications&email_token=ABM4AOES2ILKD2O6VB4FKH3Q6DB4XA5CNFSM4KHZZG4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJFPZTI#issuecomment-575339725>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABM4AOHX2M7VD5YD3I7ZKJDQ6DB4XANCNFSM4KHZZG4A>.
|
|
It is in javascript, so probably json. But that doesn't matter. What I was complaining about was things like if I change the spin algorithm or how the limits are defined, the old file won't be replicated exactly. Maybe not even close to exactly. So I have been dragging any of that work until we have a lot of it pretty solidified. It is probably fine now. |
|
I added SVG output to the export types. I don't have any plans to import that type, and automatically set up the parameters. But it might be a useful stopgap for you. It is an image file (sort of) and it does have the parameters used in the comments. This hasn't been released to sandify.org yet, but it is on master. |
|
We ended up implementing this in #275 (1.0.0) as a Save/Load .sdf file feature, and pulled all settings out of the other exported file types. |
If I want to share a pattern with someone I can give them the pattern file. If they want to load the parameters so they can modify it to fit their table dimensions or use the parameters as a starting point for a new pattern, they have to open the file with a text editor and manually copy the parameters from the file to the appropriate entry boxes in sandify.
It would be very useful if Sandify could read the parameters from the header in the file so they wouldn't have to be copied manually from a text editor. Maybe have a button labeled "read parameters from file" that would start the process...
I think the ultimate pattern sharing would be accomplished by storing the parameters in the EXIF comments of .jpg images of the patterns rendered on the sandify page that generates them. You could then look at collections of pattern images, select one you like, load it into sandify and all the parameters would be populated to generate the gcode for that pattern. You could then edit it to fit your table, use it as a starting point to generate a new pattern, etc.
This would require being able to render the image as a .jpg file and to store and read from the EXIF parameters of that file.
Here's an example- if you open this image you'll find the pattern parameters stored in the EXIF comments:
I think it might be possible to store the actual gcode in the .jpg file EXIF comments, but that might not be very useful for sharing...
The text was updated successfully, but these errors were encountered: