Hi !
PD 0.56.1 LUBUNTU 24.04 (LXQT)
Is it possible to find out PD's editmode state via a message or an object ?
I know about IEMGUT's [receivecanvas] that gives out that information, but only for that specific canvas, in which the object resides.
A general method to query PD's overall editmode state would be great, maybe as a message to the [pdcontrol] object (like the "isvisible" message) ?
BACKGROUND: I am controlling a quite intense PD patch with the keyboard. Unfortunately all my keystrokes are also getting "read" when I'm in editmode, causing quite a chaos (unless i deactivate the [key] object. Would be great to be able to automate this.
[receivecanvas] for about 50 subpatches is possible but something i'd rather avoid ;-)
Thanks for any hints !
Best
Oliver
Em qui., 4 de dez. de 2025 às 20:54, Oliver oliver@klingt.org escreveu:
I know about IEMGUT's [receivecanvas]
there's also [else/canvas.edit] which gives you specifically that.
but only for that specific canvas, in which the object resides. A general method to query PD's overall editmode state would be great,
The problem is that this is a canvas specific message, but I guess you can use this information for a global on/off anyway.
maybe as a message to the [pdcontrol] object (like the "isvisible" message) ?
BACKGROUND: I am controlling a quite intense PD patch with the keyboard. Unfortunately all my keystrokes are also getting "read" when I'm in editmode, causing quite a chaos (unless i deactivate the [key] object. Would be great to be able to automate this.
[else/canvas.edit] and [receivecanvas] have a depth argument, so they can query the edit status of parent windows. This is what I use for something that is kinda like what you have and works for me.
cheers
[...]
BACKGROUND: I am controlling a quite intense PD patch with the keyboard. Unfortunately all my keystrokes are also getting "read" when I'm in editmode, causing quite a chaos (unless i deactivate the [key] object. Would be great to be able to automate this.
I have used capital letters for controlling the patch with Caps-Lock on, which I then deactivate when editing. This reduces the chaos a bit.
I remember another solution with two computer keyboards, where only one of them was controllung the patch via one of the [hid] objects and the other was used for editing.
Or use a single global [spigot] for deactivating messages from [key] is another option, as you describe.
hmmm...
best, Peter
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? How does Max go about this?
P.
That seems a good and simple idea!
Le ven. 5 déc. 2025 à 07:45, Peter P. peterparker@fastmail.com a écrit :
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? How does Max go about this?
P.
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/LUKEIEEOIN...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Am 5. Dezember 2025 07:45:48 MEZ schrieb "Peter P." peterparker@fastmail.com:
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:
mfg.sfg.jfd IOhannes
Thank you all for your nice answers !
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?)
True that. I didn't think of those consequences ...
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.
That's what i did so far ...
but tbh, I don't think that [key] is really that useful as an interface in "production"-grade patches.
No, but for "quick and dirty" scenarios ;-)
After i sent my first mail, i realized that there's a quite handy workaraound for my personal needs with the tools at hand:
1.) IEMGUTS/[receivecanvas] in the main patch window. To make sure only this windows gets queried.
2.) Using it's "key" messages to get keyboard values (thus it works like a "local" [key] object)
3.) As an extra safety, use its "editmode" message to open/close a spigot for the "key" messages.
Thank you all
Best
Oliver