Import palette

[lindehell]

How about the ability to upload a txt file with your personal palette? Each line could just be like: H13 S77 S78 S158 Etc.

That way you done have to uncheck every color you don't have. And you don't end up with a pattern containing H25 translucent brown by mistake that is not on the market anymore.

This would be huge, at least for me and just as an option so people can do it the old-fashioned way as well.

[maxcleme]

Hey, first of all, thanks for putting feedbacks and idea here!

I already had the idea of letting people adding their own palette, but not really in the same way as you described. Let me try to explain how I see potential futur feature, based on what you need.

First of all, if I understood correctly, what you want is ultimately being able to save your current selection, not really load an additional palette (which in your case, contains already defined colors, since their is no color code associated to it). Anyway, I think being able to save your presets, either locally in your browser, or externally as a file, so you could load your own presets elsewhere, could be a REALLY nice feature!

Now let's speak about custom palette, which could also be a great feature, however file format needs to be well designed. What I mean is, how it will be formatted? Is it plain text, or more like a .csv? How are you supposed to describe color code? Hex? Rgb? Why not HSL or LAB then? Or even CSS synthax? Am I able to design my custom palette directly from the website (would be sick!). Then we would have to deal with conflict, what happened if my custom palette contains a H71 entry? Would leads to conflict with the Hama palette if I choose both. Would we allow/forbid multiple palettes in case of presence of a custom one? Anyway, that's too many questions for one feature, IMO it means that it's not mature enough, at least for me. Finding time to enhance this tools is getting harder and harder, and I still have requested feature to implement.

Anyway, don't get me wrong, these two features are really nice enhancement and are in my scope from a long time, and I think they will be implemented in the futur. The first one should obviously come first, it's way more mature IMO.

I just realized I've been overwhelmed by my thoughts, sorry for the long read.

Please, feel free to continue the discussion about these two features, to be sure I'm right about your need and/or develop the reasoning behind them!

Thanks again for feedbacks!

[lindehell]

Thank you for the long answer. My only programming skills comes is in bioinformatics so it's good that you tell me what is realistic when making a tool that others are suppose to use.

What I was thinking is that you have a .csv file with the brands color code in the style of for example "S51". You have these nice underlying lists with hex/RGB and I would imagine end users don't really care about that. They know what beads they have in their little drawers. Might be something for the far future with totally custom pallets, but to me that feels like some other random pixel art software.

Would it be possible to have two additional pallets in the list or hidden, one "Custom Midi" and one "Custom Mini" that contain all brands and all colors and when you upload a file with brand names (S78 etc.) these pallets are automatically selected with the colors in the file selected. If you go this custom route, then the other pallettes (the ones you have now) could even be hidden and you just work with these "Custom Midi/Mini". To avoid conflict between mini and midi you could have a check marks beside the upload buťton for what size you want to upload. Then if people want they could even have one big file with both sizes and only the ones of the size that you ticked of before uploading will be selected.

Feels like I'm missing some of the reasoning with potential conflicts from your answer.

So glad you listen. I find your program amazing and before discovering your GitHub page by accident I was paying for another app that is all fluff and no substance (like yours) would like migrate entirely to your program and the features I have been bombarding you with is just my ultimate wish list to be able to do that.

So long answer right back at you. Your doing great, keep it up.

Cheers Henrik

[maxcleme]

Thank again for additional feedback and idea, I'm going to go through all of them, in order to extends a bit my POV of these.

What I was thinking is that you have a .csv file with the brands color code in the style of for example "S51". You have these nice underlying lists with hex/RGB and I would imagine end users don't really care about that. They know what beads they have in their little drawers.

I would like to insist again, but IMO what you need is a way to save your current selection of colors/palettes instead of loading a file. I mean, if you are OK with creating your own file, in respect to whatever format it needs, then load it into the website, why not being OK with only selecting relevant colors in the website, that's it. The issue raised is I guess because your presets is not save, so you have to select again only the relevant colors when your re-open the website.

To be honest, I'm exactly in this situation, I mostly do grayscale patterns, each times I start a new project, I need to disable all Hama colors and then only enable 5 colors. What would save me time is that my current selection is saved in the browser so I don't have to do it again the next time.

Might be something for the far future with totally custom pallets, but to me that feels like some other random pixel art software.

Agree with this, but being able to load whatever color codes you want could solve at least two frustrations :

• I think Hama H71 is not darker/lighter enough, how can I correct this ?
• I live somewhere when the brand I used is not present here, how can I correct this ? Even if I want to contribute to this, I still would like being able to test beforehand.

IMO full custom palette is something that could be useful, and not necessarily far from beading.

Would it be possible to have two additional pallets in the list or hidden, one "Custom Midi" and one "Custom Mini" that contain all brands and all colors and when you upload a file with brand names (S78 etc.) these pallets are automatically selected with the colors in the file selected. If you go this custom route, then the other pallettes (the ones you have now) could even be hidden and you just work with these "Custom Midi/Mini".

I liked the idea of having an entry for the custom palette, but why not even make the structure of loaded file containing the name of the palette ? I mean, if I want to split my custom palettes into a mini and a midi one for whatever reason, I could still do it.

To avoid conflict between mini and midi you could have a check marks beside the upload button for what size you want to upload. Then if people want they could even have one big file with both sizes and only the ones of the size that you ticked of before uploading will be selected.

Again, it could be already defined in the loaded file, what why I have many questions regarding its structure. However I would like to argue by saying that mini/midi is not related at all with palettes (which is how it is implemented right now, palette define only colors codes, that's it), mini/midi is only something I use to change the size of the boards and the rendering size, but you can ultimately use Artkal Mini palette over Midi board, of course it is not doable in the real world, but I didn't bother with it, and I think I should not.

So glad you listen. I find your program amazing and before discovering your GitHub page by accident I was paying for another app that is all fluff and no substance (like yours) would like migrate entirely to your program and the features I have been bombarding you with is just my ultimate wish list to be able to do that.

Really honored by this, I started this project for my own, then I wanted to be able to use it online, but if people are trying to enhance it by giving out idea, I will be honored to investigate them and trying to implement them as well if they makes sense (already done few of them).

Cheers!

[Tryk47]

Hi I really support the idea of "saving" the choosen palette to use later. !! in my opinion it would both support lindehell's requirements and other requirements as excluding transparent beads, Neon, metal or clear etc. /Tryk

[maxcleme]

Thanks for reviving this 4 years old issue! IIRC the plan I had in mind in the past was to generalize a bit and offer the feature of saving/loading "presets", which would be broader than the palette itself. When I was beading quite a lot (and developing both beadcolors & beadifier for my own needs), my presets was always the same, same boards size, same advanced settings, same palette etc.

I admit I don't really maintain these two projects, unless some very minor works (eg. adding new colors for the community) 😅

[Tryk47]

makes sense to save everything, yes. :) i understand.

what is "beadcolors" ?

[maxcleme]

what is "beadcolors" ?

The source of truth for color used in beadifier, it is just another repo for inventoring all the colors :)

https://github.com/maxcleme/beadcolors (see the description if you're interested consuming it)

https://beadcolors.eremes.xyz/

[gavinhewitt]

I admit I don't really maintain these two projects, unless some very minor works (eg. adding new colors for the community) 😅

I don't know TypeScript at all, otherwise I could perhaps contribute to this awesome tool :-(