On Wed, 2016-11-30 at 21:58 +0000, Jonathan Wilkes wrote:
Hey all
After watching "Future Pd Developments" round-table (thanks to
everyone involved for the effort to record/put online), I feel like poking some more into the structured list idea. Some of the conclusions that came up:
* Something like [list args] as a way to get all given arguments
as a list would be utterly helpful.
Please don't name it that. [list] objects currently operate on incoming lists or take an incoming symbol and output it as a list. In both cases the output is generated from the data arriving at the inlet (and in the latter case at least the name tells you exactly what kind of non-list data to feed it).
[list args] would instead operate on load time data associated with its parent glist. In the common case where a user creates it on a toplevel canvas, it also has the drawback of not outputting a sane default-- i.e., an outgoing "bang" doesn't give you any clue about what "args" refers to.
It was not my choice, but I find your points plausible.
General comment: Didn't we talk about abusing the comma atom for situations like this?
So [myOSCabstraction selector1 foo bar, selector2 bing bang, selector3 something else]
Then inside of that
[loadbang] | [myArgParser selector2] <-- get the "selector2" part of the args | [list prepend set] | [list trim] | [oscformat]
The benefit is that "selector2" is an arbitrary symbol in your own language that tells you and other users something about its data. $2, or even $@- 2, only tells you where it came from, which is incidental and not as meaningful. I.e., compare:
[unpack 0 0 0 0 0] | [$2 $1 $3 $4 $5] | [s voice3]
to
[get note a d s r pitch] | [pack 0 0 0 0 0] | [s voice3]
Oh, I like that!
Roman