<div dir="ltr">Found this thread (<a href="https://lists.puredata.info/pipermail/pd-list/2016-08/115936.html">https://lists.puredata.info/pipermail/pd-list/2016-08/115936.html</a>) some days ago... and then I have forked the IOhannes abstraction that Matt Barber mentions to deal with any number of arguments and to implement the attribute tag recognition. <div><br></div><div>This approach could be used to detect other kinds of "pseudo" types!<div><br></div><div>I hope it is usefull for other people!</div><div><a href="http://git.nics.unicamp.br/nicspd/patchTools/AnyArgumentsAndAttributes">http://git.nics.unicamp.br/nicspd/patchTools/AnyArgumentsAndAttributes</a><br></div><div><br></div><div>Cheers,</div><div>José</div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-18 13:08 GMT-03:00 Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey all<br>
<br>
After having worked with Python a bit, I'm very intrigued by the many<br>
useful data containers it provides (tuples, lists, sets,<br>
dictionaries). <br>
<br>
At the same time, I am sometimes troubled by the inflexibility of<br>
arguments in Pd. Writing abstractions that deal with a variable number<br>
of arguments is hard. Even retrieving the number of specified arguments<br>
inside the abstraction is hard. Also, if you have fixed argument part<br>
and a variable part, you need to make sure that the variable part is<br>
put at the end of the argument list, otherwise there is no way to<br>
distinguish them.<br>
<br>
I'm just thinking loud here and do not have any idea, how hard it would<br>
be to implement in Pd. I'm just trying to raise a discussion about the<br>
topic. Here some (probably not very thought-through) ideas:<br>
<br>
<br>
== GROUPING IN ABSTRACTION ARGUMENTS ==<br>
Allow grouping of atoms, so that you can pass a whole list to one<br>
single argument like this:<br>
<br>
[myabs ( one two 3 ) 4 five]<br>
<br>
inside the abstraction:<br>
<br>
$1 would evaluate to 'list one two 3' <br>
$2 would evaluate to '4'<br>
$3 would evaluate to '5'<br>
<br>
== GETTING NUMBER OF ARGS ==<br>
With the same example:<br>
<br>
[myabs ( one two 3 ) 4 five]<br>
<br>
inside the abstraction:<br>
<br>
$# would evaluate to '3' (number of arguments given)<br>
<br>
== GROUPING IN MESSAGES ==<br>
[1 2 ( 97 98 99 ) 4 5(<br>
|<br>
[$2 (<br>
<br>
<br>
would give '97 98 99'<br>
<br>
== NAMED ARGUMENTS ==<br>
<br>
[myabs freq=440 vol=1]<br>
<br>
inside the abstraction:<br>
<br>
$freq would evaluate to '440'<br>
$vol would evalute to '1'<br>
<br>
If a certain argument is not specified as creation argument, it would<br>
evaluate to '0' (similar to existing behavior).<br>
<br>
<br>
== USE CASE ==<br>
[oscformat] takes an arbitrary number of arguments to create an OSC<br>
address. While I find this the cleaner and more pd-like way than<br>
 /one/two/three, this has big draw-back. You currently cannot pass the<br>
OSC address (containing an arbitrary number of address fields) to an<br>
abstraction when using [oscformat]. The number of arguments must known<br>
beforehand when using this format. With [packOSC] from the osc library,<br>
you can do:<br>
<br>
[myabs /base/address]<br>
<br>
and therein:<br>
<br>
[packOSC $1/freq]<br>
<br>
which evaluates to /base/address/freq. <br>
<br>
By allowing grouping of arguments, one could achieve the same without<br>
resorting to long symbols (which has other drawbacks). In the main<br>
patch you could create:<br>
<br>
[myabs ( base address )]<br>
<br>
and therein:<br>
<br>
[oscformat $1 freq]<br>
<br>
and [oscformat] would actually see 'base address freq'.<br>
<br>
There are many other cool things you could do. It would allow to create<br>
lists of lists, which can be easily split again later (which is<br>
currently very hard to do and involves a lot of serializing and using<br>
delimiters or prepended number-of-elements). Generally, it would allow<br>
to create much more flexible abstractions.<br>
<br>
Any feedback welcome.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Roman<br>
<br>
<br>
<br>
<br>
  </font></span><br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">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/<wbr>listinfo/pd-list</a><br>
<br></blockquote></div><br></div></div></div>