People, I'm on a roll here, updating much of the help files and documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching"
I'd like you people to revise it.
Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c90...
already in an open PR
Cheers
I could just send the main Patch, but it just works best if you have all of the current state of the reference folder and also check other changes I'm proposing in this PR, so see attachment of the whole thing.
I got a rather broken keyboard, so I must be generating more typos than usual. Will need to revise it!
note that [Pd-messages] gets called in the help files of [send-receive], 'message boxes' and [namecanvas], all of them have been rewritten as well.
cheers
Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < porres@gmail.com> escreveu:
People, I'm on a roll here, updating much of the help files and documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching"
I'd like you people to revise it.
Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c90...
already in an open PR
Cheers
the reason I ask for revisions here is that I'm not an expert on this dark magic, so I'm not 100% sure about things. I can revert the commit in the PR and keep it on the fridge for the next release update if the real wizards see problems on it.
Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres < porres@gmail.com> escreveu:
I could just send the main Patch, but it just works best if you have all of the current state of the reference folder and also check other changes I'm proposing in this PR, so see attachment of the whole thing.
I got a rather broken keyboard, so I must be generating more typos than usual. Will need to revise it!
note that [Pd-messages] gets called in the help files of [send-receive], 'message boxes' and [namecanvas], all of them have been rewritten as well.
cheers
Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < porres@gmail.com> escreveu:
People, I'm on a roll here, updating much of the help files and documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching"
I'd like you people to revise it.
Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c90...
already in an open PR
Cheers
new commit, forgot about 'dirty' https://github.com/pure-data/pure-data/pull/1455/commits/8fe7ff12419c797bf33...
patch attached
Em sex., 26 de nov. de 2021 às 17:05, Alexandre Torres Porres < porres@gmail.com> escreveu:
the reason I ask for revisions here is that I'm not an expert on this dark magic, so I'm not 100% sure about things. I can revert the commit in the PR and keep it on the fridge for the next release update if the real wizards see problems on it.
Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres < porres@gmail.com> escreveu:
I could just send the main Patch, but it just works best if you have all of the current state of the reference folder and also check other changes I'm proposing in this PR, so see attachment of the whole thing.
I got a rather broken keyboard, so I must be generating more typos than usual. Will need to revise it!
note that [Pd-messages] gets called in the help files of [send-receive], 'message boxes' and [namecanvas], all of them have been rewritten as well.
cheers
Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < porres@gmail.com> escreveu:
People, I'm on a roll here, updating much of the help files and documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching"
I'd like you people to revise it.
Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c90...
already in an open PR
Cheers
I think there are definitely many "official" messages (e.g. "dsp", "fast-forward", "quit", etc.) that need to be documented properly, so in principle I very much welcome this effort.
However, I'm rather sceptical about including any "dynamic patching" messages in the official documentation as they are not officially supported. I think it would be better to exclude this from the main PR (https://github.com/pure-data/pure-data/pull/1455) and only offer this as a secondary PR (that you can rebase regularly on top of the other one).
In particular, please don't include any GUI dialog messages. Those are really internal. Also, don't advertize "coords" (at least you didn't mention "donecanvasdialog") because that one should really be replaced by https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd release :-)
I think including dynamic patching would "taint" your otherwise great documentation updates.
Christof
On 26.11.2021 21:05, Alexandre Torres Porres wrote:
the reason I ask for revisions here is that I'm not an expert on this dark magic, so I'm not 100% sure about things. I can revert the commit in the PR and keep it on the fridge for the next release update if the real wizards see problems on it.
Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres porres@gmail.com escreveu:
I could just send the main Patch, but it just works best if you have all of the current state of the reference folder and also check other changes I'm proposing in this PR, so see attachment of the whole thing. I got a rather broken keyboard, so I must be generating more typos than usual. Will need to revise it! note that [Pd-messages] gets called in the help files of [send-receive], 'message boxes' and [namecanvas], all of them have been rewritten as well. cheers Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres <porres@gmail.com> escreveu: People, I'm on a roll here, updating much of the help files and documentation. I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching" I'd like you people to revise it. Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c901ab9c74befd124ccb6e69 already in an open PR Cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
In particular, please don't include any GUI dialog messages
which are they all?
anyway, I felt I was crossing a line, hence I'm waving here to the judges :)
For instance, [namecanvas] did include a 'msg' message to canvas. I count that as a modest dynamic patch documentation.
Also, many of us use and abuse these for ages now... what if the documentation also gives us a "heads up", some "warning" that this is unstable and should be used assuming risks? This would be better than just having people check for this kind of documentation in Pd-extended or something and worse stuff.
But I see this might needs lots of debates, and as soon as I have more input I can revise and move this to a github discussion and a parallel PR.
thanks
Em sex., 26 de nov. de 2021 às 17:18, Christof Ressi info@christofressi.com escreveu:
I think there are definitely many "official" messages (e.g. "dsp", "fast-forward", "quit", etc.) that need to be documented properly, so in principle I very much welcome this effort.
However, I'm rather sceptical about including any "dynamic patching" messages in the official documentation as they are not officially supported. I think it would be better to exclude this from the main PR ( https://github.com/pure-data/pure-data/pull/1455) and only offer this as a secondary PR (that you can rebase regularly on top of the other one).
In particular, please don't include any GUI dialog messages. Those are really internal. Also, don't advertize "coords" (at least you didn't mention "donecanvasdialog") because that one should really be replaced by https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd release :-)
I think including dynamic patching would "taint" your otherwise great documentation updates.
Christof On 26.11.2021 21:05, Alexandre Torres Porres wrote:
the reason I ask for revisions here is that I'm not an expert on this dark magic, so I'm not 100% sure about things. I can revert the commit in the PR and keep it on the fridge for the next release update if the real wizards see problems on it.
Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres < porres@gmail.com> escreveu:
I could just send the main Patch, but it just works best if you have all of the current state of the reference folder and also check other changes I'm proposing in this PR, so see attachment of the whole thing.
I got a rather broken keyboard, so I must be generating more typos than usual. Will need to revise it!
note that [Pd-messages] gets called in the help files of [send-receive], 'message boxes' and [namecanvas], all of them have been rewritten as well.
cheers
Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < porres@gmail.com> escreveu:
People, I'm on a roll here, updating much of the help files and documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching"
I'd like you people to revise it.
Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c90...
already in an open PR
Cheers
_______________________________________________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
Em sex., 26 de nov. de 2021 às 17:18, Christof Ressi info@christofressi.com escreveu:
don't advertize "coords" (at least you didn't mention "donecanvasdialog") because that one should really be replaced by https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd release :-)
yeah, makes sense to wait for this. Now, is the next '0.52-0 final'? :) i know it's not :(
I don't see a mention to these messages: mouse, mouseup, mousedown, relocate. And also all other messages related to gui stuff.
It could also be clearly mentioned that subpatches receive messages sent to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those.
People, I'm on a roll here, updating much of the help files and documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching"
I'd like you people to revise it.
Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c90...
already in an open PR
Cheers
Em sex., 26 de nov. de 2021 às 20:19, João Pais jmmmpais@gmail.com escreveu:
I don't see a mention to these messages: mouse, mouseup, mousedown, relocate. And also all other messages related to gui stuff.
yeah, I didn't put it. It felt like something hard to document and for more extreme cases. And now that Christof says I should really keep out of this dark corner, I wonder if I did right.
It could also be clearly mentioned that subpatches receive messages sent to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those.
how isn't it clearly mentioned?
+1 to having them in the docs but clearly labelled as something along the lines of "not in the public API - may change without notice". That kind of stuff is really helpful to people coming up on the whole system to better understand how it all works.
my two cents Canadian. :-)
On Fri, Nov 26, 2021 at 4:15 PM Alexandre Torres Porres porres@gmail.com wrote:
Em sex., 26 de nov. de 2021 às 20:19, João Pais jmmmpais@gmail.com escreveu:
I don't see a mention to these messages: mouse, mouseup, mousedown, relocate. And also all other messages related to gui stuff.
yeah, I didn't put it. It felt like something hard to document and for more extreme cases. And now that Christof says I should really keep out of this dark corner, I wonder if I did right.
It could also be clearly mentioned that subpatches receive messages sent to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those.
how isn't it clearly mentioned? _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sex., 26 de nov. de 2021 às 20:19, João Pais jmmmpais@gmail.com escreveu:
I don't see a mention to these messages: mouse, mouseup, mousedown, relocate. And also all other messages related to gui stuff.
yeah, I didn't put it. It felt like something hard to document and for more extreme cases. And now that Christof says I should really keep out of this dark corner, I wonder if I did right.
I don't remember now exactly why these methods are "dangerous" and "unofficial" (it was discussed already a lot in the list anyway), but I've been using them for more than 15 years with no big issues. If any of these methods is cut, then my patches won't work anymore - hopefully someone else's as well.
It could also be clearly mentioned that subpatches receive messages sent to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those.
how isn't it clearly mentioned?
The first one is mentioned in [pd Dynamic-Patching], although it might be easier to understand if there is an example immediately under the text. But there are enough examples of [s pd-xxxx] in the patch anyway to deduce it.
The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts.
If any of these methods is cut, then my patches won't work anymore - hopefully someone else's as well.
You are using private APIs. Nobody made a guarantee that it would work forever.
That being said, we try not to change - let alone remove - those methods unless absolutely necessary.
but I've been using them for more than 15 years with no big issues.
Well, a few years ago Miller changed the [donecanvasdialog( message. I noticed that it will break dynamic patching and asked him to use a workaround. He was nice enough to do it. So you were just lucky ;-)
Note that the messages found in Pd patch files, like [obj ...(, are pretty stable. We can't really change them without breaking literally all existing patches. However, anything else should really be considered private. Particularly mnssages like [mouse(, [mouseup(, [donecanvasdialog( are obviously internal messages sent between Pd core and the GUI process. People just discovered them in the source code (or by watching the GUI/Pd traffic) and started (ab)using them for dynamic patching. The Pd extended folks included them in their documentation, so usage became more wide-spread. However, it was never officially supported in Pd vanilla.
Christof
On 27.11.2021 12:22, João Pais wrote:
Em sex., 26 de nov. de 2021 às 20:19, João Pais jmmmpais@gmail.com escreveu:
I don't see a mention to these messages: mouse, mouseup, mousedown, relocate. And also all other messages related to gui stuff.
yeah, I didn't put it. It felt like something hard to document and for more extreme cases. And now that Christof says I should really keep out of this dark corner, I wonder if I did right.
I don't remember now exactly why these methods are "dangerous" and "unofficial" (it was discussed already a lot in the list anyway), but I've been using them for more than 15 years with no big issues. If any of these methods is cut, then my patches won't work anymore - hopefully someone else's as well.
It could also be clearly mentioned that subpatches receive messages sent to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those.
how isn't it clearly mentioned?
The first one is mentioned in [pd Dynamic-Patching], although it might be easier to understand if there is an example immediately under the text. But there are enough examples of [s pd-xxxx] in the patch anyway to deduce it.
The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
but I've been using them for more than 15 years with no big issues.
Well, a few years ago Miller changed the [donecanvasdialog( message. I noticed that it will break dynamic patching and asked him to use a workaround. He was nice enough to do it. So you were just lucky ;-)
Note that the messages found in Pd patch files, like [obj ...(, are pretty stable. We can't really change them without breaking literally all existing patches. However, anything else should really be considered private. Particularly mnssages like [mouse(, [mouseup(, [donecanvasdialog( are obviously internal messages sent between Pd core and the GUI process. People just discovered them in the source code (or by watching the GUI/Pd traffic) and started (ab)using them for dynamic patching. The Pd extended folks included them in their documentation, so usage became more wide-spread. However, it was never officially supported in Pd vanilla.
yes, at some point it would be good to assume that they can stay and keep being abused (I forgot why they are "illegal"), and when possible new methods should come out to replace them.
(I forgot why they are "illegal"),
They are not "illegal", they are private. As I tried to explain in the last mail, messages like "donecanvasdialog" or "mouseup" are used for Pd core <-> GUI communication. The only reason why they exist in the first place is because Pd core and GUI live in different processes, otherwise they could simply be C function calls.
The nice thing about a private API is that you can change/extend it at will. Once the private API becomes public, this becomes hard or even impossible.
Now, the problem with Pd is that it doesn't really have a mechanism to prevent users from calling those internal messages. (The only exception being the "dsp" method.)
and when possible new methods should come out to replace them.
I think that's where we should put our focus on. Things like emulating mouse interaction by sending "mouse" and "mouseup" messages are a huge red flag. The user is obviously trying to achieve something and we should ask ourselves what it is exactly and how this could be done in a more sane way. So maybe a good start would be to collect different dynamic patching use cases and then think about possible new APIs that could help achieve them.
My "goprect" PR is just one step in this direction.
[iemguts] is also a good example of this approach: it basically provides a stable public API over a unstable private APIs. The advantage is that whenever Pd changes the implementation, only [iemguts] needs to be updated, instead of every patch that directly uses the internal message. For example, with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external...
Christof
On 27.11.2021 14:32, João Pais wrote:
but I've been using them for more than 15 years with no big issues.
Well, a few years ago Miller changed the [donecanvasdialog( message. I noticed that it will break dynamic patching and asked him to use a workaround. He was nice enough to do it. So you were just lucky ;-)
Note that the messages found in Pd patch files, like [obj ...(, are pretty stable. We can't really change them without breaking literally all existing patches. However, anything else should really be considered private. Particularly mnssages like [mouse(, [mouseup(, [donecanvasdialog( are obviously internal messages sent between Pd core and the GUI process. People just discovered them in the source code (or by watching the GUI/Pd traffic) and started (ab)using them for dynamic patching. The Pd extended folks included them in their documentation, so usage became more wide-spread. However, it was never officially supported in Pd vanilla.
yes, at some point it would be good to assume that they can stay and keep being abused (I forgot why they are "illegal"), and when possible new methods should come out to replace them.
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi info@christofressi.com escreveu:
with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external...
how exactly? please elaborate and give examples, I'm curious
Two examples that come to my mind:
No need to emulate mouse selection with "mouse" and "mouseup".
resp. [iemguts/canvasobjectposition]
Are there any other use cases for "mouse" and "mouseup"?
On 27.11.2021 16:47, Alexandre Torres Porres wrote:
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi info@christofressi.com escreveu:
with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external...
how exactly? please elaborate and give examples, I'm curious
nice!
Em sáb., 27 de nov. de 2021 às 13:04, Christof Ressi info@christofressi.com escreveu:
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by index. No
need to emulate mouse selection with "mouse" and "mouseup".
- canvases/objects can be moved around with [iemguts/canvasposition]
resp. [iemguts/canvasobjectposition]
Are there any other use cases for "mouse" and "mouseup"? On 27.11.2021 16:47, Alexandre Torres Porres wrote:
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < info@christofressi.com> escreveu:
with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external...
how exactly? please elaborate and give examples, I'm curious
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Perhaps referring to this black magic library is something I could do in the document.
Em sáb., 27 de nov. de 2021 às 13:18, Alexandre Torres Porres < porres@gmail.com> escreveu:
nice!
Em sáb., 27 de nov. de 2021 às 13:04, Christof Ressi < info@christofressi.com> escreveu:
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by index.
No need to emulate mouse selection with "mouse" and "mouseup".
- canvases/objects can be moved around with [iemguts/canvasposition]
resp. [iemguts/canvasobjectposition]
Are there any other use cases for "mouse" and "mouseup"? On 27.11.2021 16:47, Alexandre Torres Porres wrote:
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < info@christofressi.com> escreveu:
with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external...
how exactly? please elaborate and give examples, I'm curious
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
if I remember correctly iemguts also adds the possibility of deleting objects without the need to simulate a mouse select and a keyboard stroke (cut? idk..)
(I don't know, but I think there was something about deleting with mouse emulation, but this was buggy too since you need to first bring the canvas to front, and then emulate the mouse... no idea, but yeah, this is bad, and iemguts makes deleting very easy)
Em sáb., 27 de nov. de 2021 13:04, Christof Ressi info@christofressi.com escreveu:
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by index. No
need to emulate mouse selection with "mouse" and "mouseup".
- canvases/objects can be moved around with [iemguts/canvasposition]
resp. [iemguts/canvasobjectposition]
Are there any other use cases for "mouse" and "mouseup"? On 27.11.2021 16:47, Alexandre Torres Porres wrote:
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < info@christofressi.com> escreveu:
with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external...
how exactly? please elaborate and give examples, I'm curious
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
You know, data structures explicitly use messages to subpatches, like 'clear' and 'read/write'. So at least these are official. And the namecanvas help file had the example to make the patch create messages and we can agree this is pretty stable and used in patches. Also, 'connect' messages are used in patches and the syntax won't likely change (so won't 'disconnect').
So this leaves us me touching a dark corner apparently only when talking about 'coords' and I guess I can have a warning about it. And we change and document your PR when it gets in. I can also refer to iemguts for more stable and further wizardry.
Em sáb., 27 de nov. de 2021 às 13:27, José de Abreu abreubacelar@gmail.com escreveu:
if I remember correctly iemguts also adds the possibility of deleting objects without the need to simulate a mouse select and a keyboard stroke (cut? idk..)
(I don't know, but I think there was something about deleting with mouse emulation, but this was buggy too since you need to first bring the canvas to front, and then emulate the mouse... no idea, but yeah, this is bad, and iemguts makes deleting very easy)
Em sáb., 27 de nov. de 2021 13:04, Christof Ressi info@christofressi.com escreveu:
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by index.
No need to emulate mouse selection with "mouse" and "mouseup".
- canvases/objects can be moved around with [iemguts/canvasposition]
resp. [iemguts/canvasobjectposition]
Are there any other use cases for "mouse" and "mouseup"? On 27.11.2021 16:47, Alexandre Torres Porres wrote:
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < info@christofressi.com> escreveu:
with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external...
how exactly? please elaborate and give examples, I'm curious
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
if I remember correctly iemguts also adds the possibility of deleting objects without the need to simulate a mouse select and a keyboard stroke (cut? idk..)
Yes! [iemguts] adds a "delete" method to the canvas class so that you can delete individual objects by index.
On 27.11.2021 17:25, José de Abreu wrote:
if I remember correctly iemguts also adds the possibility of deleting objects without the need to simulate a mouse select and a keyboard stroke (cut? idk..)
(I don't know, but I think there was something about deleting with mouse emulation, but this was buggy too since you need to first bring the canvas to front, and then emulate the mouse... no idea, but yeah, this is bad, and iemguts makes deleting very easy)
Em sáb., 27 de nov. de 2021 13:04, Christof Ressi info@christofressi.com escreveu:
Two examples that come to my mind: 1) [iemguts/canvasselect] allows to (de)select objects simply by index. No need to emulate mouse selection with "mouse" and "mouseup". 2) canvases/objects can be moved around with [iemguts/canvasposition] resp. [iemguts/canvasobjectposition] Are there any other use cases for "mouse" and "mouseup"? On 27.11.2021 16:47, Alexandre Torres Porres wrote:
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi <info@christofressi.com> escreveu: with [iemguts] there really is no reason to ever use "mouse" and "mouseup" again. Unfortunately, many people seem to prefer undocumented internal messages over a well tested external... how exactly? please elaborate and give examples, I'm curious
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sáb., 27 de nov. de 2021 às 08:23, João Pais jmmmpais@gmail.com escreveu:
It could also be clearly mentioned that subpatches receive messages sent
to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those.
how isn't it clearly mentioned?
The first one is mentioned in [pd Dynamic-Patching], although it might be easier to understand if there is an example immediately under the text.
what do you mean by "immediately under the text"?
As you can see, I have two categories in this documentation file, both highlighted and separated. They are: *"Messages to Pd"* (even though I also document a couple of messages *"from"* Pd, namely: pd-dsp-started/stopped).
The other section is "*Messages you can send to Pd files and canvases*", so yeah, this is where I document this, cause this is its category and it only makes sense. And I clearly document all that you say here right in the first paragraph. Quoting my text "*You can communicate with a Pd window by sending messages to the name of the file (which communicates to the main window). You can also commucate with a subpatch's window by sending messages to the subpatch's name. In both cases you need to preceed the send name with 'pd-'. Alternatively you can name a main window or a subpatch with [namecanvas].*" You can see then that I ask people to check the help file of [namecanvas], which has also been quite updated and also gives the same information and uses some examples and refers back to this document.
But there are enough examples of [s pd-xxxx] in the patch anyway to deduce
it.
'deduce' it? Well, if you read that text, there's nothing to deduce :)
The second isn't mentioned at all, the search results for "abstraction" and
".pd" return elements in other types of contexts.
You can see I also mentioned, in the same way as subpatches, that you can communicate with Pd patches, and I also have examples for that case so people could 'deduce' if I hadn't mentioned.
I guess I can be more clear that an abstraction is a Pd file, but that seemed obvious to me. I also didn't want to give an explicit example with an abstraction cause then I'd have to create yet another file. But this might be a good thing to call them both in th help file of namecanvas and this pd-message file.
But I also made it clear how [namecanvas] is useful for abstractions in its help file, that I emphatically tell people to check for reference. And I don't think it makes sense to talk to an abstraction using its filename, cause you can't just communicate with a single abstraction. I also don't know of a use case that from a parent patch you need to send messages to abstractions like that. Seems like the sane way to communicate with abstractions is via inlets.
I can only see a reason to change the main patch window of an abstraction from within the abstraction, to edit, for instance, is graph size. But in this case it makes sense to use [namecanvas] with a local name using "$0".
For now I guess I can make a more modest mentioning about this issue and how you probably want to use [namecanvas] in as abstraction's main window instead of sending messages to its filename. I dunno, maybe first we need to agree if it makes sense at all for me to document "messages to files/canvases", which ones, etc...
cheers
just adding to my previous email below on how namecanvas talks about abstractions. It actually already did talk before, but I made it more clear, saying "*This is sometimes the only way to send a message to a canvas when initializing graph-on-parent abstractions with local parameters (using "$0" to give it a local name).*"
It's not that all too clear, but then, but I guess this is all a good reference that belongs in the documentation. It'll never replacce a dynamic patching tutorial, and maybe we need that too to make all things clear, but that's for later, and maybe ccan be achieved by third party tutorials, like my "Live Electronics Tutorial" that I'm also expanding to include tutorials on Data Structures and stuff...
Em sáb., 27 de nov. de 2021 às 13:18, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sáb., 27 de nov. de 2021 às 08:23, João Pais jmmmpais@gmail.com escreveu:
It could also be clearly mentioned that subpatches receive messages sent
to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those.
how isn't it clearly mentioned?
The first one is mentioned in [pd Dynamic-Patching], although it might be easier to understand if there is an example immediately under the text.
what do you mean by "immediately under the text"?
As you can see, I have two categories in this documentation file, both highlighted and separated. They are: *"Messages to Pd"* (even though I also document a couple of messages *"from"* Pd, namely: pd-dsp-started/stopped).
The other section is "*Messages you can send to Pd files and canvases*", so yeah, this is where I document this, cause this is its category and it only makes sense. And I clearly document all that you say here right in the first paragraph. Quoting my text "*You can communicate with a Pd window by sending messages to the name of the file (which communicates to the main window). You can also commucate with a subpatch's window by sending messages to the subpatch's name. In both cases you need to preceed the send name with 'pd-'. Alternatively you can name a main window or a subpatch with [namecanvas].*" You can see then that I ask people to check the help file of [namecanvas], which has also been quite updated and also gives the same information and uses some examples and refers back to this document.
But there are enough examples of [s pd-xxxx] in the patch anyway to deduce
it.
'deduce' it? Well, if you read that text, there's nothing to deduce :)
The second isn't mentioned at all, the search results for "abstraction"
and ".pd" return elements in other types of contexts.
You can see I also mentioned, in the same way as subpatches, that you can communicate with Pd patches, and I also have examples for that case so people could 'deduce' if I hadn't mentioned.
I guess I can be more clear that an abstraction is a Pd file, but that seemed obvious to me. I also didn't want to give an explicit example with an abstraction cause then I'd have to create yet another file. But this might be a good thing to call them both in th help file of namecanvas and this pd-message file.
But I also made it clear how [namecanvas] is useful for abstractions in its help file, that I emphatically tell people to check for reference. And I don't think it makes sense to talk to an abstraction using its filename, cause you can't just communicate with a single abstraction. I also don't know of a use case that from a parent patch you need to send messages to abstractions like that. Seems like the sane way to communicate with abstractions is via inlets.
I can only see a reason to change the main patch window of an abstraction from within the abstraction, to edit, for instance, is graph size. But in this case it makes sense to use [namecanvas] with a local name using "$0".
For now I guess I can make a more modest mentioning about this issue and how you probably want to use [namecanvas] in as abstraction's main window instead of sending messages to its filename. I dunno, maybe first we need to agree if it makes sense at all for me to document "messages to files/canvases", which ones, etc...
cheers
The first one is mentioned in [pd Dynamic-Patching], although it might be easier to understand if there is an example immediately under the text.
what do you mean by "immediately under the text"?
just a couple of objects under the paragraph where it explains it. then it's more didactical - although the whole patch is full of such examples, anyway.
The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts.
You can see I also mentioned, in the same way as subpatches, that you can communicate with Pd patches, and I also have examples for that case so people could 'deduce' if I hadn't mentioned.
I guess I can be more clear that an abstraction is a Pd file, but that seemed obvious to me. I also didn't want to give an explicit example with an abstraction cause then I'd have to create yet another file. But this might be a good thing to call them both in th help file of namecanvas and this pd-message file.
I think you didn't understand - if you have an abstraction called "abs1" used in the patch, sending messages to pd-abs1 won't work. They need to be sent to pd-abs1.pd - and that could be clearly named in the documentation.
But I also made it clear how [namecanvas] is useful for abstractions in its help file, that I emphatically tell people to check for reference. And I don't think it makes sense to talk to an abstraction using its filename, cause you can't just communicate with a single abstraction. I also don't know of a use case that from a parent patch you need to send messages to abstractions like that. Seems like the sane way to communicate with abstractions is via inlets.
I have an abstraction which is a midiroll-type of score with more than 35000 structs. As this is calculated dynamically when the main patch opens, so that I don't have to overload pd when programming. This is used only for the graphical display, so there are no other objects besides the structs. It is a quite peculiar situation,anyway.
Em dom., 28 de nov. de 2021 às 16:33, João Pais jmmmpais@gmail.com escreveu:
I think you didn't understand - if you have an abstraction called "abs1" used in the patch, sending messages to pd-abs1 won't work. They need to be sent to pd-abs1.pd - and that could be clearly named in the documentation.
Oh, I see! Yes, there's a very good reason I didn't put that in the documentation: I had no idea that's how it works :)
It is a quite peculiar situation,anyway.
Then I'll just add the remark that abstractions need ".pd", but you should most probably just use [namecanvas].
thanks
I realize now how this can be useful and important to make abstractions fire a loabdang if they are created via dynamic patching!
Well, I added this information then, with examples.
Em dom., 28 de nov. de 2021 às 17:30, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em dom., 28 de nov. de 2021 às 16:33, João Pais jmmmpais@gmail.com escreveu:
I think you didn't understand - if you have an abstraction called "abs1" used in the patch, sending messages to pd-abs1 won't work. They need to be sent to pd-abs1.pd - and that could be clearly named in the documentation.
Oh, I see! Yes, there's a very good reason I didn't put that in the documentation: I had no idea that's how it works :)
It is a quite peculiar situation,anyway.
Then I'll just add the remark that abstractions need ".pd", but you should most probably just use [namecanvas].
thanks