Free Sequential Style Vintage Skins for Repro-1 and Repro-5 (Updated 3-09-25)

[Fannon]

Maybe I'll find a few hours this weekend to build a tool that could help here?

First idea how it could look like:

[mesamask]

WOW that's already looking really sweet
This could end up being very very useful for those kind of tasks! Thanks a ton for even considering doing this

[Fannon]

Ok, then let's try this

Here is the very first version: https://fannon.github.io/online-diff-patch-tool/

TODO: Test if it works properly (help appreciated), enable "share patch" functionality. Maybe add color highlighting for the patch.

[Fannon]

Here is a screenshot of the current state.

[mesamask]

This certainly came unexpectedly and I'd need to dig out some time to really look into it, but I quickly did a first test.
I'm not entirely sure if I'm understanding the concept correctly, here are screenshots to show what I did:

First step:

test1.png

The first step was for the purpose to come up with a patch

Second step:

test2.png

Second step was to apply the patch to come up with an updated skin file.
I've added the (?) because as mentioned I'm not really sure if this is the correct workflow.

But if this is the general concept I'd say this is a really nifty and useful tool for this

Unfortunately I probably won't have time this weekend to look further into it, and apply/test things on an actual skin. But my first impression is that this tool will be really handy for this usecase, thanks again for providing it

[Fannon]

Thanks for trying it out already!

Yes, it's a two step process. Maybe it's better to do a reset in between or to open the tool in two browser tabs.

First step is to generate the patch (like you show).
The second step is to apply the patch (either patch is already in, because of the link or you paste it there manually). Then you fill in your current file and the patched file (middle) will be automatically generated.

Now you copy'n'paste the patched file and try out if it has the desired changes applied.

But be aware that this diff algorithm cannot do magic. There can be conflicts that it cannot correctly resolve. Not even git can do that always and there's some manual resolving to do.

But if you start from the same "original file", there are no potential conflicts and you can easily apply the patch.

[mesamask]

Quite impressive to see in "real-time" how fast you're creating this tool, looks different and more matured with almost every visit

Had time for an actual test with a skin and am afraid I have to report not-so-good news.
Seems the patch is detecting the changes but not really applying them later on. Two screenshots that should explain what I mean, using the "KeyVizColour" as example:

KeyViz_detected.png

PatchApplied.png

"KeyVizColour" only serves as an example, as it's a very obvious one. Guess I also should mention that it's not just in a different location, it's nowhere in the file.
The end result is that a skin with a "Patched File" from step two still looks identical to what it was before.

For reference I'm attaching the three files that I was using, hope they are labelled clear enough.
(.txt files aren't allowed, so I zipped them)

[Fannon]

Thanks mesamark for testing it with realistic files!

It looks like there are so many changes (between 2.1.1 and 2.1.2) that this simpler diff algorithm cannot really do it correctly What's unfortunate is that it just tries and does not give good feedback whether it fails. The git diff implementation is better in that regard (you'll get merge pointers where it doesn't know how to merge correctly).

I've tested with a simpler change and it works, but looks like the changes you have between your files are too much for it. I assumed that you would only add / change a few lines between the original and the changes you want to share.

Having so many changes is something where you'll definitely will then need git and manual resolving of conflicts.

Does it at least work with simpler changes? Here's a link with a patch against your "Hive_orig_v2.1.2": Link

[Fannon]

Ok, it does look like the chosen diff / patch implementation is really not doing a good job here It looks like it can't even handle simpler differences that git could handle automatically.

Looks like I need to look for something better and test it. Not sure I'll get to that today.

[Fannon]

@mesamark: I've tried a different approach but hit a dead end there :/

But I also found an option with the existing approach which should make the apply patch function more generous, with the danger that it misapplies something. It might be worth trying again now.

[mesamask]

I was offline until more or less now, sorry. Did some test runs with the same files and same results like yesterday.

I'm preparing a test with u-he's "ColourCopy" delay now. The latest version (v1.0.2) of the GUI script has 2772 lines, as opposed to Hive's 23156 lines (v2.1.2). I don't know if/how pure length is affecting the algorithm of the tool, but it might be worth testing.
Since I didn't have any resources from ColourCopy v1.0.1 anymore I've already extracted them from a "legacy" installer. In particular to have access to the v1.0.1 GUI script as the foundation. And if it's going to work out better than with Hive I'll probably create a "dummy" skin (just something with a few different colors or so, to have a comparison) from those resources, because I can't find any suitable test objects for ColourCopy.
(But because of family and other things I'm not sure when I got time for it.)

[mesamask]

Same result with ColourCopy. Starting to believe I'm just too dumb to use the tool....

Generated the patch with factory v1.0.1 as "Original File" and factory v1.0.2 as "Patched File". Since there's no custom skin v1.0.1 to apply the patch on, I was simply using the factory v1.0.1 as "Original File" again. Because there aren't any intentional differences it should result in an identical file to the factory v1.0.2 as "Patched File". But it's not, when comparing in Notepad++ it's identical to factory v1.0.1

Attaching the two files again

[Fannon]

I think the problem is that you have too many changes that are to close to each other. Creating a patch will always work, but then the patch will only work if the original file is basically equal to your original file.

What you seem to want to do is to merge in changes into a file that has already diverged a lot from the original file the patch was created from. This is tricky and very likely you will need something like Git + manual conflict solving to make it work.

I'll probably have to keep the tool now as it is. I hope it works for the simpler use-cases (like sharing some changes you did to the most recent version of a preset).

[mesamask]

... I'll probably have to keep the tool now as it is. ...

No worries Fannon, you've already put way more than enough work into it! The fact you were even considering creating the tool with that context in mind is already awesome and very much appreciated
And just because it didn't work out too well for this very specific usecase certainly doesn't mean it wouldn't be useful for many other tasks. You also mentioned there's only one similar tool out there (the one you linked to earlier), so it's a bit of a market gap anyway.

And I still think it will be useful for more specific tasks in the context of updating/creating GUI scripts. For example I don't think there's a faster way to come up with an overview/list of changes between versions.
Paste v1 and v2 in and you instantly got an overview of the differences in the Patch segment. Doesn't even require a single mouse click. Copy-Paste it into an editor and you always have a nice list at hand you can work with.
So that's already one practical usecase in that context, and I'm sure there's more of them.

Thank you very much, Fannon!

[jtsterays]

This should be the default skin, or at least included natively.