<div dir="ltr"><div dir="ltr">some thoughts:<br><div><br>i think that sigmund~ is ok with flags that come last, because of the way that sigmund~ parses its arguments. It doesn't impose any order, since the user will create it the way it wants ([sigmund~ env pitch] and [sigmund~ pitch env] are both valid and gets its outlets swapped, and it is ok), so for sigmund~ the point of view is that all arguments needs to be parsed and if you throw a flag in the middle, it will be parsed accordingly, so even if you put a flag in the middle (like [sigmund~ env -npts 512 pitch]) it will also work.<br><br></div><div>but not all objects works if the flags appear in different order, and this actually confuses me more than sigmund~<br><br></div><div>for example<br><br></div><div>[netreceive -u 5000] will listen to port 5000 and will use udp protocol,<br></div><div>but<br></div><div>[netreceive 5000 -u] will listen to port 5000 and use tcp protocol!! -u is ignored in this case... <br><br></div><div>(you can check this using pdsend... for the first case "pdsend 5000 localhost udp" will work, but for the second it doesn't... it only works with "pdsend 5000 localhost tcp")<br><br></div><div>but on the other hand, pd also has the opposite case, where flags comes in the end, they are on the text family objects, specifically the [text sequence] object<br><br>[text sequence text-help-seq2 -g], the -g goes after the creation argument with the name of the text... and -w or -t also goes in the end<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em dom., 27 de fev. de 2022 às 14:22, 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">I didn't mean to define things in a broader sense outside the context of Pd. I'm just concerned in defining what is the "official" settings and behaviour of flags in Pd.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em dom., 27 de fev. de 2022 às 06:33, IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>> escreveu:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
that's typically not how it works. see Postel's law.<br></blockquote><div><br></div><div>I see. It's not actually a bug if you allow non-conformant input, as long as the meaning is clear. But the point here is to define what is the correct way, in order to document it as such.</div><div><br></div><div>Lots of people use a bogus symbol argument for inlet (such as [inlet hz]) and Pd allows it, even though it is meaningless and non-conformant input, but the point is that it is not documented and it shouldn't be. In the same way you can have [osc~ 440 hz(cycles-per-second)] and [osc~] will not complain that it is meaningless and that's fine.</div><div><br></div><div>But this is a bit different, it's something that is meaningful and that will work.</div><div><br></div><div>Therefore, my main concern here is to agree on what is the standard way and document it. And I believe the idea is that flags in pd are supposed to come first for optional settings, and I should not say that you can have it come later in [sigmund~], even though it works.</div><div> </div><div>I'm also concerned to conform to this principles in my externals.</div><div><br></div><div>Would it be weird or wrong to have an external that NEEDS to load flags AFTER the creation arguments? This has been necessary for parameters that take a non fixed number of elements. </div><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">
Pd has mostly adopted single-dash flags, both for cmdline args and for <br>
arguments.<br></blockquote><div><br></div><div>I think Pd has "only" adopted single-dash flags, right? Unless you mean externals out there have adopted things differently.</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">
that doesn't mean that other suffixes (e.g. '@') are "bugs". they are <br>
just uncommon.<br></blockquote><div><br></div><div>cyclone uses "@", but that's because MAX uses it (and calls it "attributes"). They can come later, though.</div><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">
- They're always optional<br>
<br>
i don't think so.<br></blockquote><div><br></div><div>I meant in Pd, but I remember now how [declare] works, and it only takes 'flags', so yeah, not really "optional".</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">
- They come before "actual" arguments.<br>
<br>
what do you mean by "actual arguments"?<br></blockquote><div><br></div><div>Arguments that are not flags, in [sigmund~] they'd be "pitch" and "env" for instance.</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">
I've never heard of anything like that. i guess you mean arguments that <br>
are not "flags" (named arguments), but what is typically called <br>
"positional arguments" (as their semantic is encoded in the position: <br>
the 1st argument means something else as the 2nd arg).<br></blockquote><div><br></div><div>yup</div><div> </div><div><br></div></div></div>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div></div>