[F.Rq.] Allow both static and input-bound markers simultaneously

[RetroEdit]

The "Bind markers to input" setting in TAStudio is clunky. Both frame-static markers and markers bound to inputs are useful. I find myself just keeping the checkbox on since I generally TAS sync-friendly games and use markers as a sort of "self-adjusting bookmarks" system that can account for insert/delete frames earlier in the movie. But markers can also be useful as a measuring stick to say "previously XYZ happened on this frame". The bind markers setting also changes how branches work.

Allowing some markers to be bound to inputs while others aren't would be cleaner.

As for how this gets implemented in practice: I think a simple implementation is for each marker to have a MarkerType that appears as a checkbox underneath the marker name when you edit it. A softer version of "Bind markers to input" could still exist, but instead it would choose the default type markers are created as. (There's a bit more to the internals: two marker lists might be best to simplify insert/delete operations. Marker serialization into the .tasproj would also need to change)

For visual distinction, one option is for each type of marker to have a different color by default or at least make that configurable?

Having per-marker configuration could also open the door to things like #3892

[vadosnaprimer]

For independent "markers" I just use branches. They never move, also you can backup to them.

[Morilli]

I personally tend to have the Bind markers to input off by default, and only when I optimize some earlier part I use it to automatically shift multiple markers at once: Activate it, insert or delete some frames, deactivate it, undo the insertion/deletion.

Is that the main use case for you also? I wonder if adding an option to shift multiple markers by a certain amount would be the most useful way to improve functionality here.

[RetroEdit]

Nah, input-bound markers is my default, because I do actively use insert/delete when TASing, so it ensure my markers stay correctly attached to their associated presses (e.g., a press to enter level 1, level 2, etc.)

Strictly speaking, feos is probably correct that branches work well enough for the common use-case that I specifically described here. I could nitpick and say branches are heavier and that they introduce branch clutter, but they can always be deleted or relegated to a backup .tasproj.

Fundamentally, I was a little spontaneous in filing this issue, since I have a lot more design notes and thoughts about how markers could work in the future. The main thing that motivated filing an issue was realizing that it's sort of weird and user error-prone that bind markers to input is a global TAStudio setting, when the marker schema can be pretty specific to a particular .tasproj file. Merely making it project-local doesn't really address the issue either because it's useful to be able to set a global default that will be applied when new projects are created.

[vadosnaprimer]

What about having a hotkey for bind/unbind (markers to input) and change it when you want to do an operation that'd interfere with the immediately current setting?

Having this as a per-marker setting might introduce insane complexity into workflow and especially code:

• Default setting for all new markers would still have to persist
• More menu options and gui buttons to create each type of marker and to change type of an existing one
• Indication which marker is which

We once saw how unbearable the codebase can become when each branch had its own greenzone, and it was a source of endless crashes, and in the end we had to mercy-nuke it. So I'm very hesitant here too.