I think we're talking about the same thing.
In matju's scheme, the abstraction author can make it possible for a user to type something like this: [myabstraction, something 1 2 3, something_else blah]
After the objects inside myabstraction are instantiated, it would output this from the leftmost inlet inside the abstraction: something 1 2 3 something_else blah
Then the abstraction author can [route something something_else] in order to use those messages to initialize whatever they want inside the abstraction. I assume this is what would happen in your scheme after the final [route bang] to the outlet at the end of the patch.
In fact you can do this in Pd Vanilla and obviate the symbol parsing/conversion. Try this: [named-arguments foo bar, height 12, cats miaow look ma an arbitrary number of values for this last named "arg"]
Break the list into sequences using [sel,]. It works because Pd's parser converts the comma atoms to symbols consisting of an escaped comma.
And you don't need [initbang] to do any of this. It's just useful to describe functionality I'm talking about.
-Jonathan
On Friday, October 24, 2014 12:18 AM, Chris McCormick chris@mccormick.cx wrote:
Hi Jonathan,
I am probably confused, or confusing here, but I was suggesting this as a mechanism whereby the author of an abstraction could have the abstraction accept named arguments set by a user of the abstraction.
In that light I am confused by what you've written below, sorry about that! You seem to be specifying a way for an abstraction to set up internal defaults, is that right?
I don't have access to "initbang" in the Pd I use yet.
Cheers,
Chris.
On 24/10/14 12:11, Jonathan Wilkes via Pd-list wrote:
Hi Chris, I prefer the idea of using the comma atom to send messages to an object/abstraction at init time.
Example: [bar 15 25( | [foo]
would be equivalent to
[initbang] | [foo, bar 15 25]
Benefits:
- messages can be type-checked or arbitrary length, just like any pd message
- eases development of externals. For instance, sigmund~ would have had
96 fewer lines of code because this syntax would have done away with the need for flags
- it looks like message-box syntax and behaves nearly the same
- once implemented, it would automatically apply (consistently) to every
internal/external object
- matju already implemented it in Gridflow
Drawbacks:
- [expr], [list], [select], [route], and a few others would need to be
treated specially to retain their current behavior regarding commas
- abstractions require some mechanism to retrieve those init-time
messages. I believe matju had them shoot out the leftmost inlet of the abstraction, with the assumption that the user would have a [route] sitting there to parse them. Another idea would be to retrieve them from an introspection object like [canvasinfo] (and maybe have another object which splits that into a sequence of messages).
-Jonathan On Thursday, October 23, 2014 11:28 PM, Chris McCormick chris@mccormick.cx wrote:
Hi all,
Here's a design pattern for passing named arguments ("bar=true foo=12") into an abstraction.
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list