[PD] documenting messages to/from Pd and dynamic patching

[Alexandre Torres Porres]

Em sáb., 27 de nov. de 2021 às 08:23, João Pais <jmmmpais at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211127/3006e8ae/attachment-0001.htm>