The number of arguments is not fixed.

Thanks in advance for your help.

i think it is not possible to get the number of arguments in vanilla.

Possible solutions in vanilla:

• create a long list like above, read the list until it is zero
• dynamically create such list with one argument at a time until it is zero
• make the first argument the number of arguments and create the list with the right length to get the exact number. The other methods are only exact if you are certain that arguments are non-zero, at least at the end. An alternative would be to put a certain stop argument at the end.

In iemlib there is [dollarg], which does it.

EDIT: I downloaded the other version of iemlib from Deken and this one works. Thanks, I will use [dollarg] for now. If anybody else can come up with a universal way to do it vanilla-style that would be very interesting, but like you said it mightn't be possible.

For example-- suppose our parent abstraction is [foo 0]. Inside that abstraction we try [list append $1] which gives "0". We also try [list append $1-sym] which gives "0-sym". But we don't know if that means the abstraction arg was zero or there was no abstraction arg given.

So let us try abstraction [foo] with no args. Now inside foo we create [list append $1] which again gives us "0". That's no help at all. But now look at the output from [list append $1-sym]:

symbol \\$1-sym

When "$1" doesn't exist, Pd's string concatenation algorithm doesn't expand the dollararg to 0 but instead quotes it directly. Weird.

So now we've got an algorithm for finding the length of the list of args, which consequently means we can reproduce that list of args inside the abstraction:

(pseudocode)
check if [list append $1]--[$1-sym( is equal to [list append $1-sym]
if it isn't then you've got one less arguments than the dollararg you tried.
if it is equal then "add2" the value of the dollararg into a msg box and try with the next biggest dollarsign variable
...
at the end, bang out the msg box to get the full list of args

Notice that you must do this inside the canvas or subcanvas where you want to get the arguments. So you cannot modularize this algorithm inside an abstraction-- you must always paste a subpatch inside the relevant abstraction.

Or in Purr Data you can just do this:

[list append $@]

or this:

[args(
|
[canvasinfo]

get.arguments.vanilla.zip

This obviously needs to iterate a given number of arguments, which are pre-typed in the two [list append] objects. One step further would be to be able to have an indefinite number of arguments, and retrive the next one after each step. I tried like this and it doesn't work:

(and obviously break the [until] loop after the first non-match), but I don't think it's possible to set [float] or [list] to $n via the right inlet, but I'd love to hear if somebody knows how to.

The only other two ways I can think of to get around this is to either create each [list append $n] dinamically (might get tricky) or to just use the approach in the patch and pre-set the [list append]s to the maximum number of possible arguments an object can have (don't know if there is such a thing).

dollarg.zip

This also uses dynamic patching and the trick @jancsika described above.

Thanks a lot everyone!

get.dollarg.zip

It is shorter and more elegant than mine.

get.dollarg.zip

Thanks again everyone, this looks reliable enough to be used instead of the external.