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

Alexandre Torres Porres porres at gmail.com
Sat Nov 27 17:39:41 CET 2021


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 at gmail.com> escreveu:

>
>
> 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/bea2e4f5/attachment-0001.htm>


More information about the Pd-list mailing list