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