Is there any class that allows abstractions to set their own arguments ? It's important for making properties dialogues that can save args the same way that numbox (Ctrl+3) and IEMGUIs do.
Well, I just made one.
http://gridflow.ca/help/setargs-help.png
Does it seem like it's designed the right way ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Doesn't iemguts let you do that? Its a very nice library for all sorts of "introspection".
.hc
On Wed, 2010-07-28 at 13:11 -0400, Mathieu Bouchard wrote:
Is there any class that allows abstractions to set their own arguments ? It's important for making properties dialogues that can save args the same way that numbox (Ctrl+3) and IEMGUIs do.
Well, I just made one.
http://gridflow.ca/help/setargs-help.png
Does it seem like it's designed the right way ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 28 Jul 2010, Hans-Christoph Steiner wrote:
Doesn't iemguts let you do that?
How is one supposed to install iemguts ?
Its a very nice library for all sorts of "introspection".
[canvasargs] doesn't support commas nor semicolons, and most of all, doesn't update the objectbox, doesn't update the titlebar of the abstraction, and doesn't even update the canvas environment, so [symbol $1] can't read the new arguments.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
I haven't tested it yet but I think the "just like message boxes" design is a great idea.
Looking at the help-png: message boxes don't have a "clear" message. You just use "set" to clear them.
-Jonathan
--- On Wed, 7/28/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: [PD] abstraction setting its own arguments To: pd-list@iem.at Date: Wednesday, July 28, 2010, 7:11 PM
Is there any class that allows abstractions to set their own arguments ? It's important for making properties dialogues that can save args the same way that numbox (Ctrl+3) and IEMGUIs do.
Well, I just made one.
http://gridflow.ca/help/setargs-help.png
Does it seem like it's designed the right way ?
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 -----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 28 Jul 2010, Jonathan Wilkes wrote:
I haven't tested it yet but I think the "just like message boxes" design is a great idea. Looking at the help-png: message boxes don't have a "clear" message. You just use "set" to clear them.
damn. I don't know where I pulled this out of. [setargs] doesn't have a "clear" either. And I forgot to mention "add".
In the meanwhile, I added "adddollar" and "adddollsym" and I added $-resubstitution so that instance args are updated in the same manner as a new instance's args would be initialised.
Now I have two more questions :
how do I make the dollsym "$0-something-$1" in a messagebox ? it seems like I just can't.
how is one supposed to handle receive-symbols and send-symbols the way floatbox, symbolbox and IEMGUI do, with $ in them ? I need something to read the "raw args", before $-substitution.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 28 Jul 2010, Mathieu Bouchard wrote:
Now I have two more questions :
- how do I make the dollsym "$0-something-$1" in a messagebox ? it seems like I just can't.
(I mean using messagebox-edition commands like adddollsym)
Also,
- how do I make the dollsym "something-$1" in a messagebox ? it seems like I just can't.
- how is one supposed to handle receive-symbols and send-symbols the way floatbox, symbolbox and IEMGUI do, with $ in them ? I need something to read the "raw args", before $-substitution.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Wed, 7/28/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Wednesday, July 28, 2010, 10:46 PM On Wed, 28 Jul 2010, Mathieu Bouchard wrote:
Now I have two more questions :
1. how do I make the dollsym "$0-something-$1"
in a messagebox ?
it seems like I just can't.
(I mean using messagebox-edition commands like adddollsym)
Also,
3. how do I make the dollsym "something-$1" in a messagebox ? it seems like I just can't.
Ugly hack: you could dynamically patch the following to get $1-$2:
[2( | [adddollsym 1-$$1( | [ (
You have to dynamically patch because saving [$1-$$1( will give you [$1-$$1( the next time you load the patch.
I guess "adddollsym" was designed at a time when you could only put the dollarsign variable at the front of a dollsym.
-Jonathan
2. how is one supposed to handle receive-symbols
and send-symbols the
way floatbox, symbolbox and
IEMGUI do, with $ in them ?
I need something to read the
"raw args", before $-substitution.
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 28 Jul 2010, Jonathan Wilkes wrote:
[adddollsym 1-$$1( You have to dynamically patch because saving [$1-$$1( will give you [$1-$$1( the next time you load the patch.
That looks like a bug... is that $$1 behaviour documented anywhere ? Not only I haven't seen it in any documentation, I also don't remember anyone mentioning it. And then the change from $$ to $$ is definitely a bug, because something you can type by hand in a messagebox then save/load (or delete/undo or copy/paste...) shouldn't produce any characters that are forbidden to type, which are {} (but frankly the backslash is about the only one likely to occur in such bugs).
I guess "adddollsym" was designed at a time when you could only put the dollarsign variable at the front of a dollsym.
how about this ?
[adddollsym2 %0-something-%1 %(
Where $1 is the text for making the dollsym, and $2 is the character that will be replaced by a $ while making the dollsym. In this method, no initial $ will be assumed, which will address my question #3. So, if this solution is fine, then only question #2 would be left to answer.
Then it would be a good thing to add adddollsym2 to pd itself.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Thu, 7/29/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Thursday, July 29, 2010, 12:21 AM On Wed, 28 Jul 2010, Jonathan Wilkes wrote:
[adddollsym 1-$$1( You have to dynamically patch because saving [$1-$$1(
will give you [$1-$$1( the next time you load the patch.
That looks like a bug... is that $$1 behaviour documented anywhere ? Not only I haven't seen it in any documentation, I also don't remember anyone mentioning it. And then the change from $$ to $$ is definitely a bug, because something you can type by hand in a messagebox then save/load (or delete/undo or copy/paste...) shouldn't produce any characters that are forbidden to type, which are {} (but frankly the backslash is about the only one likely to occur in such bugs).
I guess "adddollsym" was designed at a time when you
could only put the dollarsign variable at the front of a dollsym.
how about this ?
[adddollsym2 %0-something-%1 %(
Where $1 is the text for making the dollsym, and $2 is the character that will be replaced by a $ while making the dollsym. In this method, no initial $ will be assumed, which will address my question #3. So, if this solution is fine, then only question #2 would be left to answer.
Then it would be a good thing to add adddollsym2 to pd itself.
That sounds like a good idea.
Since adddollsym currently ignores any additional args, couldn't you just add the functionality to adddollsym so that when there's no $2 it behaves as it currently does, but if there is a $2 it does what you describe? Or is it likely there's some patch out there that would depend on adddollsym always ignoring extra args? The only thing I can think of would be [list prepend adddollsym] | [list trim] | [ (
but that seems rather baroque.
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 28 Jul 2010, Jonathan Wilkes wrote:
That sounds like a good idea.
Ok, it's implemented already. You can try it if you checkout the svn trunk.
Since adddollsym currently ignores any additional args, couldn't you just add the functionality to adddollsym so that when there's no $2 it behaves as it currently does,
Well, if it were only a substitution thing, I could claim that the second argument of adddollsym defaults to the "$" character, and then the method would have a single case. But because the presence of a substitution char would also cause the method to not add an implicit leading "$", it looks more like two different methods stuck into just one.
What do you think ? Are there examples of methods that have multiple behaviours stuck together like that based on number of args ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Thu, 7/29/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Thursday, July 29, 2010, 1:15 AM On Wed, 28 Jul 2010, Jonathan Wilkes wrote:
That sounds like a good idea.
Ok, it's implemented already. You can try it if you checkout the svn trunk.
Since adddollsym currently ignores any additional
args, couldn't you just add the functionality to adddollsym so that when there's no $2 it behaves as it currently does,
Well, if it were only a substitution thing, I could claim that the second argument of adddollsym defaults to the "$" character, and then the method would have a single case. But because the presence of a substitution char would also cause the method to not add an implicit leading "$", it looks more like two different methods stuck into just one.
What do you think ? Are there examples of methods that have multiple behaviours stuck together like that based on number of args ?
I can't think of an example.
On another note: Is there a reason why you don't show an "add" message for [getargs] in the help-png?
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 28 Jul 2010, Jonathan Wilkes wrote:
Is there a reason why you don't show an "add" message for [getargs] in the help-png?
As I said in a previous mail yesterday, I forgot to mention "add". Then I didn't reupload the new version of the page. I just reuploaded it now. See it again now, with more details :
http://gridflow.ca/help/setargs-help.png
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Thu, 7/29/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Thursday, July 29, 2010, 5:06 PM On Wed, 28 Jul 2010, Jonathan Wilkes wrote:
Is there a reason why you don't show an "add" message
for [getargs] in the help-png?
As I said in a previous mail yesterday, I forgot to mention "add". Then I didn't reupload the new version of the page. I just reuploaded it now. See it again now, with more details :
Sorry, I see you did say that.
For accessing the args from an abstraction: do you have something in GF that works like your comment in patch id# 1543850?
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
For accessing the args from an abstraction: do you have something in GF that works like your comment in patch id# 1543850?
[args *] outputs all args at loadbang time. (in 9.10 you can also bang it later)
See http://gridflow.ca/help/args-help.png for more options.
Note that [args] does ()-parsing of those args, so [foo (1 2) 3] will be counted as having two args, (1 2) and 3.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Sat, 7/31/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Saturday, July 31, 2010, 5:53 PM On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
For accessing the args from an abstraction: do you
have something in GF that works like your comment in patch id# 1543850?
[args *] outputs all args at loadbang time. (in 9.10 you can also bang it later)
Right, but what I was asking about is more flexible because inside the abstraction you could have something like: [expr $@]
So I don't have to know how many args the user typed in (nor do I have to use dynamic patching at all).
Your suggestion for this feature was something that would expand to the nth arg + any following args, so I was wondering if you have that in GF.
-Jonathan
See http://gridflow.ca/help/args-help.png for more options.
Note that [args] does ()-parsing of those args, so [foo (1 2) 3] will be counted as having two args, (1 2) and 3.
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
Your suggestion for this feature was something that would expand to the nth arg + any following args, so I was wondering if you have that in GF.
I only have [args a b c *] outputting $4+following out of the right outlet.
If I had this feature in GridFlow, it wouldn't be working in [expr] anyway.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Sat, 7/31/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Saturday, July 31, 2010, 7:16 PM On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
Your suggestion for this feature was something that
would expand to
the nth arg + any following args, so I was wondering
if you have that
in GF.
I only have [args a b c *] outputting $4+following out of the right outlet.
If I had this feature in GridFlow, it wouldn't be working in [expr] anyway.
That's just an example. But I think it is the best way to handle getting args inside an abstraction because it obviates the need for all of the "arg-getting" objects scattered about pd-extended, and it's more flexible than any of them because you can expand the args directly in an object box like [$@].
Then maybe "$@4" could mean "everything from $4 to the last arg".
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
That's just an example. But I think it is the best way to handle getting args inside an abstraction because it obviates the need for all of the "arg-getting" objects scattered about pd-extended,
It still wouldn't support non-default defaults of [args], nor support the ()-parsing that [args] does, nor handle the comma-message feature of [args]. I think that you are making overly broad assumptions about people's needs.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Sat, 7/31/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Saturday, July 31, 2010, 9:12 PM On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
That's just an example. But I think it is the
best way to handle getting args inside an abstraction because it obviates the need for all of the "arg-getting" objects scattered about pd-extended,
It still wouldn't support non-default defaults of [args], nor support the ()-parsing that [args] does, nor handle the comma-message feature of [args]. I think that you are making overly broad assumptions about people's needs.
I'll definitely have to play around with [args]. Some things I see up front are:
- the magical [inlet] message on loadbang is weird and will cause a
crash in winxp if you happen to remove the abstraction's inlet.
- sending output from [args] on loadbang is redundant when
[loadbang]-[args] is so trivial.
Ok, I certainly don't have the know-how to refactor $@ for inclusion in Pd-extended, but here's my thought: it's more flexible to have one standard "arg-getter" like $@ and one or more "arg parsers" than it is to have one or more "arg swiss army knives".
Is there anything [args] can currently do that wouldn't be possible by taking an "anything" at its inlet? Because currently, with [args]-- but without $@ in pd-ext-- I cannot create an object in an abstraction that has a variable number of args without relying on dynamic patching. In my experience this involved [expr] but there are probably other examples where this technique would come in handy. 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). 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 without burdening the users with learning a completely different way of getting args every time they want to do something different with them.
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
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
--- On Sun, 8/1/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Sunday, August 1, 2010, 7:40 PM 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.
No, it just crashes. But my bigger point is that it's really confusing behavior for messages to be coming out an inlet at loadbang time when nothing is actually connected to that inlet. Why did you choose to do that?
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).
Exactly. The clean patching solution for multiple loadbangs is pretty easy: [loadbang]-[t b b b etc.] . (I actually used that even before thinking about the problem of [loadbang] order because it just seemed like a simple, readable way to do it.)
Maybe you could have another object with a different name like [getargs] that doesn't do the loadbang.
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" ?
I don't know why I said "anything" and not "list". I guess I was thinking that $@ expands to an anything and not a list (unless the first arg is a float). But as you show, it would most likely arrive at [args] as a list anyway...
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" ?)
Yes, in this case I would say "list".
But since I'm working on clarifying the docs...
The word "anything" seems sometimes to be used in opposition to the list message, to refer to a multi-element message with a selector other than "list" (or a single-element message with selector other than bang, symbol, float, or pointer).
At other times it seems to mean any message that would be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. )
And at further other times, it seems like it means "other than x/y/z, anything", as in, "other than 11 reserved selectors, you can send anything to [bng] and it will trigger a bang."
Do any of these fit your definition of "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...
Why are [args] and [setargs] two separate objects?
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
On Mon, 2 Aug 2010, Jonathan Wilkes wrote:
« error: [args hello (world a 42) *] inlet 0 method loadbang: can't send init-messages, because object has no [inlet] »
No, it just crashes.
I suppose you can also find other situations in which GF crashes instead of reporting an error message ?
But my bigger point is that it's really confusing behavior for messages to be coming out an inlet at loadbang time when nothing is actually connected to that inlet.
It's confusing while you don't expect it. Once it's expected, it's not any more confusing than receive-symbols hidden inside IEMGUI properties dialogues.
Why did you choose to do that?
Because [args] used to have a right outlet to be connected to the top left [inlet] and it would always go across the whole patch in some ugly way. I could have made it left outlet instead, but figured out that if I could save a bit of boilerplate (usually a [t a] and two more wires) in every abstraction, I'd have that much less in every abstraction, and I wouldn't have to verify all abstractions to make sure that they support the init-commas.
Exactly. The clean patching solution for multiple loadbangs is pretty easy: [loadbang]-[t b b b etc.] . (I actually used that even before thinking about the problem of [loadbang] order because it just seemed like a simple, readable way to do it.)
That's not the only well-ordered one : you can do clear-looking partial ordering of loadbangs by using subpatches (with nesting or not). All subpatch [loadbang]s are guaranteed to be finished before their immediate parent's [loadbang]s.
Maybe you could have another object with a different name like [getargs] that doesn't do the loadbang.
I may as well do search-and-replace on all of GridFlow. I shouldn't care so much about backwards-compatibility when not only other people don't contribute abstractions to GF, but also, there's no one even saying something like « I use [args] ». Then why bother.
But at this point, my idea of it is to make it a comma-option in [args] :
[args foo bar *, noloadbang]
and then think some more before getting into anything not backwards-compatible.
The word "anything" seems sometimes to be used in opposition to the list message, to refer to a multi-element message with a selector other than "list" (or a single-element message with selector other than bang, symbol, float, or pointer).
bang is not a single-element message : it has no $1.
At other times it seems to mean any message that would be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. )
What does that case exclude ?... only "loadbang" and "dsp" ? (but then, not even necessarily).
And at further other times, it seems like it means "other than x/y/z, anything", as in, "other than 11 reserved selectors, you can send anything to [bng] and it will trigger a bang."
this is why method <any> appears last, for a given inlet or outlet.
Do any of these fit your definition of "anything"?
No. The one I mean here is more like : if you put $@ alone in a message box, you'll get "an anything" in the sense that the possible values of $@ make most any message possible. This includes the case where the value of $1 is "list", in which case the $1 of the output will be the $2 of the input. (In effect, this would be a shortcut of [list trim].)
Whereas you get "a list" if you write "list $@" in it because you can only make list-messages that way.
Why are [args] and [setargs] two separate objects?
Didn't really think about it. Any ideas ?
I suppose that there would be a point soon when I will have a better idea about what to do, but I only _started_ using [setargs] very recently, so, I don't know yet.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Mon, 8/2/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Monday, August 2, 2010, 6:09 PM On Mon, 2 Aug 2010, Jonathan Wilkes wrote:
« error: [args hello (world a 42) *] inlet 0
method
loadbang: can't send init-messages, because object
has no
[inlet] »
No, it just crashes.
I suppose you can also find other situations in which GF crashes instead of reporting an error message ?
That's the only I've seen so far. I haven't used GF much yet.
But my bigger point is that it's really confusing
behavior for messages to be coming out an inlet at loadbang time when nothing is actually connected to that inlet.
It's confusing while you don't expect it. Once it's expected, it's not any more confusing than receive-symbols hidden inside IEMGUI properties dialogues.
But IEMGUI receive-symbols don't make any assumptions about whether or not there is an inlet in a particular canvas. What if the abstraction in question doesn't have any xlets, but the user wants to use key/value pairs?
Actually there's a particular doc-related example I have in mind that would benefit from key/values in the args but doesn't have xlets. It might be something relevant to the GFDP, so I'll send it to you after I flesh it out.
Why did you choose to do that?
Because [args] used to have a right outlet to be connected to the top left [inlet] and it would always go across the whole patch in some ugly way. I could have made it left outlet instead, but figured out that if I could save a bit of boilerplate (usually a [t a] and two more wires) in every abstraction, I'd have that much less in every abstraction, and I wouldn't have to verify all abstractions to make sure that they support the init-commas.
Exactly. The clean patching solution for multiple
loadbangs is pretty easy: [loadbang]-[t b b b etc.] . (I actually used that even before thinking about the problem of [loadbang] order because it just seemed like a simple, readable way to do it.)
That's not the only well-ordered one : you can do clear-looking partial ordering of loadbangs by using subpatches (with nesting or not). All subpatch [loadbang]s are guaranteed to be finished before their immediate parent's [loadbang]s.
Maybe you could have another object with a different
name like [getargs] that doesn't do the loadbang.
I may as well do search-and-replace on all of GridFlow. I shouldn't care so much about backwards-compatibility when not only other people don't contribute abstractions to GF, but also, there's no one even saying something like « I use [args] ». Then why bother.
But at this point, my idea of it is to make it a comma-option in [args] :
[args foo bar *, noloadbang]
and then think some more before getting into anything not backwards-compatible.
The word "anything" seems sometimes to be used in
opposition to the list message, to refer to a multi-element message with a selector other than "list" (or a single-element message with selector other than bang, symbol, float, or pointer).
bang is not a single-element message : it has no $1.
Right. Other messages consisting of only a selector are part of this definition, too.
At other times it seems to mean any message that would
be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. )
What does that case exclude ?... only "loadbang" and "dsp" ? (but then, not even necessarily).
It includes those messages (well, maybe not "dsp" with signal objects-- that's special).
And at further other times, it seems like it means
"other than x/y/z, anything", as in, "other than 11 reserved selectors, you can send anything to [bng] and it will trigger a bang."
this is why method <any> appears last, for a given inlet or outlet.
Ok. I just explain it explicitly for those objects that require it.
Do any of these fit your definition of "anything"?
No. The one I mean here is more like : if you put $@ alone in a message box, you'll get "an anything" in the sense that the possible values of $@ make most any message possible. This includes the case where the value of $1 is "list", in which case the $1 of the output will be the $2 of the input. (In effect, this would be a shortcut of [list trim].)
How is your definition different than my 2nd one above?
Whereas you get "a list" if you write "list $@" in it because you can only make list-messages that way.
Why are [args] and [setargs] two separate objects?
Didn't really think about it. Any ideas ?
An [args] that does both setting and getting would be somewhat analogous to a "luxury" message box. You use all the same messages to set the content, and sending a bang would output the content. The big difference I guess is that with args you can tell it default values to output if there are no args, which you can't do with a message box.
I suppose that there would be a point soon when I will have a better idea about what to do, but I only _started_ using [setargs] very recently, so, I don't know yet.
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 2 Aug 2010, Jonathan Wilkes wrote:
--- On Mon, 8/2/10, Mathieu Bouchard matju@artengine.ca wrote:
I suppose you can also find other situations in which GF crashes instead of reporting an error message ?
That's the only I've seen so far. I haven't used GF much yet.
That's quite a problem, because I can't think of anything that would make this error message any more crash-prone than the standard error messages you get in GF externals (GF abstractions are a different matter though, because then, many error messages would come from Pd instead).
It's confusing while you don't expect it. Once it's expected, it's not any more confusing than receive-symbols hidden inside IEMGUI properties dialogues.
But IEMGUI receive-symbols don't make any assumptions about whether or not there is an inlet in a particular canvas.
My comparison with IEMGUI is to mean that once you start with the supposition that every message travels along a wire, you hit one exception with [r]/[s] and it's fine, then you hit another exception with hidden implicit [r]/[s] inside IEMGUI and floatatom/symbolatom and it's fine as well, and then you hit another exception with [args] and I don't know why it would be less fine.
What if the abstraction in question doesn't have any xlets, but the user wants to use key/value pairs?
If an object has no need for an inlet, then it doesn't matter whether there is one at all.
And then, the point of key/value pairs in left inlets is to ensure that every attribute is settable at runtime in the same manner as it is settable in the objectbox. It is enforcing a standard by making it convenient to follow the standard. Thus, the perspective of [args] on key/values is that objects that use them should have an [inlet] so that those attributes can be reconfigured at any time if the user wants it.
I could add an option to make it differently (actually, backward-compatible with the older [args] that didn't do that yet) but I don't really see a purpose for which I'd say « yes, it's a good idea to make this attribute non-reconfigurable ».
Actually there's a particular doc-related example I have in mind that would benefit from key/values in the args but doesn't have xlets.
You know, if it's a GOP, then the [inlet] can be hidden by putting any GOP-visible component on top of it. the GFDP components such as [doc_i] and [doc_m] are covering the inlet-space, at least in run-mode (those two particular classes only do so in run-mode).
I'm actually also toying with the idea of adding inlets to [doc_m] and such, during the « GFDP rewrite », that is, some major change to GFDP that I expect would be the last big change. I don't know when that rewrite would happen. I'll try to make it as gradual as possible (simply because big changes are much harder to finish than the sum of their parts...)
It might be something relevant to the GFDP, so I'll send it to you after I flesh it out.
ok
At other times it seems to mean any message that would be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. )
What does that case exclude ?... only "loadbang" and "dsp" ? (but then, not even necessarily).
It includes those messages (well, maybe not "dsp" with signal objects-- that's special).
[loadbang] does not send to any objects that only have a anything-method. It only talks to objects that explicitly define "loadbang". Same for "dsp".
(In both cases, this is an exception in the sending, not the receiving, ... but that distinction doesn't even matter to a writer of externals, in which case all that matters is that class_addanything is not enough)
How is your definition different than my 2nd one above?
Oops... either there was no difference at all, or there was something very subtle and I forgot what it was.
An [args] that does both setting and getting would be somewhat analogous to a "luxury" message box. You use all the same messages to set the content, and sending a bang would output the content. The big difference I guess is that with args you can tell it default values to output if there are no args, which you can't do with a message box.
Right. That sounds like something to consider, for the future...
But also, another big difference is that it does a job of [unpack]ing, that the messagebox doesn't do. Therefore, in that case, to follow an analogy with the messagebox, it's ambiguous whether there ought to be a complementary implicit [pack] behaviour in [args], causing it to have as many inlets as it has outlets.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Sat, 8/7/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Saturday, August 7, 2010, 2:06 AM On Mon, 2 Aug 2010, Jonathan Wilkes wrote:
--- On Mon, 8/2/10, Mathieu Bouchard matju@artengine.ca
wrote:
I suppose you can also find other situations in
which GF
crashes instead of reporting an error message ?
That's the only I've seen so far. I haven't used
GF much yet.
That's quite a problem, because I can't think of anything that would make this error message any more crash-prone than the standard error messages you get in GF externals (GF abstractions are a different matter though, because then, many error messages would come from Pd instead).
It's confusing while you don't expect it. Once
it's
expected, it's not any more confusing than
receive-symbols
hidden inside IEMGUI properties dialogues.
But IEMGUI receive-symbols don't make any assumptions
about whether
or not there is an inlet in a particular canvas.
My comparison with IEMGUI is to mean that once you start with the supposition that every message travels along a wire, you hit one exception with [r]/[s] and it's fine, then you hit another exception with hidden implicit [r]/[s] inside IEMGUI and floatatom/symbolatom and it's fine as well, and then you hit another exception with [args] and I don't know why it would be less fine.
Well for one thing, in all those cases you can control where the messages end up (or which messages arrive) using send/receive names. With [args] the blueberries appear in my cereal bowl without me having gone to the refridgerator to retrieve them. And if I want to pour [milk~] instead of [milk] the refridgerator quits running.
What if the abstraction in question doesn't have any
xlets, but the user wants to use key/value pairs?
If an object has no need for an inlet, then it doesn't matter whether there is one at all.
And then, the point of key/value pairs in left inlets is to ensure that every attribute is settable at runtime in the same manner as it is settable in the objectbox. It is enforcing a standard by making it convenient to follow the standard. Thus, the perspective of [args] on key/values is that objects that use them should have an [inlet] so that those attributes can be reconfigured at any time if the user wants it.
I could add an option to make it differently (actually, backward-compatible with the older [args] that didn't do that yet) but I don't really see a purpose for which I'd say « yes, it's a good idea to make this attribute non-reconfigurable ».
Actually there's a particular doc-related example I
have in mind that
would benefit from key/values in the args but doesn't
have xlets.
You know, if it's a GOP, then the [inlet] can be hidden by putting any GOP-visible component on top of it. the GFDP components such as [doc_i] and [doc_m] are covering the inlet-space, at least in run-mode (those two particular classes only do so in run-mode).
I'm actually also toying with the idea of adding inlets to [doc_m] and such, during the « GFDP rewrite », that is, some major change to GFDP that I expect would be the last big change. I don't know when that rewrite would happen. I'll try to make it as gradual as possible (simply because big changes are much harder to finish than the sum of their parts...)
It might be something relevant to the GFDP, so I'll
send it to you after I flesh it out.
ok
At other times it seems to mean any message
that would
be accepted by the anything-method, which
includes list
messages as well as the other pd built-ins.
(like [any],
[send], [spigot], etc. )
What does that case exclude ?... only "loadbang"
and "dsp"
? (but then, not even necessarily).
It includes those messages (well, maybe not "dsp" with
signal objects--
that's special).
[loadbang] does not send to any objects that only have a anything-method. It only talks to objects that explicitly define "loadbang". Same for "dsp".
(In both cases, this is an exception in the sending, not the receiving, ... but that distinction doesn't even matter to a writer of externals, in which case all that matters is that class_addanything is not enough)
How is your definition different than my 2nd one
above?
Oops... either there was no difference at all, or there was something very subtle and I forgot what it was.
Well, I'd like to figure out the simplest way to write this particular definition so that someone unfamiliar with this e.e. cummings-like language has a chance of understanding it.
An [args] that does both setting and getting would be
somewhat analogous to a "luxury" message box. You use all the same messages to set the content, and sending a bang would output the content. The big difference I guess is that with args you can tell it default values to output if there are no args, which you can't do with a message box.
Right. That sounds like something to consider, for the future...
But also, another big difference is that it does a job of [unpack]ing, that the messagebox doesn't do. Therefore, in that case, to follow an analogy with the messagebox, it's ambiguous whether there ought to be a complementary implicit [pack] behaviour in [args], causing it to have as many inlets as it has outlets.
If you did that then are all the inlets "hot"? Or would a "bang" to the left inlet both update and output the args?
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, 6 Aug 2010, Jonathan Wilkes wrote:
With [args] the blueberries appear in my cereal bowl without me having gone to the refridgerator to retrieve them.
I don't know why you wouldn't want the blueberries to appear in your cereal bowl automatically. It's a really cool features.
And if I want to pour [milk~] instead of [milk] the refridgerator quits running.
Ok, you mean if the left inlet is an [inlet~] ? Well, that's a limitation of Pd. It doesn't allow abstraction inlets to be hybrid inlets. You can't even emulate, imitate nor wrap [tabwrite~], for example, because it has a hybrid inlet that you can't do with neither [inlet] nor [inlet~].
Why would you complain to me ? Complain to Miller instead.
Well, I'd like to figure out the simplest way to write this particular definition so that someone unfamiliar with this e.e. cummings-like language has a chance of understanding it.
Write it the way you did, and if I ever find again something to say, I will tell you.
I don't know what "e.e.cummings-like" may mean because I don't have that background.
But also, another big difference is that it does a job of [unpack]ing, that the messagebox doesn't do. Therefore, in that case, to follow an analogy with the messagebox, it's ambiguous whether there ought to be a complementary implicit [pack] behaviour in [args], causing it to have as many inlets as it has outlets.
If you did that then are all the inlets "hot"? Or would a "bang" to the left inlet both update and output the args?
I don't quite know.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Sun, 8/8/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Sunday, August 8, 2010, 8:30 PM On Fri, 6 Aug 2010, Jonathan Wilkes wrote:
With [args] the blueberries appear in my cereal bowl
without me having gone to the refridgerator to retrieve them.
I don't know why you wouldn't want the blueberries to appear in your cereal bowl automatically. It's a really cool features.
Sometimes it is. Then sometimes I don't want blueberries, like if I want to use key/values pairs to set something that shouldn't change at runtime, and I want all messages sent to the left inlet to pass unchanged to the outlet (or blocked given some condition).
And if I want to pour [milk~] instead of [milk] the
refridgerator quits running.
Ok, you mean if the left inlet is an [inlet~] ? Well, that's a limitation of Pd. It doesn't allow abstraction inlets to be hybrid inlets. You can't even emulate, imitate nor wrap [tabwrite~], for example, because it has a hybrid inlet that you can't do with neither [inlet] nor [inlet~].
No but currently you can have a signal object with a leftmost [inlet~] and then have a right [inlet] for the messages. So while your [args] adds the key/value feature, using this feature means you no longer have the ability to have a leftmost [inlet~] in an abstraction.
Why would you complain to me ? Complain to Miller instead.
Well, I'd like to figure out the simplest way to write
this particular definition so that someone unfamiliar with this e.e. cummings-like language has a chance of understanding it.
Write it the way you did, and if I ever find again something to say, I will tell you.
I don't know what "e.e.cummings-like" may mean because I don't have that background.
I'm referring to the act of personifying an indefinite pronoun.
But also, another big difference is that it does a
job of
[unpack]ing, that the messagebox doesn't do.
Therefore, in
that case, to follow an analogy with the
messagebox, it's
ambiguous whether there ought to be a
complementary implicit
[pack] behaviour in [args], causing it to have as
many
inlets as it has outlets.
If you did that then are all the inlets "hot"?
Or would a "bang" to the left inlet both update and output the args?
I don't quite know.
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Hans-Christoph Steiner -
Jonathan Wilkes -
Mathieu Bouchard