Brian H.

I want to have an abstraction that takes a list of variable length as an argument. I also want to have a default list, in case there is no argument. It seems like once there is a list argument in [patcherargs], the flexibility of the number of items is gone.

In the example below, the default argument is a 5 item list. If I override the default with my own argument, and it has *fewer* items than the default, then a list of my argument + the end of the default argument.

button

message

inlet

outlet

patcherargs

Hi,
I want to have an abstraction that takes a list of variable length as an argument.  I also want to have a default list, in case there is no argument.  It seems like once there is a list argument in [patcherargs], the flexibility of the number of items is gone.

In the example below, the default argument is a 5 item list.  If I override the default with my own argument, and it has *fewer* items than the default, then a list of my argument + the end of the default argument.

What's the logic I'm missing here?
Thanks,
Brian


Hi,
I want to have an abstraction that takes a list of variable length as an argument.  I also want to have a default list, in case there is

-patcherargs-flexible-list-items

I couldn't work that out either a few months ago, so I made a workaround with [zl reg] and a delayed [loadbang]:

With any luck someone's got a better method.

I couldn't work that out either a few months ago, so I made a workaround with [zl reg] and a delayed [loadbang]: 

the only thing you can do is to filter out "0" - which means that "0" can also not be used in cases where you want it.

works great for say, a list of symbols as argument-to-patcher.

otherwise... you can always use quotation marks (yes that sucks) and send your list as one symbol into the patcher. in this case it can also be longer than 9 elements.

the only thing you can do is to filter out "0" - which means that "0" can also not be used in cases where you want it.

works great for say, a list of symbols as argument-to-patcher.

Do you guys think this is a bug? I don't see it as expected behavior...

Do you guys think this is a bug?  I don't see it as expected behavior...

My guess is that it's not a bug. One could expect one's own argument to completely override the default list, as with [zl reg]. But what happens isn't unusual in Max either, e.g. [pack] does it.

here's a workaround using Bill's patch as a starting point, just have to be sure to modify the 'zl reg' for your default choices:

(whether 'bug' or 'feature-request', either way, it would certainly be better to redesign 'patcherargs' to accomodate this... and makes me think: everything should work like python :D)

here's a workaround using Bill's patch as a starting point, just have to be sure to modify the 'zl reg' for your default choices: 

But currently it works in a very silly way, like Monty Python. ;-)

[patcherargs] flexible list items