<div dir="ltr">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 "<i>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).</i>"<div><br></div><div>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...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb., 27 de nov. de 2021 às 13:18, Alexandre Torres Porres <<a href="mailto:porres@gmail.com">porres@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb., 27 de nov. de 2021 às 08:23, João Pais <<a href="mailto:jmmmpais@gmail.com" target="_blank">jmmmpais@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It could also be clearly mentioned that subpatches receive
messages sent <br>
to pd-[subpatch], and abstractions are named
[abstraction].pd (if I'm <br>
recalling correctly) - unless there is a namecanvas used in
those.<br>
</blockquote>
<div><br>
</div>
<div>how isn't it clearly mentioned?</div>
</div>
</div>
</blockquote>
<p>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.</p></div></blockquote><div>what do you mean by "immediately under the text"?</div><div><br></div><div>As you can see, I have two categories in this documentation file, both highlighted and separated. They are: <b>"Messages to Pd"</b> (even though I also document a couple of messages <b>"from"</b> Pd, namely: pd-dsp-started/stopped).</div><div><br></div><div>The other section is "<b>Messages you can send to Pd files and canvases</b>", 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 "<i>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].</i>" 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.</div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p> But there are enough examples of [s pd-xxxx] in
the patch anyway to deduce it.</p></div></blockquote><div>'deduce' it? Well, if you read that text, there's nothing to deduce :) </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts.<br></p></div></blockquote><div>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. </div></div><div><br></div><div>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.</div><div><br></div><div>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. <br><br>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".</div><div><br></div><div>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...</div><div><br></div><div>cheers</div><div><br></div></div></div>
</blockquote></div>