comment: okay, I did some testing. note that not all bugs found were restricted to the use case or test case below.
use case: using keyboard controls to toggle emote blendshapes between 0 and 1 (key1..key9 toggling emote1..emote9) , accompanied by a separate group of keyboard controls mapped to the same key to set all emote blendshapes to 0 (a group of keybinds setting emote1..emote9 with key0). this would allow toggling independent emotes with key1..key9, and pressing key0 to turn off all emotes.
test case: keyboard control toggle; keybind (Alt)(1), blendshape "testShape", values {0,1}. keyboard control set; keybind (Alt)(0), blendshape "testShape", initial value {0}, set value {0}.
comment: Puppetstring 0.0.4 does not like it if you set multiple keyboard controls to the same blendshape. (that is, when several keyboard controls have their blendshape targets set to the same string.)
bug0: when a toggle keybind and a set keybind both target the same blendshape, the displayed values for the toggle keybind may appear to change correctly in Puppetstring, but the output blendshape communicated to session remains fixed regardless of keypresses. replicated successfully.
bug1: when a toggle keybind and a set keybind both target the same blendshape, clicking the edit button for the set keybind may instead result in opening the edit view for the toggle keybind, or opening the edit view for the set keybind as if it were an increment/decrement keybind. replication has been difficult; my conjecture is that the result of clicking the edit button for the set keyboard control may depend on variables or values that are persistent to a given instance of Puppetstring.
comment: as I was doing testing for this bug, additional bugs were discovered outside of the test case. keyboard set controls are hecked up, friendo. UI always goes like this lol
bug2: after editing a set keybind, future set keybinds may have an additional "Value 2" underneath "Key 1". for example, after three calls to edit any set keybinds, editing another set keybind might have a "Key 1" with the fields "Value 1", "Value 2", "Value 2", and "Value 2". partially replicated successfully; did not test whether or not the process is initiated by editing a set keybind which has multiple keys to set a blendshape to different values, or if it's initiated with any set keybind regardless of how many keys or values it has.
bug3: for a set keybind with multiple keys, the second key always sets the targeted blendshape to 0, regardless of the value entered for "Key 2" in its "Value 2" field. however, entering a value for "Key 1" "Value 2" will result in "Key 2" setting the blendshape to "Key 1"s "Value 2".
bug3 cont'd: "Key 1" "Value 1" {0.1}, "Key 1" "Value 2" {0.2}, "Key 2" "Value 2" {0.3}. this setup will cause "Key 1" to set the blendshape to 0.1 and "Key 2" to set the blendshape to 0.2. Replicated successfully.
bug4: editing a set keybind may result in all "Value 2" fields being initiated with the value from "Value 1", and the "Value 1" field being initiated as {0}.
comment: these are all the bugs I recalled and found in this sitting. there may be others I can't recall right now. and unrelatedto the bugs reported here, I have a suspicion there may be other bblendshapes like psHeadFrontBack where the values sent to Session may not match the values Puppetstring has, but I haven't gotten to around to actually testing this so I'm not confident whether this is the case nor which blendshapes may be affected.
final comment: best of luck, AR14. don't forget to hydrate, get up and move around, and find a bit of time to get some serotonin in.