<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb., 5 de set. de 2020 às 09:04, 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 dir="ltr"><div> <br></div><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"><div dir="ltr">
João, you say it can't "embed" and save contents with the patch, but [text] allows you to do so with the "-k" flag, why don't you use it?

</div></blockquote><div><br></div><div> [text define] is the base for [jp.coll], and it has to be created dynamically at startup. also, apparently the contents are saved with the pd file in a line such as "#A set this is a message \; this is another 1 ... \;;" From what I tested this is saved with the patch where [text define] resides, which in this case it's the abstraction and not in the main patch. This would need to be changed in Pd's workings so that -k contents are saved on the main patch file.<br></div></div></div></blockquote><div><br></div><div>hmmm, I see. Then, what I'm thinking of is the [savestate] object, which is used for that. It should work very easily, right?<br></div><div><br></div><div> </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 class="gmail_quote"><div></div><div> </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">You also have not implemented assoc and deassoc, I'm thinking about that.<div><br></div><div>coll saves the text separating with a comma the index and the actual message. You can also do that with [text] and if you do so you could potentially use it to define and detect an address, and have something else associated with it - I hope you know what I mean and that I'm not too confused.</div></div></blockquote><div><br></div><div>this is the main reason why I didn't name it [jmmmp/coll] but 
[jmmmp/jp.coll]. Adding commas to a [text] messes up the number of lines - can be seen already in the help of [text get]. Now I remembered I could put the commas back in, and do an internal conversion for the line number. </div></div></div></blockquote><div><br></div><div>[text] will also tell you if the line ends with ";" or with "," - so you could use this to differentiate if it's an address or the data.</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 dir="ltr"><div class="gmail_quote"><div>Btw all (?) jmmmp objects are dependent on other jmmmp objects - mostly [f+]. Some of them have to rely on other libraries as well, but usually it's better to have the whole jmmmp together.</div></div></div></blockquote><div><br></div><div>The thing about offering a vanilla patch is that it can be used in stuff like libpd, camomile, etc... so someone may not want or can't have all of the library. Anyway, [f+] is very simple, and it can be easily replaced with [f] & [+] to become 100% full vanilla  and dependency free (an external vanilla abstraction is still an external dependency).</div><div><br></div><div>cheers</div></div></div>