Potential Bug? OSC "Fire Macro" Erratic

Which software version did you update from?

PS: Current version is 3.2.4. I'm not implying that this would solve the problem, just saying.

This is getting really consistent. Should I figure out an exact algorithm to reproduce and report it somewhere as formal bug report? Sometimes this thing stops responding to even the Shift key on Nomad's popup virtual keyboard. I'm using a lot of eos/key OSC commands programmatically to automate stuff and that may be what's triggering the unusual bug. This supposed bug kills all my automation stuff and I have to restart Eos and that always immediately fixes it. Sometimes I have to just shift-update to fix it, but sometimes that just inputs "Update" into cmd line even if if pressed shift with the popup keyboard and Shift was highlighted when I hit Update key.

I'm going to later try to reproduce it with Qlab to be absolutely 100% sure it's not an issue with my code. I think it may have something to do with the fact that for all my eos/key arguments, I have to use "11 Enter" instead of just "Enter". "11 Enter" was initially a typo, but it worked, but then when I fixed the typo, it stopped working. So I just used "11 Enter" for all the other eos/key arguments.

And I did pull up wireshark on the Eos computer, as well as the Eos Diagnostics tab (I even filmed it on the Diagnostic tab), and it's not like my code is spamming looping commands or anything.

But again this started immediately after updating Eos, so I'm fairly suspicious it's not my code.

You're already in the right place to report a bug. We're just currently having a hard time reproducing, but will do another round of testing. This might take a moment.

Current theory is that a key gets stuck, e.g. Shift remains pressed. Because you're using /eos/key with arguments rather than the keys inline it's possible that the console thinks you're trying to have a key combination.

/eos/key/shift=1.0 (where = denotes the separation between address and argument) is the syntax to have a button held down, /eos/key/shift=0.0 to release.

OK, thank you so much! Yes, I can reproduce the macro issue very easily now by simply toggling the Shift boolean to True and then trying to fire a macro fire command. "11 Enter" worked because the 1st character is 1. I'll go back and use the boolean for the shift key commands.

I went back to try and figure out why I wasn't able to figure this out myself and here's what I found:

My ADHD brain had studied this over and over again and it looked like meaningless spaghetti. The top headers are very confusing since they don't line up with anything below. I see "(optional)" and that tells me I can disregard parts of this, but I don't know which parts. I see "but- ton" and I have no idea what that's supposed to mean because if it meant simply "button", it would have said that, but it didn't, so I don't know what it means. I see "number for button edge" and I don't know what that means, but I think it has something to do with encoders, so that tells me none of this applies to normal keys, so maybe 1 is for clockwise and 0 is for counter clockwise.

Have you guys thought about organizing this vertically instead of horizontally, as below? This is what I think it's trying to say, but I'm still not sure:

OSC Method/Address
/eos/key/<key name without underscore for spaces>

Arguments
1 (to trigger a button not like Shift, or to press and hold a button like Shift)
0 (to let go of the button, but this is only needed for buttons like Shift)

Examples/Comments (Method/Address, Argument format)
/eos/key/select active, 1 (trigger [Select Active] button)
/eos/key/shift, 1 (press [Shift] button, toggling it to True)
/eos/key/shift, 0 (let go of [Shift] button to let go, toggling it back to False)

Examples/Comments (Method/Address=Argument format)
/eos/key/shift=1 (press [Shift] button, toggling it to True)
/eos/key/shift=0 (let go of [Shift] button to let go, toggling it back to False)

Note: For the backslash key, use backslash /eos/key/\

Note: Keys requiring a separate command to let go are [Shift], [any others here]


------------

Changes:

I organized the visual hierarchy vertically so that lengthy rows can take up the entire screen on the x without encroaching upon other columns causing confusion.

I avoided using "go 0" because people (like myself) can interpret the 0 as possibly being a 0 for False, as in the second Argument above. 

I used the [Shift] key as an example and the [About] button as another example since that example combination demonstrates proper usage of non-boolean keys (such as About) as well as boolean keys (such as Shift), so the user can now easily interpret how the 2 types of key commands differ. 

I removed "number from button edge" from the verbiage since I still don't know what that means.

I removed the ".0" from "1.0" and "0.0" since it appears to be extraneous. 

I condensed "but- ton" to "button" per lexicon.

I made minor additions to verbiage inside () that I believe make the information easier to understand, such as adding a bit about toggling [Shift] back to False so it is more clear that some keys have boolean, True/False properties and are not single action events. 

I changed <name>  to <key name without underscore for spaces> to make it unambiguously clear that any multiple-word key does not need underscore here like they do in the eos/cmd argument context.

I used the word "trigger" in some places to indicate that some buttons should be thought of as a single-action-event, not as a boolean property to toggle on and off.

I removed the word "release" from all explainers since that could potentially be confused for the [Release] button on the console. 

I removed the "(optional)" since there are no cases where using the 0 would be advantageous but not purely extraneous, while there are cases where not using the 0 would lead to unexpected, unwanted behavior (such as the prompt for this thread).

I communicated the two different OSC composition formats with two separate sections. The first is the format TouchOSC and my software uses while the second is the format that Qlab uses. I created 2 sections to make it more clear that there are 2 acceptable formats and different OSC softwares may use one or the other.

#Creates stuff for displays operator to do
class DisplaysOperator(bpy.types.Operator):
    bl_idname = "my.displays_operator"
    bl_label = "Displays"
    
    def execute(self, context):
        ip_address = context.scene.osc_ip_address
        port = context.scene.osc_port
        
        address = "/eos/key/displays"
        argument = "1"
        argument2 = "0"
        
        send_osc_string(address, ip_address, port, argument)
        send_osc_string(address, ip_address, port, argument2)
        send_osc_string(address, ip_address, port, argument)
        send_osc_string(address, ip_address, port, argument2)
        #Why does this work? This is the simplest version I found that works. All other versions either do nothing or pull up the Brightness Control box over the CIA.
        
        return {'FINISHED'}
    
    
#Creates stuff for about operator to do
class AboutOperator(bpy.types.Operator):
    bl_idname = "my.about_operator"
    bl_label = "About"
    
    def execute(self, context):
        ip_address = context.scene.osc_ip_address
        port = context.scene.osc_port
        
        address = "/eos/key/about"
        argument = "0"
        
        send_osc_string(address, ip_address, port, argument)
        #How come this button appears to be the only button that responds to a 0 for a trigger event and not 1?
        
        return {'FINISHED'}
    

#Creates stuff for record operator to do
class RecordOperator(bpy.types.Operator):
    bl_idname = "my.record_operator"
    bl_label = "Record"
    
    def execute(self, context):
        ip_address = context.scene.osc_ip_address
        port = context.scene.osc_port
        
        address = "/eos/key/record"
        argument = "1"
        
        send_osc_string(address, ip_address, port, argument)
        #This one and many others behave as expected after reading the documentation
        
        return {'FINISHED'}
    

This is interesting. The About key only works with a 0 while many other keys only work with a 1. Meanwhile, the Displays key only works correctly when I send a combination of 4 different 1's and 0's. 

#Creates stuff for displays operator to do
class DisplaysOperator(bpy.types.Operator):
    bl_idname = "my.displays_operator"
    bl_label = "Displays"
    
    def execute(self, context):
        ip_address = context.scene.osc_ip_address
        port = context.scene.osc_port
        
        address = "/eos/key/displays"
        argument = "1"
        argument2 = "0"
        
        send_osc_string(address, ip_address, port, argument)
        send_osc_string(address, ip_address, port, argument2)
        send_osc_string(address, ip_address, port, argument)
        send_osc_string(address, ip_address, port, argument2)
        #Why does this work? This is the simplest version I found that works. All other versions either do nothing or pull up the Brightness Control box over the CIA.
        
        return {'FINISHED'}
    
    
#Creates stuff for about operator to do
class AboutOperator(bpy.types.Operator):
    bl_idname = "my.about_operator"
    bl_label = "About"
    
    def execute(self, context):
        ip_address = context.scene.osc_ip_address
        port = context.scene.osc_port
        
        address = "/eos/key/about"
        argument = "0"
        
        send_osc_string(address, ip_address, port, argument)
        #How come this button appears to be the only button that responds to a 0 for a trigger event and not 1?
        
        return {'FINISHED'}
    

#Creates stuff for record operator to do
class RecordOperator(bpy.types.Operator):
    bl_idname = "my.record_operator"
    bl_label = "Record"
    
    def execute(self, context):
        ip_address = context.scene.osc_ip_address
        port = context.scene.osc_port
        
        address = "/eos/key/record"
        argument = "1"
        
        send_osc_string(address, ip_address, port, argument)
        #This one and many others behave as expected after reading the documentation
        
        return {'FINISHED'}
    

This is interesting. The About key only works with a 0 while many other keys only work with a 1. Meanwhile, the Displays key only works correctly when I send a combination of 4 different 1's and 0's. 

What is the "Brightness Control box"?

Ah, that's what you should see if you press Displays for more than half a second (ish). According to Tab 99 how far apart are displays=1 and displays=0 (lines 14 and 15 of your python code)?

OK, I did not know about the press & hold, that's good to know. Thanks! I think the Python code would have worked if I had given it 1 then 0, but I tested it all in Qlab and the old Qlab doesn't auto-update network cue labels, so one was labeled what I wanted, but the actual string was wrong, so that was why, lol. Now it's working correctly and the .5 second behavior is working as you say.

Is there a comprehensive list somewhere of other keys that have other properties like this I should know about?

There isn't. The reason why button behave differently is because some act on the down edge (when pressed) and some on the up edge (when released). Buttons than can be both the first part of a key combination and a standalone button as well, will only act on the up edge for the standalone function.

The key combinations for About display toggles are why About only acts as the regular standalone function when released.

Displays also has key combination funcitonality, as well as long-press, standalone single press and standalone double press.

The buttons that can be the first part of a combination or have long-press functionality that come to mind are Shift, Displays, About, Learn, Fan, Params, Filter, MoreSK, the navigation buttons (like Tab) and the playback buttons (like StopEffect).