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