@image_engine I have absolutely no idea why it should be the case...... but the GUI will be laggy if the audio settings are too tight........ even when the DSP is not in use AND IS TURNED OFF. It makes no sense, but it is so. Maybe an audio chain is built as the patch is built, even when there are no audio objects?
[input_event]...... I might be wrong, but my foggy old brain is trying to tell me that [input_event] was not part of extended. If you have made a fresh installation on W10 it might be missing.
Here it is again from my "pd/extra" folder........ in.zip
The two files were in "extra"...... not in a sub-folder.... which makes me a little more certain that they were not included in extended.
Of course the Win 10 api might have been re-written and the .dll might be deprecated.
I don't know if the execution order is critical for the pedal up flag...... but that would be the first place to look if the patch behaved badly. It could matter if you changed something else for some reason. But on the left side the send_ped_up can send [0( from the box above when banged by [sel 1 3] and [1(...[1( or [0(....[1( depending on the order from [sel 1 2 3 4]. Can that cause problems because of the arrival of a new input in the middle of a pedal input? I don't know...... but it could be best to "fix" the order so that there is no doubt about the logic.
Yes, I inserted the two bangs to get rid of the double cords from the select object...... but also, as you say, it helps with a de-bug...... as it reminds the reader that outputs 2 and 4 are getting only bangs, while outputs 1 and 3 are getting logic (0/1).......
I would use logic (0/1) as you have done....... as the patch is all about logic. Number 0 is logical false and so "means" "off" and is a natural reset. You could create tags for messages using symbols and then [route] instead of [select]. I had never thought about that, but it is a very interesting idea . It serves no purpose in a running patch, and creates extra work building the patch........ BUT......
..... In the past I have set a slow [metro] to make such a patch "live" and used "magic glass" or labelled [print] objects for debugging. In a very complex logic patch it could be very useful to tag the messages. It can be hard to spot message ordering problems just using the terminal window and even harder with "magic glass". With symbol tags you would easily see where the messages originated. It's a very good idea! Up-vote deserved!
Sorry...... that sparked some ideas.
Tagging and routing by symbols will be a bad idea because the logic decisions need to be taken by 1/0 true/false and so the value needs to head up the list.
But tags could be appended....... to show the route taken.
[route] would always be used instead of [select]...... so that the appended message is preserved...... and then the logical value re"-"placed using [list prepend].
I might start a new thread I think..... to gather ideas and criticism.
A set of specific "normal" and "debugging" objects would be useful, as, for example [myselect 0 1] (which contained values to "send onwards" unlike [sel] ) could be renamed to [myrouter 0 1 router5].
Aarrgh...... probably a huge hole in which to stop digging......
..... and I bet it exists in extended already........?????
Is your patch working as you wish?
And reading again.... after all that!..... I think you meant "message or float" and not "symbol or float" to send the zero.
I don't know of any difference, and they send exactly the same data, but the message [1( is more useful for debugging than the float  because you can click it and send the message.......