<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">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>