Re: [PD] [key], [keyup] and operating system key reapat
Yes, the key/event handling comes from tk. you'll have to ask them about the behavior (it seems like there should be some way to disable key repeats on windows..) -seb -Original Message- From: Peter P. To: pd-list@lists.iem.at Sent: Wed, May 4, 2022 12:49 am Subject: Re: [PD] [key], [keyup] and operating system key reapat Hi everyone, IOhannes, * IOhannes m zmoelnig [2022-05-04 08:40]: > > On 5/4/22 08:04, Peter P. wrote: > > It would be great to have more unified behavior since so much work has > > already gone into this issue. > > i guess this would be great for many users of Tcl/Tk. > you might want to file a (wishlist) bug there. If this doesn't provoke nightmares I'd be happy to do, perhaps for documentation purposes only. > > gdmasdr > IOhannes > > > PS: i'm happy to fix bugs in the Pd sources; but unlike Dan, I am *ont* > willing to patch the Tcl/Tk engine for Pd's sake. i guess this saves me from > a few nightmares Thanks, just to be clear as I am not involved in this coding: The problem lies within Tcl/Tk right (and is known within that community of coders)? best, P ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
Hah, to be clear: I only do that when it's absolutely necessary. Thankfully the Tk community has been updating things on macOS at a munch greater rate the last few years now, so we are running into fewer problems at the Tk level. Also, people like Seb have thankfully been assisting and we have the patching mechanism in place for if/when we have to apply custom patches to Tk, at least for the macOS build process. I am actually thankful we can also have this conversation... it wasn't so long ago that key handling was *broken* on macOS! In my opinion, I defer to the system and Tk for this. In fact, the only reason Pd actually respects the system setting is that we, the Pd community, added it to Tk! We made a patch which includes it a couple years ago, and I believe the Tk devs used it. The suggestion for it came from someone *here*, so maybe we have ourselves to blame for divergent behavior.? ;) > On May 4, 2022, at 10:14 AM, pd-list-requ...@lists.iem.at wrote: > > Message: 2 > Date: Wed, 4 May 2022 08:39:29 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] [key], [keyup] and operating system key reapat > Message-ID: <mailto:f121dc43-8951-496c-f88b-654dbf920...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > PS: i'm happy to fix bugs in the Pd sources; but unlike Dan, I am *ont* > willing to patch the Tcl/Tk engine for Pd's sake. i guess this saves me > from a few nightmares Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
On 5/4/22 09:49, Peter P. wrote: >> i guess this would be great for many users of Tcl/Tk. >> you might want to file a (wishlist) bug there. > If this doesn't provoke nightmares I'd be happy to do, perhaps for > documentation purposes only. it won't provoke nightmares for me (as i wouldn't even know what you are doing in the Tcl/Tk bugtracker). YMMV. On 5/4/22 09:49, Peter P. wrote: PS: i'm happy to fix bugs in the Pd sources; but unlike Dan, I am *not* willing to patch the Tcl/Tk engine for Pd's sake. i guess this saves me from a few nightmares Thanks, just to be clear as I am not involved in this coding: The problem lies within Tcl/Tk right (and is known within that community of coders)? i have no idea. the Tcl/Tk community might be aware of the fact, but not see it as a problem. like so many things this is probably just a result of different decisions that were made on the OS level. (and I assume that Tcl/Tk is just passing through the system characteristics). e.g. on macOS there is this UX guideline, that whenever you change something in a properties window, the change is applied immediately. otoh, Linux and Windows systems typically use a distinct "Apply" button, that you have to actively press in order to apply your changes. now we *could* create a dialog that behaves the same on all platforms, which is great as there is now a consistent behaviour of Pd across OSs. but if we pick the macOS UX guideline, users of Linux or Windows will probably be unhappy. or vice-versa. similar with key repeat: the designers of your desktop environment probably (hopefully!) spent some thought on why key repeat behaves as it does, but (unfortunately) they came to different solutions as what should be the "correct" behaviour. but if Tcl/Tk chose to abstract that behaviour away to a (new) behaviour, that is consistent across all platforms, wouldn't this make Tcl/Tk applications behave "weird" in the experience of users who work on a system that usually has a behaviour that *differs* from the one chosen by Tcl/Tk. the simplistic answer is of course: if you want your dialogs to behave like on Windows, you shouldn't use macOS. if you want your keys to repeat like on Linux, you shouldn't use Windows. in practice this is of course a straw man, as people don't typically pick their OSs because they like a given keyrepeat or dialog behaviour. but it hopefully explains why it's often not so simple to "fix" differences between OSs. having said all that: the Tcl/Tk community might be able to give more informed feedback on such a feature request. gfmadsr IOhannes OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
Hi everyone, IOhannes, * IOhannes m zmoelnig [2022-05-04 08:40]: > > On 5/4/22 08:04, Peter P. wrote: > > It would be great to have more unified behavior since so much work has > > already gone into this issue. > > i guess this would be great for many users of Tcl/Tk. > you might want to file a (wishlist) bug there. If this doesn't provoke nightmares I'd be happy to do, perhaps for documentation purposes only. > > gdmasdr > IOhannes > > > PS: i'm happy to fix bugs in the Pd sources; but unlike Dan, I am *ont* > willing to patch the Tcl/Tk engine for Pd's sake. i guess this saves me from > a few nightmares Thanks, just to be clear as I am not involved in this coding: The problem lies within Tcl/Tk right (and is known within that community of coders)? best, P ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
On 5/4/22 08:04, Peter P. wrote: It would be great to have more unified behavior since so much work has already gone into this issue. i guess this would be great for many users of Tcl/Tk. you might want to file a (wishlist) bug there. gdmasdr IOhannes PS: i'm happy to fix bugs in the Pd sources; but unlike Dan, I am *ont* willing to patch the Tcl/Tk engine for Pd's sake. i guess this saves me from a few nightmares OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
Dear Sebastian, * Sebastian Shader via Pd-list [2022-05-03 21:55]: > I might be mistaking what you're saying but, on OSX if key repeats are off in > the system preferences (at least when pd starts) then they will not repeat > from the [key] & [keyname] objects Thanks for clarifying, yes, I re-read your last mail about this topic. So again, to summarize: OS X: key repeat off: One key down, one key up key repeat on: Many key downs, one key up Win: key repeat on or off: Many key downs, one key up Linux: key repeat off: One key down, one key up key repeat on: Many key downs, many key ups So even if I tell the user of a patch to set key repeat off in the operating system preferences, I'd still have to provide an abstraction that filters repeated key downs in case she's on Windows... It would be great to have more unified behavior since so much work has already gone into this issue. Looking forward for comments and suggestions, P ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
Dear oliver, dear list, * oliver [2022-05-03 18:05]: > Peter P. wrote: > > Dear Dan and everyone contributing to this issue, > > > > I kinda felt this is a sensitive topic but was not aware of the amount > > of frustrating work that has already gone into it. Every bit of it is > > much appreciated, thank you and everyone a lot! > > > > So if I would want to write a patch that uses the [key] and [keyup] objects > > to > > work consistently on all three platforms, I would have to tell the user to > > turn key repeat off in her operating system AND provide a means to > > filter out repeating key ons (Win and OS X), correct? > > > > In this case I happily deal with the current status. > > Often key repetitions are desired, for example if i want to make a beautiful > dividing line like this: > > === Yes, this is without discussion and full of beauty. However for many Pd-related requirements it is not. > Maybe a safer approach would be to provide an abstraction that does the > filtering depending on the OS. I think there should be a vanilla way that works on all three OSes. Thanks for pointing to your abstraction, it looks very sophisticated. I have used the attached abstraction in the past to filter key repeats but it did not work reliably. It would occasionally let single repeated events pass through, and has to be tuned to the key repeat rate, as there is a wait time. Futhermore these abstraction get hella complicated if you depress multiple keys simultaneously. cheersz, P #N canvas 559 247 891 565 12; #X text 13 13 Abstraction to detect keyboard actions without repeating key presses.; #X obj 154 173 tgl 15 0 empty empty down/up 17 7 0 10 -262144 -1 -1 0 1; #X obj 125 201 bng 15 250 50 0 empty empty should_only_flash_once_on_down_or_up 17 7 0 10 -262144 -1 -1; #X obj 36 420 timer; #X obj 36 394 t b b; #X obj 36 340 key; #X obj 36 366 sel 71; #X obj 36 445 moses 1; #X floatatom 35 474 5 0 0 1 msec - -; #X obj 35 500 print myComputersRepeatRate; #X text 139 339 When you press and hold a key on your computers keyboard \, most operating systems will repeat this keypress automatically \, mimicking old typewriters. This can be an obstacle to detect key-down and key-up reliably. Use the patch to the left to estimate the longest intervall in milliseconds of such repeats while keeping a single key depressed. The first argument of [keyhold] should be slightly larger than this interval.; #X obj 125 146 keyhold 60 G; #X text 460 163 2.argument: Symbol to indicate the key to filter.; #X text 459 90 1.argument: Interval time (msec) to block key repeats. Will vary for different operating systems and its user settings. See patch below for information how to set for your computer.; #X text 26 247 This will detect key downs and ups for capital letter 'G' while blocking key repeats that happen faster than 60msec.; #X text 459 206 BUG: Currently the space bar can not be detected.; #N canvas 511 55 450 300 version-2019-05-01 0; #X text 16 97 Bug/TODO: The symbol for the space bar has different captitals 'space' and 'Space' for down and ups.; #X text 18 31 Expanded from an idea posted by Katja Vetter on the pd mailing list on March 8th 2019; #X restore 710 529 pd version-2019-05-01; #X text 419 530 (c) 2019 Peter P. under the BSD license.; #X text 458 240 NOTE: Most computer keyboards can not detect more than 3-5 keys depressed together.; #X connect 3 0 7 0; #X connect 4 0 3 0; #X connect 4 1 3 1; #X connect 5 0 6 0; #X connect 6 0 4 0; #X connect 7 1 8 0; #X connect 8 0 9 0; #X connect 11 0 1 0; #X connect 11 0 2 0; #N canvas 847 82 516 684 12; #X obj 107 133 keyname; #X obj 107 167 t b f; #X obj 107 234 pack s f; #X obj 107 204 symbol; #X obj 107 273 route list; #X msg 211 398 0; #X obj 211 475 pipe \$1; #X obj 107 406 t b b; #X msg 139 439 clear; #X obj 107 514 change; #X obj 107 545 outlet; #X msg 107 477 1; #X obj 107 350 sel 1 0; #X obj 107 309 route \$2; #N canvas 511 55 450 300 version-2019-05-01 0; #X text 16 97 Bug/TODO: The symbol for the space bar has different captitals 'space' and 'Space' for down and ups.; #X text 18 31 Expanded from an idea posted by Katja Vetter on the pd mailing list on March 8th 2019; #X restore 331 647 pd version-2019-05-01; #X text 40 648 (c) 2019 Peter P. under the BSD license.; #X connect 0 0 1 0; #X connect 0 1 3 1; #X connect 1 0 3 0; #X connect 1 1 2 1; #X connect 2 0 4 0; #X connect 3 0 2 0; #X connect 4 0 13 0; #X connect 5 0 6 0; #X connect 6 0 9 0; #X connect 7 0 11 0; #X connect 7 1 8 0; #X connect 8 0 6 0; #X connect 9 0 10 0; #X connect 11 0 9 0; #X connect 12 0 7 0; #X connect 12 1 5 0; #X connect 13 0 12 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
I might be mistaking what you're saying but, on OSX if key repeats are off in the system preferences (at least when pd starts) then they will not repeat from the [key] & [keyname] objects -seb -Original Message- From: Peter P. To: pd-list@lists.iem.at Sent: Tue, May 3, 2022 4:17 am Subject: Re: [PD] [key], [keyup] and operating system key reapat Dear Dan and everyone contributing to this issue, I kinda felt this is a sensitive topic but was not aware of the amount of frustrating work that has already gone into it. Every bit of it is much appreciated, thank you and everyone a lot! So if I would want to write a patch that uses the [key] and [keyup] objects to work consistently on all three platforms, I would have to tell the user to turn key repeat off in her operating system AND provide a means to filter out repeating key ons (Win and OS X), correct? In this case I happily deal with the current status. thanks again, Peter * Dan Wilcox [2022-05-02 12:38]: > For me, every time this topic comes up, I get recurring nightmares of having > to write, set, and apply patches to the Tk source code. From my point of > view, we should enjoy what works as it is and remember that for some people, > the key handling should respect the general system as opposed to being > Pd-specific. Of course, some may have a different opinion, in which case I > ask them to contribute working solutions for test/discussion. > > The only other solution is to open more issues and *hope* IOhannes fix > everything again, but I *think* his feeling is similar to mine above... ;) > > > On May 2, 2022, at 12:00 PM, pd-list-requ...@lists.iem.at wrote: > > > > Message: 2 > > Date: Sun, 1 May 2022 18:50:34 +0200 > > From: "Peter P." > <mailto:peterpar...@fastmail.com>> > > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > > Subject: Re: [PD] [key], [keyup] and operating system key reapat > > Message-ID: <20220501165034.sq22mbyufuza5...@fastmail.com > > <mailto:20220501165034.sq22mbyufuza5...@fastmail.com>> > > Content-Type: text/plain; charset=us-ascii > > > > * Peter P. mailto:peterpar...@fastmail.com>> > > [2022-05-01 18:44]: > > [...] > >> Shouldn't/couldn't the filtering of repeated note-ons be done within the > >> objects on Win and OS X at least? > > Oh, just saw this issue > > https://github.com/pure-data/pure-data/issues/945 > > <https://github.com/pure-data/pure-data/issues/945> > > and several related others. Seems complicated and a lot of work has gone > > into the current behavior already... I am wondering what the current > > status is, and if there is any future work planned? > > > > Thanks to everyone working on it!! > > > > P > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
Peter P. wrote: Dear Dan and everyone contributing to this issue, I kinda felt this is a sensitive topic but was not aware of the amount of frustrating work that has already gone into it. Every bit of it is much appreciated, thank you and everyone a lot! So if I would want to write a patch that uses the [key] and [keyup] objects to work consistently on all three platforms, I would have to tell the user to turn key repeat off in her operating system AND provide a means to filter out repeating key ons (Win and OS X), correct? In this case I happily deal with the current status. Often key repetitions are desired, for example if i want to make a beautiful dividing line like this: === Maybe a safer approach would be to provide an abstraction that does the filtering depending on the OS. Of course you will need at least [operating_system] from ZEXY for that, so this wouldn't be vanilla only. and of course it has other drawbacks, as it would need to be centralised (only one instance of [keyname] and then distribute the results with a [send]) that's at least the way i do it attached is an abstraction i made a few years ago, haven't revised it lately, so please just take it as an example (also as it's only for windows ATM) best oliver #N canvas 515 92 858 824 10; #X declare -stdpath iemguts -path iemguts; #X declare -stdlib zexy -lib zexy; #X obj 415 717 cnv 14 63 15 empty empty empty 2 2 0 9 -248636 -66577 0; #X obj 415 716 closebang, f 10; #X obj 280 209 t b b; #X obj 330 209 t b b; #X msg 280 406 1; #X msg 295 361 stop; #X obj 280 384 del 500; #X msg 376 433 1; #X msg 390 385 stop; #X obj 376 411 del 500; #X obj 396 575 s ol_key; #X msg 307 486 UP; #X msg 359 486 DOWN; #X obj 280 429 metro 50; #X obj 376 456 metro 50; #X msg 408 486 LEFT; #X msg 457 486 RIGHT; #X obj 280 182 route Up Down Left Right, f 34; #X msg 465 430 1; #X msg 478 383 stop; #X obj 465 408 del 500; #X msg 529 429 1; #X msg 537 384 stop; #X obj 529 407 del 500; #X obj 465 453 metro 50; #X obj 529 452 metro 50; #X obj 537 268 route Up Down Left Right, f 34; #X obj 380 209 t b b; #X obj 430 209 t b b; #X obj 50 72 keyname; #X obj 50 216 pack 0 s; #X obj 50 262 route 1 0, f 21; #X obj 50 288 route Control_L Shift_L; #X obj 111 369 route Control_L Shift_L; #X obj 50 311 t b; #X obj 120 311 t b; #X obj 111 390 t b; #X obj 178 390 t b; #X obj 161 513 s shiftstate; #X msg 50 335 1; #X msg 111 413 0; #X msg 178 412 0; #X msg 120 333 1; #X text 282 161 ARROW KEYS; #X obj 396 524 symbol; #X obj 589 541 outlet; #X obj 517 541 outlet; #X text 508 562 KEY DOWN; #X text 587 561 KEY UP; #X obj 607 511 s ol_keyup; #X obj 589 451 symbol; #X text 52 46 STRG + SHIFT, f 13; #X obj 219 398 s \$0-up; #X obj 537 246 r \$0-up; #X obj 126 685 spigot; #X msg 167 656 0; #X msg 145 656 1; #X obj 45 618 t b b b b; #X msg 96 656 1; #X msg 126 706 0; #X obj 96 733 s \$0-ol_key_spigot; #X obj 155 513 cnv 5 5 17 empty empty empty 20 12 0 14 -173398 -66577 0; #X obj 390 575 cnv 5 5 17 empty empty empty 20 12 0 14 -173398 -66577 0; #X obj 601 511 cnv 5 5 17 empty empty empty 20 12 0 14 -173398 -66577 0; #X obj 56 760 cnv 5 5 17 empty empty empty 20 12 0 14 -173398 -66577 0; #X obj 90 733 cnv 5 5 17 empty empty empty 20 12 0 14 -173398 -66577 0; #X obj 120 619 cnv 5 5 17 empty empty empty 20 12 0 14 -260097 -66577 0; #X obj 213 398 cnv 5 5 17 empty empty empty 20 12 0 14 -173398 -66577 0; #X obj 531 246 cnv 5 5 17 empty empty empty 20 12 0 14 -260097 -66577 0; #X text 413 680 this has to be created before everything else !, f 25; #X obj 126 619 r ol_key_single_check; #X obj 62 760 s ol_key_single_check; #X obj 45 594 del 50; #X obj 45 572 r check_ol_key_instances; #X text 44 551 check for multiple instances; #X obj 415 746 s check_ol_key_instances; #X obj 570 746 print \$0-CB; #X obj 511 542 cnv 5 5 17 empty empty empty 20 12 0 14 -102336 -66577 0; #X obj 583 541 cnv 5 5 17 empty empty empty 20 12 0 14 -102336 -66577 0; #X obj 573 41 cnv 10 170 20 empty empty needs_IEMGUTS_ZEXY 10 11 0 14 -4160 -262144 0; #X obj 573 57 cnv 4 130 4 empty empty empty 10 11 0 14 -4160 -262144 0; #X obj 512 71 cnv 14 230 15 empty empty empty 2 2 0 9 -253181 -66577 0; #X msg 406 433 0; #X msg 495 430 0; #X msg 559 429 0; #X msg 315 406 0; #X obj 537 291 t b b; #X obj 587 292 t b b; #X obj 637 292 t b b; #X obj 687 293 t b b; #X msg 311 676 1; #X obj 291 746 s \$0-mainspigot-r; #X obj 50 240 spigot 1; #X obj 112 240 cnv 5 5 17 empty empty empty 20 12 0 14 -260097 -66577 0; #X obj 118 240 r \$0-mainspigot; #X obj 1 1 cnv 3 68 13 \$0-bgnd \$0-bgnd-r Control_L 20 7 1 9 -241339 -66577 0; #X obj 0 0 tgl 15 0 \$0-mainspigot \$0-mainspigot-r empty 17 7 0 10 -203904 -1 -1 1 1; #X msg 225 702 pos 0 \$1; #X msg 208 673 0; #X msg 237 673 20; #X msg 119 195 label \$1; #X obj 119 216 s \$0-bgnd-r; #X obj 650 746 s \$0-bgnd-r; #X msg 650 725 label; #X obj 683 615 cnv 5 5 17 empty empty empty 20 12 0 14 -173398 -66577 0; #X
Re: [PD] [key], [keyup] and operating system key reapat
Dear Dan and everyone contributing to this issue, I kinda felt this is a sensitive topic but was not aware of the amount of frustrating work that has already gone into it. Every bit of it is much appreciated, thank you and everyone a lot! So if I would want to write a patch that uses the [key] and [keyup] objects to work consistently on all three platforms, I would have to tell the user to turn key repeat off in her operating system AND provide a means to filter out repeating key ons (Win and OS X), correct? In this case I happily deal with the current status. thanks again, Peter * Dan Wilcox [2022-05-02 12:38]: > For me, every time this topic comes up, I get recurring nightmares of having > to write, set, and apply patches to the Tk source code. From my point of > view, we should enjoy what works as it is and remember that for some people, > the key handling should respect the general system as opposed to being > Pd-specific. Of course, some may have a different opinion, in which case I > ask them to contribute working solutions for test/discussion. > > The only other solution is to open more issues and *hope* IOhannes fix > everything again, but I *think* his feeling is similar to mine above... ;) > > > On May 2, 2022, at 12:00 PM, pd-list-requ...@lists.iem.at wrote: > > > > Message: 2 > > Date: Sun, 1 May 2022 18:50:34 +0200 > > From: "Peter P." > <mailto:peterpar...@fastmail.com>> > > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > > Subject: Re: [PD] [key], [keyup] and operating system key reapat > > Message-ID: <20220501165034.sq22mbyufuza5...@fastmail.com > > <mailto:20220501165034.sq22mbyufuza5...@fastmail.com>> > > Content-Type: text/plain; charset=us-ascii > > > > * Peter P. mailto:peterpar...@fastmail.com>> > > [2022-05-01 18:44]: > > [...] > >> Shouldn't/couldn't the filtering of repeated note-ons be done within the > >> objects on Win and OS X at least? > > Oh, just saw this issue > > https://github.com/pure-data/pure-data/issues/945 > > <https://github.com/pure-data/pure-data/issues/945> > > and several related others. Seems complicated and a lot of work has gone > > into the current behavior already... I am wondering what the current > > status is, and if there is any future work planned? > > > > Thanks to everyone working on it!! > > > > P > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
For me, every time this topic comes up, I get recurring nightmares of having to write, set, and apply patches to the Tk source code. From my point of view, we should enjoy what works as it is and remember that for some people, the key handling should respect the general system as opposed to being Pd-specific. Of course, some may have a different opinion, in which case I ask them to contribute working solutions for test/discussion. The only other solution is to open more issues and *hope* IOhannes fix everything again, but I *think* his feeling is similar to mine above... ;) > On May 2, 2022, at 12:00 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 2 > Date: Sun, 1 May 2022 18:50:34 +0200 > From: "Peter P." mailto:peterpar...@fastmail.com>> > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] [key], [keyup] and operating system key reapat > Message-ID: <20220501165034.sq22mbyufuza5...@fastmail.com > <mailto:20220501165034.sq22mbyufuza5...@fastmail.com>> > Content-Type: text/plain; charset=us-ascii > > * Peter P. mailto:peterpar...@fastmail.com>> > [2022-05-01 18:44]: > [...] >> Shouldn't/couldn't the filtering of repeated note-ons be done within the >> objects on Win and OS X at least? > Oh, just saw this issue > https://github.com/pure-data/pure-data/issues/945 > <https://github.com/pure-data/pure-data/issues/945> > and several related others. Seems complicated and a lot of work has gone > into the current behavior already... I am wondering what the current > status is, and if there is any future work planned? > > Thanks to everyone working on it!! > > P Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
* Peter P. [2022-05-01 18:44]: [...] > Shouldn't/couldn't the filtering of repeated note-ons be done within the > objects on Win and OS X at least? Oh, just saw this issue https://github.com/pure-data/pure-data/issues/945 and several related others. Seems complicated and a lot of work has gone into the current behavior already... I am wondering what the current status is, and if there is any future work planned? Thanks to everyone working on it!! P ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
Thanks Lucas, thanks Sebastian, so the OS X behavior can be made the same as the windows one once the system preferences are set correctly... It seems there is no way of getting consistent behavior on all three OSes by default: On Windows I have to filter repeated key-ons. On OS X I have to change the global repeat preferences and filter out repeated key-ons. On Linux I have to disable key repeat via "xset r off" and am done. It would be great it this could be unified further, the OS X bugfix is already a big step into the right direction. I suppose it would not be easy/impossible at all? Shouldn't/couldn't the filtering of repeated note-ons be done within the objects on Win and OS X at least? Thanks again, P * Sebastian Shader via Pd-list [2022-04-29 09:04]: > On MacOS the key repeat should be respecting the system preference now after > switching to tcl/tk 8.6.12 (see discussion here: > https://github.com/pure-data/pure-data/pull/1306)note that key ons are > repeated without corresponding key offs, until the key is released (if key > repeats are enabled in the system preferences) > > -seb > > -Original Message- > From: Peter P. > To: pd-list > Sent: Thu, Apr 28, 2022 10:38 pm > Subject: [PD] [key], [keyup] and operating system key reapat > > Hi list, > > I can't seem to get my head around different behavior of the [key] and > [keyup] objects on different OSes and even within the same OS. I > discovered that for depressed keys after an initial delay > -Pd on Debian will report repeated key ups and downs, > -Pd on Windows does not, > -Pd on OS X may or may not. > Could a few of us test this quickly and report their findings here > maybe? > > Thanks! > Peter > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
On MacOS the key repeat should be respecting the system preference now after switching to tcl/tk 8.6.12 (see discussion here: https://github.com/pure-data/pure-data/pull/1306)note that key ons are repeated without corresponding key offs, until the key is released (if key repeats are enabled in the system preferences) -seb -Original Message- From: Peter P. To: pd-list Sent: Thu, Apr 28, 2022 10:38 pm Subject: [PD] [key], [keyup] and operating system key reapat Hi list, I can't seem to get my head around different behavior of the [key] and [keyup] objects on different OSes and even within the same OS. I discovered that for depressed keys after an initial delay -Pd on Debian will report repeated key ups and downs, -Pd on Windows does not, -Pd on OS X may or may not. Could a few of us test this quickly and report their findings here maybe? Thanks! Peter ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [key], [keyup] and operating system key reapat
Pd 0.52-2 pressing and holding a key: Windows11 (Tk 8.6.10 amd64) key: 106 key: 106 key: 106 key: 106 key: 106 key: 106 key: 106 key: 106 key: 106 key: 106 keyup: 106 Debian11 (Tk 8.6.11 amd64) key: 106 keyup: 106 key: 106 keyup: 106 key: 106 keyup: 106 key: 106 keyup: 106 key: 106 keyup: 106 -- Mensaje telepatico asistido por maquinas. On 29/04/2022 02:38, Peter P. wrote: Hi list, I can't seem to get my head around different behavior of the [key] and [keyup] objects on different OSes and even within the same OS. I discovered that for depressed keys after an initial delay -Pd on Debian will report repeated key ups and downs, -Pd on Windows does not, -Pd on OS X may or may not. Could a few of us test this quickly and report their findings here maybe? Thanks! Peter ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [key], [keyup] and operating system key reapat
Hi list, I can't seem to get my head around different behavior of the [key] and [keyup] objects on different OSes and even within the same OS. I discovered that for depressed keys after an initial delay -Pd on Debian will report repeated key ups and downs, -Pd on Windows does not, -Pd on OS X may or may not. Could a few of us test this quickly and report their findings here maybe? Thanks! Peter ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
