[PD] abstraction setting its own arguments
Mathieu Bouchard
matju at artengine.ca
Sun Aug 1 19:40:11 CEST 2010
On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
> * the magical [inlet] message on loadbang is weird and will cause a
> crash in winxp if you happen to remove the abstraction's inlet.
You mean you don't get the following error message ?
« error: [args hello (world a 42) *] inlet 0 method loadbang:
can't send init-messages, because object has no [inlet] »
> * sending output from [args] on loadbang is redundant when
> [loadbang]-[args] is so trivial.
lots of shortcuts are trivial individually, then pile up to make a
difference.
The problem with auto-[loadbang] in args is that [loadbang] order is a
dangerous thing (which I forgot to think about when designing that part of
[args]... not sure what to do with it now... a bit hard to undo).
> Is there anything [args] can currently do that wouldn't be possible by
> taking an "anything" at its inlet?
What would be the meaning of that "anything" ?
you mean plugging [loadbang]-[list append $@] into it ?... maybe it would
work, but it would be two more objects per abstraction, too. (and it
wouldn't be a "anything". why "anything" ?)
> Additionally, your method of using commas to separate named init values
> assumes that the pd programmer doesn't want to send commas as arguments
> (which I did want to do in my [expr] example).
I expect to add this feature whenever someone needs it :
[args *, nocommas]
would consider commas as non-special. Also :
[args *, nocommas, noparens]
would completely disable special parsing. But it's also possible that the
syntax would be :
[args *, commas 0, parens 0]
a 0/1 attribute specified without a value defaults to 1. I haven't really
thought about a rule for what is better, negative bools (names with "no"
in them) when they sound good (mainly for exceptional cases), or positive
bools all over.
> So what I'm saying is that your [args] doesn't fit my needs, and $@
> wouldn't fit everyone's needs, but $@ + [args] +
> [other_parsers_as_needed] would fit the maximum number of needs
You know, passing [loadbang]-[list append $@]-[args] isn't making [args]'s
code any shorter than with an autonomous [args] as it is now.
And then, for the handling of abstractions' properties dialogues, I'm
going to do something rather close to a list-method for [args], without
doing it : I'm going to use [setargs] just before re-banging the [args].
It's the only way I can think of using [args] with an input that is not
just the original arguments of the abstraction-instance...
> without burdening the users with learning a completely different way of
> getting args every time they want to do something different with them.
I'm all for adding $@ to pd-extended, but by itself, its inclusion in
pd-extended doesn't seem like a reason to change anything in [args] at
all. In any case, if you feel like $@ has to be included in pd-extended,
that's something you have to talk to Hans about.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
More information about the Pd-list
mailing list