Am 5. Dezember 2025 07:45:48 MEZ schrieb "Peter P." <[email protected]>: >On a second thought, would it make sense to add a configurable option to >future versions of the [key] object to have it only output messages when >not in edit mode?
well, but [key] gives you global keystrokes, and edit mode is per canvas. if the object would stop outputting data if an arbitrary window is in edit mode (that does not need to have focus), I guess that would be quite confusing. there might be some use for a per-canvas [key] that can distinguish between edit mode and run mode (but i guess you could already create something like this with iemguts' [canvasreceive]). alternatively, [key] could only output if the currently focused window is in run mode (I guess this is what you had in mind), but I'm not sure if this is actually desirable (as in: to much magic making it confusing; how about windows that do not have a run mode? what about focus-always-under-mouse window managers?) my personal quick and dirty solution to this is to use a special key (usually ESC) to switch the output of [key] on and off. but tbh, I don't think that [key] is really that useful as an interface in "production"-grade patches. so my use cases are: - for classes (eg showing how to create a keyboard piano) I use [key] controlled with ESC - for live coding performances (that use the key presses both as for writing chode and as an input my material for "score") I just use [key]. (probably this kind of self referential live coding is not that common though) - for an "instrument" patch (practically fixed, as opposed to a changeable patch in live coding) I use [hid] mfg.sfg.jfd IOhannes --- [email protected] - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/[email protected]/message/F35TOHXZH2NRA2TRHC6TTMIWPPIXC7EV/ To unsubscribe send an email to [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
